On 1/26/26 10:52 PM, Marek Polacek wrote:
On Sat, Jan 24, 2026 at 05:25:06PM +0800, Jason Merrill wrote:
On 1/22/26 6:17 AM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
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.
Agreed.
So this patch adds STS_ROLLBACK_SAFE to
use the _safe variant of cp_lexer_previous_token.
How about if safe_previous_token returns null then we use the current token
instead? I'd rather not add separate modes.
I also don't like adding a new mode. But using the current token leads
to the same -fcompare-debug FAIL with pr104025.C:
"pr104025.C":16:14 vs "pr104025.C":16:12
As before, once we don't do saved_token_sentinel at all, and the second time
we _set_source_position to something that doesn't match the previous position.
Ah, so the problem is that _safe_previous_ is incompatible with
cp_lexer_new_from_tokens because the latter sets buffer to null.
Perhaps instead it should set it properly and the condition in
cp_lexer_destroy should check saved_type instead of buffer.
Or we could just save input_location in saved_token_sentinel instead of
trying to recover it.
Jason
