https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67192
--- Comment #12 from Patrick Palka <ppalka at gcc dot gnu.org> --- (In reply to Manuel López-Ibáñez from comment #10) > (In reply to Manuel López-Ibáñez from comment #8) > > Does GCC work at all if input_location is saved and restored in > > c_parser_peek_token? I guess not, it seems too much still relies in > > input_location being magically right. > > Perhaps you can add c_parser_peek_token_keep_input_location and use that > where you are peeking the next token. In the C++ frontend it looks like the entire file is lexed at startup and so the cp_lexer_peek_token method does not change input_location (since input_location is updated as a side effect of lexing a new token). Instead, the cp_lexer_consume_token method is responsible for updating input_location. In the C frontend it looks like the reverse happens: tokens are lexed on demand and so the c_parser_peek_token method does update input_location (as a side effect of lexing the next token) and c_parser_consume_token does not change input_location. Would it be a good idea to make the C frontend behave more like the C++ frontend w.r.t. updating input_location? The behavior of the C++ frontend seems more sensible to me. And I think such a change would fix this PR.
