<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>My company has an implementation of comment suppression that we
haven't tried to upstream yet. It doesn't address all the issues
you mentioned though.</p>
<p>The general comment format is something like: // clang_sa_ignore
[deadcode.DeadStores, cplusplus] plus whatever other text the user
wants<br>
</p>
<p>The comment must be on the same line as the last element in the
path. The line offset that you proposed seems like a reasonable
extension.<br>
</p>
<p>The comment only suppresses the diagnostic. This happens well
after all the path sensitive nodes have been created. Stated
differently, the comment suppression does not help the analyzer
uncover new problems.</p>
<p>One thing to note is that it isn't necessarily obvious which
checker generated a warning, particularly when you only have the
console output to work with. So we changed our analyzer to also
emit the category of any static analyzer warnings.</p>
<p>I'll start some internal conversations and see if we can start
getting some of those patches upstreamed.<br>
</p>
<div class="moz-cite-prefix">On 8/18/2016 3:17 AM, Gábor Horváth via
cfe-dev wrote:<br>
</div>
<blockquote
cite="mid:CAPRL4a2sGnU3Mu0zfrYB7V+xGMAy3zh7Awg+MHf-Pi5y2KK1rA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>Hi!<br>
<br>
</div>
In the CodeChecker tool (<a moz-do-not-send="true"
href="https://github.com/Ericsson/codechecker">https://github.com/Ericsson/codechecker</a>)
we support suppressing false positive bugs as a post
processing step. After all the issues were reported,
CodeChecker filters out the suppressed ones, and those
will not be displayed to the user. <br>
<br>
</div>
In our experience, however, and external tool only
suppression suppport is not sufficient for certian
reasons:<br>
</div>
* When a checker generates a sink node during analysis, the
rest of the path will not be covered by the Static Analyzer.
Unfortunately, if the user suppress the bug in an external
tool, the coverage will not get better. This way false
positive results can hide true positive results regardless
of suppression.<br>
</div>
* The compiler could do better job diagnosing ill formed
suppressions (invalid source range, typo in checker name etc).<br>
</div>
<div>* Tools that are developed on top of the compiler need not
to introduce their own customized solution for suppression. <br>
<br>
</div>
<div>It is beneficial to have a suppression format that is
standard across all clang tools. So the same format could be
used to:<br>
</div>
<div>* Suppress clang warnings<br>
</div>
<div>* Suppress clang static analyzer warnings<br>
</div>
<div>* Suppress clang tidy warnings<br>
<br>
</div>
<div>There are two main approaches to suppress warnings that I
can think of right now:<br>
<br>
</div>
<div>Suppress using comments (or pragma):<br>
</div>
<div>* This is a good solution for code evolution. The comments
are moving together with the code. Edits are less likely to
invalidate comments.<br>
</div>
<div>* This is an intrusive solution, the source code needs to
be changed to suppress an issue. This is both good, because
the suppressions are version controlled and bad, because
suppressing in 3rd party libraries might be problematic.<br>
</div>
<div>* For path sensitive checks, it is not always self evident
at which point of the path should a suppression comment be
added. <br>
<br>
<br>
</div>
<div>Suppress using hashes:<br>
</div>
<div>* It is hard to come up with a reliable hash to identify
bugs. There always might be corner cases when the hashes of
different bugs collide or the hash of a bug changes due to an
edit that in fact should not affect the bug.<br>
</div>
<div>* It is non intrusive.<br>
</div>
<div>* The user do not need to think about at which point should
the suppression comment be inserted.<br>
<br>
<br>
</div>
<div>I would suggest the suppress comment road.<br>
</div>
<div>The syntax could be something like:<br>
</div>
<div>// clang suppress warning-or-checker-name [optional line
offset][optional column range] [comment]<br>
<br>
</div>
<div>The warning-or-checker-name could be a regex, so multiple
checks can be suppressed at the same time.<br>
</div>
<div>Column ranges are useful when multiple errors are reported
for the same line.<br>
</div>
<div>Line offsets are useful when one do not want to break the
flow of a multi line code snippet with a comment, so this way
warnings could be suppressed without too much negative effects
on the readability.<br>
</div>
<div>Comment is for documentation purposes, the user can
document why does she think that this is a false positive.<br>
<br>
</div>
<div>What do you think?<br>
<br>
</div>
<div>Regards,<br>
</div>
<div>Gábor<br>
</div>
<div><br>
</div>
<div><br>
<br>
</div>
<div><br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
cfe-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
</pre>
</body>
</html>