[RFC] New attribute `annotate_type` (iteration 2)

Clang Frontend
4

This sounds reasonable, but I think it would be up to the static analysis tools that interpret the attribute to perform this propagation. From the point of view of Clang, I’m not sure there’s a meaningful distinction to be made, beyond answering the question of how this attribute will show up in the AST. Let’s use a concrete example:

typedef int [[clang::annotate_type("foo")]] FooAnnotatedInt;
FooAnnotatedInt f();

Here’s how I think this should behave (and how it does currently behave in the draft patch):

  • The FooAnnotatedInt in the declaration of f() would be a TypedefType (pretty obviously).

  • Calling desugar() on this TypedefType would yield an AttributedType representing int [[clang::annotate_type("foo")]] (also pretty obviously, as that’s the underlying type of FooAnnotatedInt).

  • Calling getCanonicalType() on the TypedefType would yield a BuiltinType representing int. (Yet again, it pretty obviously has to do this, as we’ve said that the attribute doesn’t have any semantics from the C++ point of view, so it’s pretty much a given that the type has to canonicalize to int.)

Does all of this mean that FooAnnotatedInt behaves as if it were an int marked with the attribute? As I say, from the point of view of Clang, I’m not sure there’s really a distinction to be made, as within Clang an int with the attribute behaves just like an int without the attribute.

A static analysis tool that interprets the AST, on the other hand, has the choice. If it wants FooAnnotatedInt to behave like an attributed int, the AST contains all the information the tool needs to do this. If, on the other hand, the tool wants FooAnnotatedInt to behave like a plain int (or some other choice that may make sense for a specific tool), it can do that too.

No, we’re not planning to add any “library” functionality to Clang or Clang Static Analyzer that would provide facilities for shadow type systems, at least for now. The shadow type system would be implemented entirely within the static analysis check that interprets the annotate_type annotations. If at some point it turns out that there is common functionality that should be shared among multiple such checks, then of course it could make sense to factor it out into a library.

Thanks, that’s an interesting paper. I’m not really familiar with the other literature around this, but what the paper describes does sound a lot like what we’re trying to achieve.

As I recall, this is something that we discussed on the earlier version of this proposal, but I have since realized that I must have misread the C++ grammar. Looking at the grammar again, I believe it is not permissible to put an attribute after each individual decl-specifier, but only after the entire decl-specifier-seq. The relevant part of the grammar is here.

What this means is that in your example above, an annotate_type can be placed after the int, but not after the const, and indeed both Clang and gcc produce an error if a C++11 attribute is placed after the const. So the question of whether we want to allow annotate_type on qualifiers is, for better or worse, moot.

Thanks, that sounds great!