Re: in search of squiggles

On Wed, Jul 22, 2026 at 7:00=E2=80=AFPM James K. Lowden <jklowden@cobolworx=
.com> wrote:
>
> How does the diagnostic system know how to highlight the offending
> term?
>
> Changes to our lexer that "should not" affect any
> messages leave some that occur at line endings no squiggles.
>
> The 3-line message, via global_dc->diagnostic_impl :
>
> prog.cob:20:17: warning: GROUP-2 and GROUP-1 have no corresponding fields=
 [-Wmove-corresponding]
> 20 | SUBTRACT CORRESPONDING GROUP-2 FROM GROUP-1.
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> is correct on our main branch, but has only two lines after my changes
>
> The linemap_dump_locations differ in their LOC component.
>
> main:
> {P:parser/UAT/testsuite.dir/417/prog.cob;
>  F:<NULL>;L:20;C:17;S:0;M:0xfffff7fad280;E:0,
>  LOC:3628322,R:3628322}
>
> dev:
> {P:UAT/testsuite.dir/417/prog.cob;
>  F:<NULL>;L:20;C:17;S:0;M:0xfffff7fad280;E:0,
>  LOC:3628288,R:3628288}
>
> How to decode LOC?  Is that, er, the key?    That is, does the diagnostic=
 framework use LOC to determine the position of the squiggly line?
>

There's a good amount of explanation in the comments at the top of
libcpp/include/line-map.h and also in the example file
libcpp/location-example.txt.  Those were both constructed when
location_t was a 32-bit int and have not been adapted since it was
moved to 64 bits, but they are still useful.

Diagnostics will underline a range if the provided location_t contains
range information. For sufficiently simple ranges, the range is
encoded in the lower bits (7 by default, if you don't change it) of
the location_t value.
"Sufficiently simple" means the range starts at the caret location and
the number of columns fits in the bits reserved for it. Other ranges
are represented by ad-hoc locations, which are a key into a lookup
table containing the range information. They are indicated by large
location_t values with bit 62 set.

In this case you can see your location_t contains range information in
"main", but not in "dev", since 3628288 has the low bits all clear and
is not an ad-hoc location.

It looks like cobol only assigns a location_t by calling
make_location(), which ends up in
line_maps::get_or_create_combined_loc() in libcpp/line-map.cc. This
function will always create either a compact range or an ad-hoc
location range, so I think most likely one of the parameters to
make_location() has changed and now token_start =3D=3D token_finish?

util.cc-   token_start  =3D linemap_position_for_column( line_table,
loc.first_column),
util.cc-   finish_line  =3D linemap_line_start( line_table, loc.last_line, =
80 ),
util.cc-   token_finish =3D linemap_position_for_column( line_table,
loc.last_column);
util.cc: token_location =3D make_location (token_start, token_start,
token_finish);

You may get something from the -fdump-internal-locations option for
debugging, to confirm that the line maps have been added in the
expected order after the new changes.

Also something that can be useful is to call e.g.

    inform(token_finish, "this is token_finish");

either in the code temporarily or from gdb, to get the diagnostics
system to show you exactly where each location is.

-Lewis