[cfe-dev] Unknown attributes in clang

[Aaron Ballman via cfe-dev]

(Dropping the old list email address and adding the new one.)

On Sat, Oct 10, 2020 at 5:55 PM Vassil Vassilev <v.g.vassilev at gmail.com> wrote:
>
> Hi,
>
>    Consider the example:
>
>    struct X {
>      int x [[transient]];
>    };
>
>    Clang rightfully warns about unknown attribute 'transient' and
> ignores it. Unfortunately it does not seem to model the unknown
> attributes in the AST.

Correct, we currently drop all unknown attributes from the AST.

> Would it make sense to add another kind of
> attribute, UnknownAttr, which will model those as a token stream
> sequence? That would be of a great benefit for tools and clang plugins.

I think that could make sense but it can be a bit tricky. Some
attributes, like GNU-style __attributes__ "slide" from one AST node to
a more appropriate one, and that can be decided per-attribute. So one
problem is that we may attach unknown attributes to an unexpected AST
node (like adding it to a type when it really should be on a
declaration). Another problem is that attributes may have particular
parsing needs for their argument list and we may not be able to
represent all the various kinds of attribute arguments. So while it's
possible, it's not trivial.

Did you know that Clang now allows you to add plugin-based attributes?
This allows you to tell the frontend about how to parse the attribute
so that you can retain some information within the AST. The attribute
plugins don't currently let you define your own semantic attribute
(you would generally use an existing one, like AnnotateAttr) and there
are still some rough edges to the feature, but you can see more
information here:
https://clang.llvm.org/docs/ClangPlugins.html#defining-attributes

HTH!

~Aaron