c++: fix for saved_token_sentinelHEADtrunkmaster

In cp_parser_splice_spec_is_nns_p I didn't use saved_token_sentinel:
its rollback uses cp_lexer_previous_token so if we are the first token
in the file, there are no previous tokens so we crash.

It would be simple to just use the _safe variant of cp_lexer_previous_token
and be done with this.  But that's not how this worked out: I saw a new
-fcompare-debug FAIL with pr104025.C.  The problem is that at the end of
cp_parser_id_expression we have a saved_token_sentinel guarded by
warn_missing_template_keyword and in that spot lexer->buffer is NULL (so
cp_lexer_set_source_position_from_token would be skipped).  pr104025.C
is compiled twice, the second time with "-w -fcompare-debug-second".  So
the first time we don't _set_source_position back to where we were after the
_skip_entire_template_parameter_list (lexer->buffer is NULL) and the second
time we don't get to the saved_token_sentinel at all.  That left us with
different columns in the location:

  "pr104025.C":16:16 vs "pr104025.C":16:12

thus the -fcompare-debug FAIL.  I assume we don't want -fcompare-debug
to ignore the column location.  So we could just save input_location in
saved_token_sentinel instead of trying to recover it.  And then
cp_parser_splice_spec_is_nns_p can be simplified.

gcc/cp/ChangeLog:

	* parser.cc (struct saved_token_sentinel): Save input_location.
	(saved_token_sentinel::rollback): Restore input_location.
	(cp_parser_splice_spec_is_nns_p): Use saved_token_sentinel.  Refactor.

Reviewed-by: Jason Merrill <jason@redhat.com>

0 files changed, 0 insertions, 0 deletions