PING: https://gcc.gnu.org/ml/gcc-patches/2015-08/msg01373.html
On 23 August 2015 at 18:07, Manuel López-Ibáñez <lopeziba...@gmail.com> 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? > > libcpp/ChangeLog: > > 2015-08-23 Manuel López-Ibáñez <m...@gcc.gnu.org> > > * line-map.c (linemap_position_for_loc_and_offset): Handle the > case of long lines encoded in multiple maps. > > > gcc/testsuite/ChangeLog: > > 2015-08-23 Manuel López-Ibáñez <m...@gcc.gnu.org> > > * gcc.dg/cpp/pr66415-1.c: Test column number.
