Nasty parsing bug?

[Aaron Ballman]

On Thu, Aug 7, 2014 at 9:30 AM, Abramo Bagnara <abramo.bagnara at gmail.com> wrote:
> On 07/08/2014 15:15, Aaron Ballman wrote:
>> On Thu, Aug 7, 2014 at 5:39 AM, Abramo Bagnara
>> <abramo.bagnara at bugseng.com> wrote:
>>> In the following source
>>>
>>> enum e { a };
>>> enum e __attribute__((unused)) x;
>>> enum e
>>> __attribute__((unused)) y;
>>>
>>> the declaration of x is parsed without errors, but the declaration of y
>>> gives a parse error i.e. the presence of the newline makes a difference (!)
>>>
>>> Indeed I cannot imagine a reason why the parsing should be influenced by
>>> token position.
>>>
>>> Opinions anyone?
>>
>> Both are illegal parses -- a GNU-style attribute cannot appear in that
>> location.
>
> Hmmm... but GCC compiles the source without any warning...
>
> Do you mean it is an undocumented feature of GCC or a GCC bug?

Undocumented feature, as far as I can tell. That would attach the
attribute to the enum e type based on position, but it seems to
appertain to the declaration instead.

But if GCC accepts this, we may want to consider implementing it as
well if there's sufficient reason.

>
>> The reason the behavior differs is in ParseEnumSpecifier,
>> around line 3667; we notice that the declaration isn't valid, and
>> guess that it's because it's missing a semicolon at the end of the
>> forward reference to enum e. This happens because __attribute__ is at
>> the start of the line for your third case. For your second case, we do
>> not perform the error recovery because __attribute__ is not at the
>> start of the line.
>
> I think that it might be ok to use isAtStartOfLine() to differentiate
> between two different diagnostic, but to use to decide if a source is
> invalid or not seems very wrong to me.

It's not determining validity of the source, it's attempting to
recover from a syntax error of source that's been determined to be
invalid.

~Aaron