[cfe-dev] Unknown attributes in clang

[Aaron Ballman via cfe-dev]

On Sun, Oct 11, 2020 at 11:47 AM Peter Dimov <pdimov at gmail.com> wrote:
>
> Aaron Ballman wrote:
>
> > 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.
>
> Does the answer change if we restrict ourselves only to C++ [[attributes]]
> matching the grammar in dcl.attr.grammar?

It would be pretty unfortunate if we only retain some kinds of unknown
attributes and not others.

However, I think it makes the problem easier because at least the
appertainment rules are clear in that case. However, the way we
represent semantic attribute arguments in the AST may be insufficient
for handling generic C++ [[attributes]]. We currently parse the
arguments based on information from Attr.td and then attach them as
members of the semantic attribute object, but in this scenario, we'd
have no idea what to parse or how to represent it in the AST. For
instance, the gsl::suppress attribute supported by Microsoft takes an
argument we can't currently represent, like:
[[gsl::suppress(pro.type.1)]]. For unknown attributes, I think we'd
have to parse token soup and retain the tokens themselves as part of
the AST representation, so a later consumer could do their own parsing
of the arguments (which could get awkward in some cases, I would
guess).

I think my preference is to put effort into the attribute plugin
system so that it's easy for downstream consumers of the Clang AST to
add attributes they know about to the frontend. This would include
things like custom argument parsing, adding novel semantic attributes
to the AST, etc. We're not quite there yet, but I think that approach
will result in a better user experience because the plugins can
provide better diagnostic support than we could do with a generic
solution. That said, I still think there may be value in retaining
some generic best-effort information about unknown attributes in the
AST -- e.g., the syntax used, the spelling of the attribute, a source
range for where the argument list (if any) can be found. We'd have to
be clear that this approach is a best-effort and that users should
prefer using a plugin for "serious" attribute support, but this would
at least retain enough information to be able to pretty print the
source code back out for the user.

~Aaron

>