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?
Background information follows in case I missed something. Many thanks.
--jkl
Background:
The lexer change affects only the lexer's idea of location, not
gcc's. To quell "dangerous trailing context" warnings, we match the
whole pattern (which may include new lines), and then surrender for
rescanning that part that is indeed trailing context. Instead of
r/s
we have
rs
where r and s are regex expressions. In the first case the lexer
treats s as "trailing context" and sets its location to match r. In
the 2nd case, r and s are concatenated and the lexer's location
initially matches them as a whole. The scanner uses yyless to return s
to the input stream, and trims the lexer's location to match r.
None of that is supposed to matter because it's done before we update
the gcc linemap. We don't call linemap_line_start and friends until
the parser gets ahold of the lexer's location. By that time of course
the lexer is done making its adjustments.
[end]
