-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
some CppCheck
and related usage cleanups
#5979
Conversation
This is a continuation of the This change is already buried somewhere in my countless branches but I did the changes from scratch now that I encountered this again. |
* and if it's possible at all */ | ||
bool isUnusedFunctionCheckEnabled() const | ||
{ | ||
return useSingleJob() && checks.isEnabled(Checks::unusedFunction); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmm.. I wonder why it doesn't check useSingleJob() || !buildDir.empty()
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just keeping the current behavior intact for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unsurprisingly tis check turned out flawed. This is addressed in #6207.
if (mSettings.checks.isEnabled(Checks::unusedFunction) && | ||
mSettings.useSingleJob() && | ||
mSettings.buildDir.empty()) { | ||
if (mSettings.isUnusedFunctionCheckEnabled() && mSettings.buildDir.empty()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmm.. I don't understand why we required that the buildDir is empty. Don't we want to run this checking here for some reason if the build dir is empty..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have no idea. Currently I am keeping the current behavior intact. I will look into this when I look at the build directory related false positives. But that requires adding a lot more general testing of the build directory first.
Okay - now I do recall why those changes were buried in the first place because I encountered exactly these testing failures. |
I was passing the wrong suppressions to the reporting function. Should be fine now. |
Merging as there has been no feedback for almost a whole week. It is also blocking traffic as usual. |
No description provided.