<div dir="ltr"><div>As Anna has kindly pointed out, APINotes is a possible replacement for my patch proposal at <a href="http://reviews.llvm.org/D13731">http://reviews.llvm.org/D13731</a>, i.e. to provide the static analyzer with "fake" function definitions with extra attributes that get merged into the AST at the beginning of static analysis (similar idea to that described earlier by Sean S and James YK).   </div><div><br></div><div>As APINotes sounds like a good solution, I would need to make sure this fits our requirements: </div><div>1. We need to support new attributes that make sense for static analysis, not just the ones currently used by the static analyzer. </div><div>2. We need allow 3rd parties to easily create their own APINotes files. </div><div>3. We need to support C++. </div><div>4. We need to support an unlimited number of functions. </div><div>5. To have the flexibility of organizing one/many libraries into one or many APINotes files. </div><div>6. To have a corresponding attribute to each APINotes feature. </div><div>7. To have the capacity to support conditional attributes (as Sean S described earlier). </div><div>  </div><div>Do those requirement fit with the APINotes design? </div><div>  </div><div>Regards, </div><div>  </div><div>Pierre Gousseau </div><div>SN-Systems - Sony Computer Entertainment </div></div><div class="gmail_extra"><br><div class="gmail_quote">On 7 December 2015 at 21:42, Anna Zaks <span dir="ltr"><<a href="mailto:ganna@apple.com" target="_blank">ganna@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On Dec 4, 2015, at 4:31 PM, Sean Silva <<a href="mailto:chisophugis@gmail.com" target="_blank">chisophugis@gmail.com</a>> wrote:</div><br><div><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 4, 2015 at 2:46 PM, James Y Knight <span dir="ltr"><<a href="mailto:jyknight@google.com" target="_blank">jyknight@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Without having looked into it...<div><br>If people need a feature like this, I'm wondering if it would make sense to parse a special file containing normalish C/C++/ObjC declarations, and use those to replace or augment attributes from matching declarations in the normal parse.</div></div></blockquote><div><br></div><div>That's actually a really good idea.</div></div></div></div></div></blockquote><div><br></div><div>Adding a file containing C/C++/ObjC declarations with additional attributes would be more flexible in some respects. However, this approach has many potential downsides.</div><div><br></div><div>Since there was no specific proposal on how this approach should be implemented, suppose we wanted to extend the experimental ModelInjector (<a href="http://reviews.llvm.org/D13731" target="_blank">http://reviews.llvm.org/D13731</a>). ModelInjector was added to the analyzer so that we could feed it summaries of common functions, which are not a part of a TU otherwise. The models are injected very late, during static analysis, so other clients would not be able to use that approach as it stands right now.</div><div><br></div><div>Here are some of the problems with adding augmented C/C++/ObjC declarations:</div><div> - Compiling the extra declarations might lead to unpredictable errors depending on the code the compiled project contains. </div><div> - Common APIs often have slightly different declarations on different platforms. We could address those with ifdefs; that would be messy. Naming the “thing” in the APINotes file is much simpler.</div><div> - In order to make this usable by other clients, the injection has to be moved up the compilation pipeline. Most likely, we would need to be able to tell which header the declaration comes from as well as associate it with the corresponding model file. This approach would muddle the compilation process much more and will be more difficult to maintain.</div><div> - What about the distribution model? Suppose we need to use this method to suppress false positives in user code by annotating 3d party APIs. Using the annotations in code approach, we would be redistributing those APIs.</div><div> - The binary YAML format is more succinct, which might matter more or less depending on how many supplementary annotations one has.</div><div><br></div><div>Cheers,</div><div>Anna.</div></div><div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Yesterday we were talking at the social briefly about this and actually it became pretty clear that a YAML-type format wouldn't scale. A compelling example from the internal patch I was reviewing is something like "if this argument has this bit set, then treat this other argument as having this meaning to the static analyzer"*; the bit itself is of course specified in the source by `#define FOO_MAGIC_OPTION (1 << 7)` or `enum { ..., FOO_MAGIC_OPTION = (1 << 7), ...}` or whatever, and to maintain sanity the YAML file would of course want to use that symbolic constant. Realistically C/C++ source code is the only fully general way to get the right name lookup, macro expansion, constexpr evaluation, ...</div><div><br></div><div>So instead of a separate file, it could be something like, your side-table of attributes is really just a C/C++ source file that contains "replacement declarations" (marked with a pragma or attribute or something), that the analyzer would parse first then substitute as appropriate (or something). That would allow you to use the natural API `#include`'s to pick up the symbolic constants.</div><div><br></div><div><br></div><div>* (</div><div>For reference, what would ultimately be desired is something like:</div><div><br></div><div>enum {</div><div>  ...</div><div>  FOO_MAGIC_BIT = (1 << 7),</div><div>  ...</div><div>};</div><div><br></div><div>// If (flags & FOO_MAGIC_BIT), then the analyzer should treat `p` as having some special meaning.</div><div>void foo(Bar *p, unsigned flags) __attribute__((arg_is_magical_when_bit_is_set(0/*arg `p`*/, 1/*arg`flags`*/, FOO_MAGIC_BIT)));</div><div>)</div><div><br></div><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div> Requiring a special YAML and binary format reader/writer seems unfortunate, especially as it looks nowhere close to being generically useful, beyond exactly what Swift needed.</div><div><br></div><div>I must also admit to being a bit surprised that Apple needed to ship a feature like this at all, since I'd have thought you/they would have had full control over their own platform's header files, and could've just committed the changes to that directly. :)</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 4, 2015 at 5:06 PM, Anna Zaks via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span><blockquote type="cite"><div>On Dec 3, 2015, at 5:18 PM, Sean Silva via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:</div><br><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Dec 3, 2015 at 2:45 PM, Douglas Gregor via cfe-dev<span> </span><span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span><span> </span>wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word">Hi all,<br><br>As some of you may have heard, Swift has gone open-source over at <a href="http://swift.org/" target="_blank">swift.org</a>. Swift makes heavy use of Clang for its (Objective-)C interoperability, including loading Clang modules to map (Objective-)C APIs into Swift via Swift’s “Clang importer” and using Clang’s CodeGen to handle C ABI issues (record layout, calling conventions) and use C inline functions directly from Swift [*]. <br><br>As an out-of-tree language front-end dependent on Clang, we have a clone of the <a href="http://llvm.org/" target="_blank">llvm.org</a> Clang repository over on GitHub at <a href="http://github.com/apple/swift-clang" target="_blank">github.com/apple/swift-clang</a>. We merge regularly and try to minimize our differences with <a href="http://llvm.org/" target="_blank">llvm.org</a>'s Clang—for more information on how we’re handling this, see <a href="http://swift.org/contributing/#llvm-and-swift" target="_blank">swift.org/contributing/#llvm-and-swift</a>.<br><br>That said, Swift’s clone of the Clang repository does have some content that isn’t in the <a href="http://llvm.org/" target="_blank">llvm.org</a> Clang repository. Here’s a quick summary of what that content is:<br><br>* There are several new attributes. We plan to propose these for inclusion into mainline Clang. They’re fairly small additions, some of which have wider applicability than Swift support:<br><br><span style="white-space:pre-wrap">    </span>* ‘noescape’ attribute: indicates that the address provided by a particular function parameter of pointer/reference type won’t escape the function. At present, this is only used to map to Swift’s ‘noescape’ attribute, although we think it makes sense to use this for the LLVM IR “nocapture” parameter attribute as well.<br><br><span style="white-space:pre-wrap">    </span>* ‘objc_subclassing_restricted’ attribute: indicates that a particular Objective-C class cannot be subclassed. Swift uses it in its generated Objective-C headers, but we are interested in making this a first-class Objective-C feature.<br><br><span style="white-space:pre-wrap">     </span>* Swift-specific attributes (‘swift_error', ‘swift_name’, ’swift_private'): these attributes affect the mapping of (Objective-)C declarations into Swift.<br><br><span style="white-space:pre-wrap">   </span>* ‘swift’ unavailability: the existing ‘availability’ attribute is extended with a ‘swift’ platform, so that one can mark something as unavailable in Swift.<br><br>* API Notes: This represents the bulk of the changes in the repository. API notes solve a not-uncommon problem: we invent some new Clang attribute that would be beneficial to add to some declarations in system headers (e.g., adding a ‘noreturn’ attribute to the C ‘exit’ function), but we can’t go around and fix all of the system headers everywhere. With API notes, we can write a separate YAML file that states that we want to add ‘noreturn’ to the ‘exit’ function: when we feed that YAML file into Clang as part of normal compilation (via a command-line option), Clang will add ‘noreturn’ to the ‘exit’ function when it parses the declaration of ‘exit’. Personally, I don’t like API notes—even with our optimizations, it’s inefficient in compile time and it takes the “truth” out of the headers—but I can see the wider use cases. If the Clang community wants this feature, I can prepare a proper proposal; if not, we’ll keep this code in the Swift clone of Clang and delete it if Swift ever stops needing it.<br></div></blockquote><div><br></div><div>Internally I recently saw a situation that would have benefitted from this sort of thing. Essentially Sean Eveson (CC'd) and his coworkers were prototyping some static analyzer checks that required certain functions in the SDK to be marked up with some info (really not much more than the moral equivalent of an "printf" attribute). Obviously there's a catch-22 with proving the checks are valuable and getting the corresponding API's officially marked up with such attributes (and such updated headers making to all clients, etc.).</div><div><br></div><div>This sort of feature would help break that catch-22 and avoid the need for ad-hoc hardcoded tables. Having all that PS4-specific data hardcoded was actually the primary barrier to upstreaming the check (or at least getting a proper upstream review of the idea), so having a way to decouple those private annotations would have really been nice!</div><div><br></div></div></div></div></div></blockquote><div><br></div></span>+1 </div><div><br></div><div>API Notes is great for adding annotations to declarations when/before changes to header files can be made. I can see how this could be used by the future clang static analyzer checks.</div><div><br></div><div>Anna.</div><span><div><br></div><div><br><blockquote type="cite"><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_extra"><div class="gmail_quote"><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><br>* SourceMgrAdapter: An adapter that translates diagnostics from an llvm::SourceMgr to clang::SourceManager. This is used by the API notes YAML compiler to translate its diagnostics into something that goes our through Clang’s SourceManager, but might be useful for other clients that are making use of llvm::SourceMgr for simple handling of source files. Unless API notes gets pulled into <a href="http://llvm.org/" target="_blank">llvm.org</a> Clang or someone else asks for it, I don’t feel like this is important to pull into <a href="http://llvm.org/" target="_blank">llvm.org</a> Clang by itself.<br><br><br>Any questions? Feel free to contact me!<br><br><span style="white-space:pre-wrap">       </span>Cheers,<br><span style="white-space:pre-wrap">       </span>Doug<br><br>[*] The actual ideas were discussed at the 2014 Developer Meeting in the “Skip the FFI” talk by Jordan Rose and John McCall (<a href="http://llvm.org/devmtg/2014-10/#talk18" target="_blank">http://llvm.org/devmtg/2014-10/#talk18</a>)</div><br>_______________________________________________<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="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br><br></blockquote></div><br></div></div><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">_______________________________________________</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">cfe-dev mailing list</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><a href="mailto:cfe-dev@lists.llvm.org" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">cfe-dev@lists.llvm.org</a><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a></div></blockquote></div><br></span></div><br>_______________________________________________<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="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br></div></div>
</div></blockquote></div><br></div></blockquote></div><br></div>