This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [C++ Patch] PR 69793 ("ICE on invalid code in "cp_lexer_peek_nth_token"")


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]