Gabriel Charette <gch...@google.com> a écrit:
> Actually from my understanding, highest_location is not equal to the
> last start_location, but to the last source_location returned by
> either linemap_line_start or linemap_positition_for_column (which is
> >>= to the start_location of the current line_map).
Right, it equals the highest location yielded by any map in the system.
Sorry.
>
>> 2/ The line number of the location
>>
>> 3/ The column number of the location
>>
>
> Right, that's what I mean, I would not actually stream
> highest_location. What I meant by they "all depend on only
> highest_location" is that IF highest_location is the same in file B.c
> and in a different compiled file C.c when they happen to include A.h,
> then all of the source_locations for the tokens in A.h (in both
> compilation) would be identical (i.e. token1's loc in B == token1's
> loc in C, etc.) (as 2/3 always is the same since we're talking about
> the same file A.h in both compilation, hence if 1 also holds, we get
> the same result).
>
Oh, OK.
>> > (i.e. if in two different contexts we happen to have the same
>> > line_table->highest_location when inserting header A.h, all of the
>> > tokens for A.h in each context will have the same source_location).
>>
>> Each token coming from a given A.h will have a different
>> source_location, as they will presumably have a different {line,column}
>> pair.
>>
>
> What I meant is that all of the source locations handed out in the
> first compilation will be the same as all of the source locations
> handed out in the second compilation, pairwise (not that ALL token's
> source locations themselves will be the same within a single
> compilation of course!).
>
OK.
>> If in two different contexts we happen to have the same
>> line_table->highest_location, the line_map::start_location of the two
>> different line maps of the two different A.hs will be equal, though.
>>
>> > If the previous statement is true, then we calculate an offset
>> > between the line_table->highest_location as it was in the serialized
>> > version of the header and as it is in the C file in which we are
>> > about to de-serialize the line table.
>> >
>> > We then need to update some things based on that offset:
>>
>> [...]
>>
>
> Hence, given that they only depend on start_location, I just have to
> calculate an offset between the serialized start_location and the
> start_location as it would be (highest_location + 1) in the C file
> including the header, and offset all of the source_locations on each
> token coming from the pph (without even needing to recalculate them!).
>
That could work. But then you'd need to do something for a map encoding
the locations of tokens coming from the pph to appear in line_table,
right? Otherwise, at lookup time, (when you want to find the map that
matches the source_location of a token coming for that pph), you'll be
in trouble. I am saying this b/c you are not calling linemap_line_start
anymore. And that function was the one that was including the said map
to line_table. And the map still must be inserted into line_table
somehow.
>> It seems to me that you could just set the line_map::start_location of
>> the de-serialized map for the current portion of A.h to the current
>> line_table->highest_location of the main CU your are currently parsing
>> (i.e, just forget about the serialized line_table->highest_location
>> into account. Actually I would think that it's unnecessary to
>> serialize the line_table->highest_location) + 1.
>>
>> Then you should also set the de-serialized line_map::to_line to the
>> current line in your context. Then you should add that line map to
>> the current line_table and set line_table->highest_location to the
>> line_map::start_location you have just computed.
>>
>> Then, assign the source_location of each token that belongs to that
>> de-serialized map to a source_location that is handed out by your new
>> linemap_position_for_line_and_column, with de-serialized map passed in
>> argument. This is where you would progress "backward" in the token
>> stream, for that given map.
>>
>> Then somehow, when you need to suck in a new pph (so this time you are
>> going downward in the stream again), just start this dance of
>> de-serializing the map for that new pph, updating its properties,
>> adding it to line_table, and setting the source_location of the tokens
>> coming for that pph again.
>>
>
> Doing it this way (with the offset) I would read in all the tokens and
> linemap entries inherited from that header and it's underlying include
> tree, thus no need to be tricky about inserting line tables for the
> header's included file, as they are part of the header's serialized
> line_table by recursion (a pph'ed header can include other pph'ed
> header),
This is what I am not sure to understand. There is only one line table
per CU. The headers included by the CU generate instances of struct
line map that are inserted into the line table of the CU. So I don't
understand what you mean by "header's serialized line_table", as I don't
think there is such a thing as a header's line_table.
--
Dodji
