On Wed, 2016-05-18 at 17:05 +0200, Paolo Carlini wrote: > Hi, > > On 18/05/2016 16:39, Jason Merrill wrote: > > On 05/17/2016 04:47 PM, Paolo Carlini wrote: > > > this ICE during error recovery exposes a rather more general > > > weakness: > > > we should never call cp_lexer_peek_nth_token (*, 2) when a > > > previous > > > cp_lexer_peek_token returns CPP_EOF. > > > > Hmm, that seems fragile, I would expect it to keep returning EOF. > Indeed. I didn't explain myself well enough. I meant something along > the > lines: outside this specific and minor case of ICE during error > recovery, we should audit our code and keep in mind that calling > cp_lexer_peek_nth_token (*, anything > 1, the common case) right > after > cp_lexer_peek_token is, how shall I put it, "suspect", due to that > assert at the beginning of cp_lexer_peek_nth_token.
Thinking aloud, I wonder if a plugin could detect this kind of thing? - verify that any call of cp_lexer_peek_nth_token for N > 1 happens after the result of cp_lexer_peek_token has been checked for EOF. (another idea might be a fault-injection option for the C++ frontend, perhaps simulating EOF at a given token index, and then using this, somehow, to torture-test the existing test cases, but that seems like a *lot* of extra parsing; static checking seems more efficient).