<div dir="ltr"><div>Hi Gábor,</div><div><br></div><div>The C++ name-matching I think is an interesting case. I believe that at the moment this is beyond the scope of the initial implementation that I am driving with. I don't think that it is beyond extension though. The names actually are matched using the spelling at the site of the declaration. I would imagine that you could do the same thing and check if the names match, which actually is good because that means that you do not need to worry about the decorated names, but rather the names as spelt by the user. This will likely have some amount of work involved as one of the interesting cases that comes to mind is the inline namespaces. I don't think that the design here precludes the functionality, merely that we will need additional processing specifically for C++ (which I think is reasonable).</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 29, 2020 at 9:11 AM Gábor Márton <<a href="mailto:martongabesz@gmail.com">martongabesz@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Saleem,<div><br></div><div>About the technical aspects. The feature to be able to add extra information to library functions would be really helpful in the Clang Static Analyzer. APINotes might be a way forward to achieve that.</div><div><br></div><div>We'd like to add the following to functions<br></div><div><ul><li>Argument constraints</li><ul><li>Not null</li><li>Range, e.g. isalpha(int x) x must be in [0,255].</li><li>Buffer size, e.g. fread(x1, x2, x3) x1 is a buffer with a size denoted by x2 * x3</li></ul><li>Taint rules</li><ul><li>propagation <br> <font face="monospace">int x; // x is tainted<br> int y;<br> myPropagator(x, &y); // y is tainted</font></li><li>filter<br> <font face="monospace">int x; // x is tainted<br> isOutOfRange(&x); // x is not tainted anymore</font><br></li><li>sink<br> <font face="monospace">int x; // x is tainted<br> myNamespace::mySink(x); // It will warn</font><br></li></ul><li>Error return rules, e.g. the return value of <a href="https://wiki.sei.cmu.edu/confluence/display/c/ERR33-C.+Detect+and+handle+standard+library+errors" target="_blank">mktime() should always be checked against -1.</a> (<a href="https://reviews.llvm.org/D72705" target="_blank">D72705</a>)</li><li>Indicate which functions we should consider with <a href="https://www.youtube.com/watch?v=IM1DYZ-xn-k" target="_blank">statistical checkers</a> (WIP, not upstreamed yet).</li></ul></div><div>Note to taint analysis: we might want to tag global variables as sources. E.g. std::cin.</div><div><br></div><div>I think that we could extend the APINote implementation that you have in the referenced commit, but with a CSA specific attribute:</div><div><font face="monospace">def CSANotes : InheritableAttr {<br> let Spellings = [GNU<"csa">];<br> let Args = [StringArgument<"FreeFormatOrSomeYamlMaybe">];<br> let Subjects = SubjectList<[Tag, Function, Var],<br> ErrorDiag>;<br>}<br></font>The string argument could be parsed specifically to the CSA developers' needs in a CSA specific implementation file. IMHO it would be a flexible solution because we could avoid adding many CSA specific attributes to Attrs.td and it would allow us to make experiments.</div><div><br></div><div>My concerns about the referenced APINotes implementation:</div><div><ul><li>Specifically with the `'Name' key`. How could we match in C++</li><ul><li>overloaded functions</li><li>member functions</li><li>functions in namespaces</li><li>function templates</li><li>member functions of class templates (e.g. std::vector::begin)</li></ul><li>Do we have a mechanism to test/indicate if a note is not applied but it should have been?</li></ul></div><div><br></div><div>Adding CSA guys who might want to comment.<br></div><div><div><a class="gmail_plusreply" id="gmail-m_7021135304688290240plusReplyChip-0" href="mailto:noqnoqneo@gmail.com" target="_blank">+Artem Dergachev</a> <br></div><div><a class="gmail_plusreply" id="gmail-m_7021135304688290240plusReplyChip-2" href="mailto:xazax.hun@gmail.com" target="_blank">+Gábor Horváth</a> <br></div></div><div><br></div><div>Thanks,</div><div>Gabor</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 28, 2020 at 11:10 PM Saleem Abdulrasool via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Hi!<div><br></div><div>I'd like to revive the effort around merging APINotes support into the <a href="http://llvm.org/" target="_blank">llvm.org</a> repository. This was previously discussed at <a href="http://lists.llvm.org/pipermail/cfe-dev/2017-May/053860.html" target="_blank">http://lists.llvm.org/pipermail/cfe-dev/2017-May/053860.html</a> nearly 3 years ago. The overall consensus seemed neutral to slightly positive. Now that the Swift specific attributes have been merged, the APINotes seem like a good next step towards converging the fork.</div><div><br></div><div>I've put up <a href="https://reviews.llvm.org/D88446" target="_blank">https://reviews.llvm.org/D88446</a> to add initial documentation on the feature before trying to add the actual implementation with the goal of gathering commits on the technical aspects of the feature.</div><div><br></div><div>Thanks.</div><font color="#888888"><div></div></font><div><br></div>-- <br><div dir="ltr">Saleem Abdulrasool<br>compnerd (at) compnerd (dot) org</div></div></div>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">Saleem Abdulrasool<br>compnerd (at) compnerd (dot) org</div></div>