Nasty parsing bug?

Aaron Ballman aaron at aaronballman.com
Thu Aug 7 06:15:06 PDT 2014


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

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

HTH!

~Aaron



More information about the cfe-commits mailing list