[cfe-dev] C++11 attributes parsing

Wed Jul 11 09:09:38 PDT 2012

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120711/3b488729/attachment.html>