Re: Linemap force location and remove LINEMAP_POSITION_FOR_COLUMN (issue4801090)

[Dodji Seketeli <dodji at seketeli dot org>]

Gabriel Charette <gchare@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