[cfe-dev] C++11 attributes parsing

[Aaron Ballman]

Ahh, now my mail client catches up.  ;-)  Sorry about that.  Then yes,
this sounds great to me,

~Aaron

On Wed, Jul 11, 2012 at 12:09 PM, Alexander Kornienko <alexfh at google.com> wrote:
> I've already replied to your e-mail:
> http://lists.cs.uiuc.edu/pipermail/cfe-dev/2012-July/022884.html
>
>> 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.
>
>
> On Wed, Jul 11, 2012 at 5:52 PM, Aaron Ballman <aaron at aaronballman.com>
> wrote:
>>
>> I had sent this before, but it likely got lost in the mix:
>>
>> Should we be concerning ourselves with Microsoft's attribute
>> (http://msdn.microsoft.com/en-us/library/f520z3b3(v=vs.110).aspx),
>> __declspec attribute, or type attribute parsing and semantics?  Or is
>> that outside the scope of what you're looking to do?
>>
>> ~Aaron
>>
>> 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
>> > 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 (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>
>> > wrote:
>> >>
>> >> 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>
>> > wrote:
>> >>
>> >> 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.
>> >
>> >
>> >
>> > --
>> > Regards,
>> > Alexander
>> >
>> > _______________________________________________
>> > cfe-dev mailing list
>> > cfe-dev at cs.uiuc.edu
>> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>> >
>
>
>
>
> --
> Alexander Kornienko | Software Engineer | alexfh at google.com | +49 151 221 77
> 957
> Google Germany GmbH | Dienerstr. 12 | 80331 München
>