On Sun, Aug 23, 2015 at 06:07:13PM +0200, Manuel López-Ibáñez wrote:
> linemap_position_for_loc_and_offset() tries to generate a location_t
> encoding a column offset from the current location, for example, point
> to a certain character inside a string. This is trivial to do when the
> new location "fits within" the map of the original location. However,
> it may happen that the (long) line corresponding to the original
> location is encoded in several maps, thus the new location should
> actually be encoded in a subsequent map from the original location.
> This patch detects this case and adjusts the map correspondingly.
>
> (This shows that the line-map representation is quite wasteful in this
> case, because line-maps always start at column 0. That is, map[0]
> highest location may encode up to line 8 column 80, then
> map[1]->start_location starts encoding at line 8 column 0. Thus, there
> are two location_t values that point to the same source location.)
>
> No new testcase since Marek found out this when tackling PR c/66415
> (https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00411.html). This
> change just fixes the column number.
>
> Bootstrapped & regtested on x86-64-linux-gnu.
>
> OK?
Ok, thanks.
Marek
