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