-
Notifications
You must be signed in to change notification settings - Fork 1.6k
fixed #12056 - qt.cfg: implemented Q_OBJECT to get rid of symbolDatabaseWarning in selfcheck
#5533
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
I still wonder why we scan |
True, we cannot fix any warnings in there. So it's rather dogfooding/bootstrapping for those files. But it might expose actual issues in the generated code as well as highlight analysis issues (the suppressed |
Q_OBJECT to get rid of symbolDatabaseWarning in selfcheck
It is strange that we are only getting a single warning. That should be reported for each of the classes based on |
It appears these are not reported because of the |
Still we should be also getting |
Possibly the same |
Nope. One is actually used and the other ones are not reported since they call the base class implementation with the same name. |
|
Anything still to do here? |
|
Given that Q_OBJECT is just a tag for the moc compiler, I see no upside for the user in defining it. |
|
*We' should scan them as integration test (they actually exposed several bugs). Also it could happen that the generated code contains bugs we might find. As mentioned before I don't know if user-code can be injected into the generated one. Also it avoids additional issues. And I doubt most people will exclude the |
|
It is actually essential for the That is also an annoying issue within CLion which shows me lots of unused GUI functions because the generated files are not being considered. |
|
I am not sure if we want to model the moc. I have the feeling the CheckUnusedFunction could relax its checking in classes that has a Q_OBJECT. It seems to me it would be good if we could check qt code without having the generated |
|
In terms what this tries to achieve is similar to the markup handling in the libraries. The main difference that this is just a define and not a separate feature implemented just for that case. Currently this would require interaction from each user to work and we usually go for a small/no configuration and this would be in line with that. To have to working better out-of-the-box would require a two-stage macro handling as suggested here: https://trac.cppcheck.net/ticket/8956#comment:10. |
|
There is also the |
No description provided.