On 07/08/2014 15:15, Aaron Ballman wrote: > On Thu, Aug 7, 2014 at 5:39 AM, Abramo Bagnara > <[email protected]> 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 > _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
