[PATCH] D13731: [Analyzer] Supporting function attributes in .model files.

pierre gousseau via cfe-commits cfe-commits at lists.llvm.org
Mon Dec 7 08:15:48 PST 2015


pgousseau added a comment.

In http://reviews.llvm.org/D13731#302989, @zaks.anna wrote:

> Pierre,
>
> Have you seen the post about API Notes?
>  http://llvm.cc/t/cfe-dev-clang-and-swift/331
>
> I believe using API notes would be a better approach for adding annotations. By the time the static analyzer sees the AST, the annotations would already be there. The API Notes should already seamlessly work for nullability annotations. Does that work for you? (Do we still need some parts of this patch? I am not sure.)


Thanks for pointing it out! It is not clear yet if APINotes is suited for our problematic, will need to ask some questions first on the "Clang and Swift" cfe-dev thread.

> A related topic is deciding what type of attributes should be used by the static analyzer checkers. Currently, there are 2 options, neither of which is ideal:

> 

> 1. Extend clang with new attributes for static analyzes. This is not highly desirable because the clang attributes namespace will get polluted and compiler users might start using them. This approach is also not convenient for proprietary checkers.

> 2. Annotate attribute (AnnotateAttr) is used in some places; however, this attribute creeps into LLVMIR, which caused problems in the past.

> 

>   The best approach would be to put all analyzer attributes behind "a fence" so that we could add/remove them without worrying that compiler(not analyzer) users depend on them. The attribute would not be CodeGened.

> 

>   Here what it might look like: analyzer_annotate(family, arg…) family: id arg:     [id=] value value:  number | string | id

> 

>   Is anyone interested in implementing this?


The "analyzer_annotate" idea sounds good, I would need to do more evaluation before deciding this is suitable for us though.


http://reviews.llvm.org/D13731





More information about the cfe-commits mailing list