This patch fixes <a href="http://llvm.org/bugs/show_bug.cgi?id=11109">pr11109</a>, a crash-on-invalid with the following source:<br><br>class foo { public<br><br>Matthias who reported the bug was nice enough to provide a basic fix (though only attached it to the bug rather than emailing cfe-commits, so it went unnoticed) but I've fixed up a few more things around here:<br>
<br>The original code was trying to consume the token following the access specifier, this is what caused the crash in the above case*. I assume the reason it was doing this was to catch the common case where a semicolon is written instead of a colon. So to address this I special cased that - FixIt replacing the semicolon with a colon (see class E in the attached test). But in the general case, consuming this token just lead to bad error recovery (see the comments for class D in the attached test) - "class foo { public int i; };" would fail once for the missing colon, then again for the missing type specifier for the declaration of 'i' because the 'int' had been erroneously consumed while looking for a colon).<br>
<br>Please let me know if this looks good and I'll check it in and resolve the bug,<br><br>- David<br><br>* since the token was eof - consuming when you're already at the end of 
the real top level file causes the preprocessor to call a function on a 
null pointer on Preprocessor.h:582. Perhaps we could add some asserts to check that the current lexer (whichever one it is) is non-null when trying to lex. I tried adding an assert in Parser::ConsumeToken to test that the token being consumed was not eof, but that wasn't viable - apparently clang has some cases where it actually lexes magic eofs. (the last eof of the outer file cannot be consumed, as this test shows, and the inner eofs of any included files never make it out of Lex)<br>