Nasty parsing bug?

[Abramo Bagnara]

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?

> 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.

> 
> We could be a bit more friendly by attempting to parse the attributes,
> and diagnosing them as being prohibited in that location.
> 
> HTH!
> 
> ~Aaron
>