[cfe-dev] C++11 attributes parsing
aaron at aaronballman.com
Wed Jul 11 08:52:43 PDT 2012
I had sent this before, but it likely got lost in the mix:
Should we be concerning ourselves with Microsoft's attribute
__declspec attribute, or type attribute parsing and semantics? Or is
that outside the scope of what you're looking to do?
On Wed, Jul 11, 2012 at 11:43 AM, Alexander Kornienko <alexfh at google.com> wrote:
> Once again with updates from Chandler:
> At the moment we have several major requirements for c++11 attribute
> 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 (Chandler: "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");
> 5. automated pretty-printing.
> Did I forget anything?
> On Mon, Jul 9, 2012 at 1:43 PM, Alexander Kornienko <alexfh at google.com>
>> 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?
> On Mon, Jul 9, 2012 at 2:14 PM, Chandler Carruth <chandlerc at google.com>
>> On Fri, Jul 6, 2012 at 10:29 AM, John McCall <rjmccall at apple.com> wrote:
>>> On Jul 6, 2012, at 7:16 AM, Alexander Kornienko wrote:
>>> > 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.
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
More information about the cfe-dev