Gabriel Charette <gch...@google.com> a écrit:
> That could work given _cpp_lex_direct does receive a cpp_reader as a
> parameter. We would need to add logic in _cpp_lex_direct to support
> this new field.
Correct.
>
> As I mentioned, we have the same problem in pph where we need to force
> a location (i.e. the lexer is assigning new locations, but we don't
> want it to when we are replaying pre-processor tokens), so just a
> "builtin_location" field is potentially insufficient.
I see. So maybe a cpp_reader::forced_token_location, initialized to -1
rather than 0 (in case someone wants to force a location to
UNKNOWN_LOCATION, which is zero for the C/C++ FE at least). There would
then still be a new parm added to cpp_init_builtins, that would be the
value of the location of the builtin macros to build. cpp_init_builtins
would then just set cpp_reader::force_token_location to that value.
If the API you are using is the lexer and you want to force the location
of the tokens it's handing out, then I guess setting
cpp_reader::forced_token_location directly is OK, IMHO.
>
> Either way, a "magic" field in cpp_reader handled with logic in
> _cpp_lex_direct, or a "magic" field in line_table handled in
> linemap_position_for_column.
I guess what I was trying to say is that IMHO the line map module ought
to provide mechanisms for mapping line/column pairs to source locations.
The policy of how/if the source location is assigned to a token should
be left the code using the line map module. And that new field and the
logic governing it did sound like a adding policy there.
> I agree that the field in cpp_reader might be clearer as the logic is
> handled in _cpp_lex_direct, where we want the change to occur, not in
> some dark corner of libcpp (linemap_position_for_column).
Indeed.
--
Dodji
