[cfe-commits] [Patch] Fix parser diagnostic on class specifiers following c++11 attributes

[Michael Han]

Hi Richard,

Thanks for the suggestions!

Attached updated patch. The parser now will parse C++11 attribute
specifiers, in the form of double squares that appear at all possible
syntactic locations following class-name in a class specifier (also before
or after 'final' keyword). In case of final keyword, I have not found a way
to classify the nature of the class specifier without using tentative
parsing. Also updated test cases.

I will look into fix-it in a separate patch.

Cheers
Michael

On Thu, Nov 15, 2012 at 10:32 PM, Richard Smith <richard at metafoo.co.uk>wrote:

> On Thu, Nov 15, 2012 at 10:33 AM, Michael Han <fragmentshaders at gmail.com>
> wrote:
> > Hi,
> >
> > Consider this code
> > class [[foo]] c [[foo]];
> >
> > Clang generates diagnostic like this:
> > error: an attribute list cannot appear here
> > class [[foo]] c [[foo]];
> >       ^~~~
> >
> > I think the first attribute is conforming, and it's the second attribute
> > that should be diagnosed.
>
> Yes, I agree that it would be better to point the diagnostic at the
> second attribute-specifier-seq (and ideally to say that it's in the
> wrong place, and offer a fixit...).
>
> > Attached the patch that fixes this.
>
> I don't think your approach here is going to work. This is valid:
>
>   class c {};
>   class c [[ ]] x;
>
> I believe your patch would treat 'class c' as a declaration in the
> second line, which it is not.
>
> In order to correctly handle this, I suggest you parse attributes
> after the class name as well as before it, before trying to classify
> the reference. If you then find that it's a TUK_Reference, return the
> attributes you found after the class name to the caller, for them to
> handle appropriately. Otherwise, produce a diagnostic indicating that
> they were written in the wrong place (offering a fixit would be
> awesome...). For a class definition, you should probably look for
> attributes both before and after the optional 'final'.
>
> Thanks for looking into this!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20121118/a85e336c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: attr-diag-ds.patch
Type: application/octet-stream
Size: 7291 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20121118/a85e336c/attachment.obj>