The whole purpose of this e-mail is to gather ideas regarding our needs for C++11 attributes parsing. Right now, only select attributes are parsed in C++11 style, attribute arguments parsing is not implemented, there’s no common check for matching attribute targets (“Subjects” field in Attr.td). BTW, AFAIK, the latter is not implemented for GNU-style attributes either.
Currently, I see the following questions:
will we allow c++11 syntax for existing GNU attributes?
what new attributes do we expect to appear in c++11 syntax?
will they require late parsing of parameters?
do we need common code for checking attribute subjects? (currently, subjects are checked in handle.*Attr functions)
If you have other ideas/information on requirements to c++11 attributes, please post them here.
One addendum I have is that I think it is extremely vital that plugins be able to add custom attributes. I have a prototype patch which does this, at least for inheritable decl attributes. Ideally, we'd need to have an easy way to specify attribute subjects and probably attribute argument parsing as well; designed properly, this could eliminate a lot of code in Sema*Attr...
4. do we need common code for checking attribute subjects? (currently,
subjects are checked in handle.*Attr functions)
It would be awesome if we could automatically generate with TableGen
most of subject checking and argument checking. It seems like we can
because SemaDeclAttr.cpp is mostly boring copy-pasted code. I think
that we could describe attribute arguments declaratively in Attr.td
and remove most argument checks in SemaDeclAttr.cpp (like, is this an
ICE? is this an ICE that is a valid function argument number? is
that a string literal? etc), thus leaving only important
attribute-specific checks to be manually written.
This was always the goal. I wanted to unify parsing of arguments first, but
there's no reason in principle that handle*Attr couldn't go first, I think.
The whole purpose of this e-mail is to gather ideas regarding our needs for C++11 attributes parsing. Right now, only select attributes are parsed in C++11 style, attribute arguments parsing is not implemented, there's no common check for matching attribute targets ("Subjects" field in Attr.td). BTW, AFAIK, the latter is not implemented for GNU-style attributes either.
Currently, I see the following questions:
1. will we allow c++11 syntax for existing GNU attributes?
Probably not. If we do, there's a potential for collision with attributes introduced by the committee. It doesn't seem to have any benefits except giving users a prettier syntax for writing code that is totally unportable between compilers.
2. what new attributes do we expect to appear in c++11 syntax?
Impossible to say; it depends on the committee.
3. will they require late parsing of parameters?
Unlikely, but possible.
4. do we need common code for checking attribute subjects? (currently, subjects are checked in handle.*Attr functions)
The C++11 attributes do put things into a namespace, so it's possible to make [[clang::magic_attr]]. The committee also appears to imply that vendors should move from using things like __attribute__ to the C++11 stuff (N2671 gives examples that have ibm::, gnu::, etc. in places).
My opinion is to put any new attributes we want to include in C++11 attributes with a clang:: prefix. As for migrating pre-existing GNU-style attributes, the best answer is to wait and see what gcc will do.
It would be very helpful to tablegen-ized SemaDeclAttr for those adding a lot of non-standard attributes to Clang
The handleAttr contains both generic semantic checks like arguments and subjects and for some attributes it also contains attribute specific semantic checks. Assuming the generic checks are generated by tablegen, I am curious on how to combine these generated code with hand written attribute specific checks in one single function handleAttr.
Or instead of one handleAttr there could be a new handleAttrGenericChecks that is generated by tablegen (along with the big switch statement in ProcessInheritableDeclAttr) and the handle*Attr would only contain hand written attribute specific semantic checks?
To summarize, at the moment we have several major requirements for c++11 attribute parsing:
all boring attribute subject checks should be automated (using either TableGen or a static code if this is possible);
automated argument parsing (Sean Hunt planned to do this);
custom attributes can be added by plugins (Joshua Cranmer has a patch);
late parsing for attribute arguments? (currently no evidence that this will be necessary, this would be definitely required, if we decide to add c++11 syntax for gcc-style attributes);
Should we be concerning ourselves with Microsoft's attribute
(C++ Attributes Reference | Microsoft Docs),
__declspec attribute, or type attribute parsing and semantics? Or is
that outside the scope of what you're looking to do?
> The whole purpose of this e-mail is to gather ideas regarding our needs
for C++11 attributes parsing. Right now, only select attributes are parsed
in C++11 style, attribute arguments parsing is not implemented, there's no
common check for matching attribute targets ("Subjects" field in Attr.td).
BTW, AFAIK, the latter is not implemented for GNU-style attributes either.
>
> Currently, I see the following questions:
> 1. will we allow c++11 syntax for existing GNU attributes?
Probably not. If we do, there's a potential for collision with attributes
introduced by the committee. It doesn't seem to have any benefits except
giving users a prettier syntax for writing code that is totally unportable
between compilers.
I think there are a very few specific GNU attributes that we should support
in either syntax: ones that are really Clang attributes but happen to be in
GNU syntax currently:
- Thread safety attributes
- Some of the LLVM attributes such as readnone
- Attributes with very active users that would specifically benefit from
the improved syntax of C++11 attributes: format string, non-null, and other
argument-related attributes which are of particular use to static analysis
tools built in and around clang.
That said, I don't think even these would ever be directly ported. We would
naturally use the new name spacing utility to pave the way for increased
portability. I would also assume this would be used as a good opportunity
to re-think any syntactical problems we've hit over the years, and maybe
talk to GCC folks to come up with an agreed-upon set of common names for
those likely to be supported in both compilers (format string, non-null,
etc).
> 2. what new attributes do we expect to appear in c++11 syntax?
Impossible to say; it depends on the committee.
> 3. will they require late parsing of parameters?
Unlikely, but possible.
The thread safety attributes at the least would benefit from this, and
there is definitely a desire to migrate those to C++11 syntax on our end.
Putting an attribute on a parameter declaration is exactly the same with GNU attributes as with C++11 attributes. The actual problem here is that these attributes, by design, are currently placed on the function with an awkward mapping back to parameter indexes. You could certainly come up with a different design in which these attributes are placed on the parameter, but doing that isn’t really inherent to migrating to C++11, and I suspect that the wider community would be a lot happier if we didn’t tie that feature somewhat randomly to C++11.
That said, I don’t really have a problem with exposing attributes in both syntaxes as long as they’re namespaced appropriately.
> To summarize, at the moment we have several major requirements for c++11
> attribute parsing:
> 1. all boring attribute subject checks should be automated (using either
> TableGen or a static code if this is possible);
> 2. automated argument parsing (Sean Hunt planned to do this);
> 3. custom attributes can be added by plugins (Joshua Cranmer has a
patch);
> 4. late parsing for attribute arguments? (currently no evidence that this
> will be necessary, this would be definitely required, if we decide to add
> c++11 syntax for gcc-style attributes);
> 5. automated pretty-printing.
>
> Did I forget anything?
Should we be concerning ourselves with Microsoft's attribute
(C++ Attributes Reference | Microsoft Learn),
__declspec attribute, or type attribute parsing and semantics? Or is
that outside the scope of what you're looking to do?
The main reason of this topic was to figure out requirements for C++11
attribute parsing, but some of the things we discussed (attribute subject
checks, common argument checks) are applicable to handling all kinds of
attributes. So, wherever it is possible to make code work for all attribute
styles for free, I think, we'll try to do so.
I had sent this before, but it likely got lost in the mix:
Should we be concerning ourselves with Microsoft's attribute
(C++ Attributes Reference | Microsoft Docs),
__declspec attribute, or type attribute parsing and semantics? Or is
that outside the scope of what you're looking to do?
Sorry about that. Then yes,