| Summary: | New Q_ENUM check also warns about Q_ENUMS for enums outside a class | ||
|---|---|---|---|
| Product: | [Developer tools] clazy | Reporter: | Christian Ehrlicher <Ch.Ehrlicher> |
| Component: | general | Assignee: | Sergio Martins <smartins> |
| Status: | RESOLVED NOT A BUG | ||
| Severity: | normal | CC: | smartins |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Other | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
Ok, the question is - why someone would add Q_ENUM for a enum defined in a namespace. I currently can't see a reason for it but moc does not complain either ... :) Yeah, there's no reason. clazy could give a different warning for this case but the fix isn't trivial since the macro processor isn't connected to the AST, so I'll just close this |
----------------------------------- #include <QObject> //class Foo namespace Foo { // Q_OBJECT enum Bar { }; Q_ENUM ( Bar ) } //; ----------------------------------- Within this code, clazy warns about Q_ENUM usage but Q_ENUMS does not work here since there's no parent class which is derived from QObject and so no QMetaObject ... Did not find a simple solution for this problem so I had to write a bug report :) Reproducible: Always Steps to Reproduce: see details