This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Linemap force location and remove LINEMAP_POSITION_FOR_COLUMN (issue4801090)


On Thu, Aug 11, 2011 at 7:22 AM, Dodji Seketeli <dodji@seketeli.org> wrote:
> Hello,
>
> gchare@google.com (Gabriel Charette) a écrit:
>
>> diff --git a/gcc/c-family/c-opts.c b/gcc/c-family/c-opts.c
>> index 3227f7b..1af8e7b 100644
>> --- a/gcc/c-family/c-opts.c
>> +++ b/gcc/c-family/c-opts.c
>> @@ -1306,13 +1306,15 @@ c_finish_options (void)
>> ? ? ?{
>> ? ? ? ?size_t i;
>>
>> - ? ? ?cb_file_change (parse_in,
>> - ? ? ? ? ? ? ? ? ? linemap_add (line_table, LC_RENAME, 0,
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?_("<built-in>"), 0));
>> + ? ? ?/* Make sure all of the builtins about to be declared have
>> + ? ? ? ? BUILTINS_LOCATION has their source_location. ?*/
>> + ? ? ?line_table->forced_location = BUILTINS_LOCATION;
>>
>> ? ? ? ?cpp_init_builtins (parse_in, flag_hosted);
>> ? ? ? ?c_cpp_builtins (parse_in);
>>
>> + ? ? ?line_table->forced_location = 0;
>> +
>
> FWIW, Since libcpp already knows about the concept of a builtin macro,
> maybe we could add a "builtin_location" member to cpp_reader, as well as
> "builtin_location" parameter to cpp_init_builtins. ?cpp_init_builtin
> would then set pfile->builtin_location and _cpp_define_builtin would
> then make sure the builtins have that builtin_location.
>
> That way, each FE would just have to call
>
> ? ?cpp_init_builtins (parse_i, flasg_hosted, BUILTIN_LOCATION);
>
> for their builtin macros have the proper location. ?And the semantics
> would be clearer than what we'd get by setting a "magical"
> line_table->forced_location at that point.
>
> Just my 2 euro cents (that aren't worth much these days)
>

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.

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.

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

Gabriel


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]