[cfe-dev] Adding Support for APINotes

Saleem Abdulrasool via cfe-dev cfe-dev at lists.llvm.org
Mon Oct 5 13:37:46 PDT 2020


Hi Gábor,

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).

On Tue, Sep 29, 2020 at 9:11 AM Gábor Márton <martongabesz at gmail.com> wrote:

> Hi Saleem,
>
> 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.
>
> We'd like to add the following to functions
>
>    - Argument constraints
>       - Not null
>       - Range, e.g. isalpha(int x) x must be in [0,255].
>       - Buffer size, e.g. fread(x1, x2, x3)  x1 is a buffer with a size
>       denoted by x2 * x3
>    - Taint rules
>       - propagation
>           int x; // x is tainted
>         int y;
>         myPropagator(x, &y); // y is tainted
>       - filter
>           int x; // x is tainted
>         isOutOfRange(&x); // x is not tainted anymore
>       - sink
>           int x; // x is tainted
>         myNamespace::mySink(x); // It will warn
>       - Error return rules, e.g. the return value of mktime() should
>    always be checked against -1.
>    <https://wiki.sei.cmu.edu/confluence/display/c/ERR33-C.+Detect+and+handle+standard+library+errors>
>    (D72705 <https://reviews.llvm.org/D72705>)
>    - Indicate which functions we should consider with statistical checkers
>    <https://www.youtube.com/watch?v=IM1DYZ-xn-k> (WIP, not upstreamed
>    yet).
>
> Note to taint analysis: we might want to tag global variables as sources.
> E.g. std::cin.
>
> I think that we could extend the APINote implementation that you have in
> the referenced commit, but with a CSA specific attribute:
> def CSANotes : InheritableAttr {
>   let Spellings = [GNU<"csa">];
>   let Args = [StringArgument<"FreeFormatOrSomeYamlMaybe">];
>   let Subjects = SubjectList<[Tag, Function, Var],
>                              ErrorDiag>;
> }
> 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.
>
> My concerns about the referenced APINotes implementation:
>
>    - Specifically with the `'Name' key`. How could we match in C++
>       - overloaded functions
>       - member functions
>       - functions in namespaces
>       - function templates
>       - member functions of class templates (e.g. std::vector::begin)
>    - Do we have a mechanism to test/indicate if a note is not applied but
>    it should have been?
>
>
> Adding CSA guys who might want to comment.
> +Artem Dergachev <noqnoqneo at gmail.com>
> +Gábor Horváth <xazax.hun at gmail.com>
>
> Thanks,
> Gabor
>
> On Mon, Sep 28, 2020 at 11:10 PM Saleem Abdulrasool via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>> Hi!
>>
>> I'd like to revive the effort around merging APINotes support into the
>> llvm.org repository.  This was previously discussed at
>> http://lists.llvm.org/pipermail/cfe-dev/2017-May/053860.html 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.
>>
>> I've put up https://reviews.llvm.org/D88446 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.
>>
>> Thanks.
>>
>> --
>> Saleem Abdulrasool
>> compnerd (at) compnerd (dot) org
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>

-- 
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20201005/25c4db96/attachment.html>


More information about the cfe-dev mailing list