On 06/20/2017 12:54 PM, Andrew Halberstadt wrote:
Yes, we can blacklist checks with:
cppcheck --suppress=<id>
You can see the check ids with:
cppcheck --errorlist
It's actually even more flexible, checks can be disabled for specific
files, directories and even lines in the file. And it can all be
specified in a text file then passed in with:
cppcheck --suppressions-list=<path>
Hmm, OK, that's a blacklist though not a whitelist. My question before
was trying to get to whether we can run this tool in a mode where it
will only run the checks which we have "blessed" with the goal of being
able to run it as tier 1 (and having people being backed out over its
complaints) on the assumption that the whitelisted checks would be those
few checks that we have found to be useful in it, but...
Maybe we could start off running this as tier 3 (so it won't cause
backouts, but people who care can check up on it once in awhile). We
could modify the list of checks to exclude over time and maybe get a
better sense of whether or not the job is catching anything useful.
... at the lack of being able to run the tool with a whitelist as an
option, I think your suggestion here is a good one. We have used a
similar mechanism to run valgrind for example and it has worked
successfully in the past. I wonder if this is something that
Sylvestre's team would be interested to take a look at?
Cheers,
Ehsan
On Sun, Jun 18, 2017 at 3:08 PM, Ehsan Akhgari
<ehsan.akhg...@gmail.com <mailto:ehsan.akhg...@gmail.com>> wrote:
Is it possible to run cppcheck in a mode where we select which
checks it runs? If yes, we could look at the list of true
positives that people have found (and continue to find) in bug
1370292 and create an opt-in set of checks that rare valuable ones
to have turned on by default, and leave the rest off by default.
(I'm hoping the effectiveness of its check isn't context
sensitive...)
On 06/06/2017 09:06 AM, Andrew Halberstadt wrote:
I was doing a bit of research into cppcheck [1] to see if it
might be worth
running as a linter (alongside eslint, flake8 etc). More
discussion in bug
1370292 [2]. I ran it against the entire tree [3] and got
these results:
https://bug1370292.bmoattachments.org/attachment.cgi?id=8874498
<https://bug1370292.bmoattachments.org/attachment.cgi?id=8874498>
So far it looks like the false positive rate is too high to
warrant
standing up a job in CI. It seems it would cause more
frustration than it's
worth. But there are likely some legit errors in there, so
please take a
quick look to see if any apply to your module. Feel free to
comment over in
bug 1370292 if you have opinions one way or the other on
standing this up
as a task. Barring a claim that it would be useful, I'll be
WONTFIXing that
bug in a bit.
-Andrew
[1] http://cppcheck.sourceforge.net/
<http://cppcheck.sourceforge.net/>
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1370292
<https://bugzilla.mozilla.org/show_bug.cgi?id=1370292>
[3] cppcheck $(sed -e 's/^/-i/'
tools/rewriting/ThirdPartyPaths.txt)
-ithird_party . 2> errors.txt
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
<mailto:dev-platform@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-platform
<https://lists.mozilla.org/listinfo/dev-platform>
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
