[PATCH 00/10] Overhaul of diagnostics (v5)

[David Malcolm]

On Fri, 2015-10-23 at 15:13 -0600, Jeff Law wrote:
> On 10/23/2015 02:41 PM, David Malcolm wrote:
> > This is a followup to:
> >    https://gcc.gnu.org/ml/gcc-patches/2015-09/msg01696.html
> > (one of the individual patches has seen iteration since that, so
> > I'm calling the whole thing "v5" for the sake of clarity).
> >
> >
> > Patches 1-3 are a preamble:
> >    "Improvements to description of source_location in line-map.h"
> >    "Add stats on adhoc table to dump_line_table_statistics"
> >    "libstdc++v3: Explicitly disable carets and colorization within
> >      testsuite"
> >
> > Patch 4:
> >   "Reimplement diagnostic_show_locus, introducing rich_location classes (v5)"
> > is an updated version of the rewrite of diagnostic_show_locus,
> > via the new rich_location class.  I believe this one is ready for trunk
> > and could be applied without needing the followup patches; I
> > have a followup patch that adds support for "fix it hints" on top
> > of this (PR/62314).
> >
> > Patch 5:
> >    "Add ranges to libcpp tokens (via ad-hoc data, unoptimized)"
> > implements token range tracking by adding range information to
> > the ad-hoc location table.  As noted in the patch, this generalizes
> > source_location (aka location_t) to be both a caret and a range,
> > letting us track them through our existing location-tracking
> > mechanisms, without having to add extra fields to core data structures.
> > The drawback is that it's inefficient. This is addressed by patch 10,
> > which implements a packing scheme to avoid the ad-hoc table for most
> > tokens.
> >
> > Patch 6:
> >    "Track expression ranges in C frontend"
> > is an updated version of the patch to add tracking of expression
> > ranges to the C frontend, using the above mechanism.
> >
> > Patch 7:
> >    "Add plugin to recursively dump the source-ranges in a tree (v2)"
> > is the test plugin to demo dumping the ranges for all
> > sub-expressions of a complicated expression.  It's unchanged since
> > previous versions.
> >
> > Patch 8:
> >    "Wire things up so that libcpp users get token underlines"
> > wires up the work from patches 4 and 5 so that most diagnostics
> > in frontends using libcpp will see some kind of underlining, for tokens
> > at least.
> >
> > Patch 9:
> >    "Delay some resolution of ad-hoc locations, preserving ranges"
> > tweaks things to provide underlines for some places that patch 8
> > missed.
> >
> > Patch 10:
> >    "Compress short ranges into source_location"
> > is the bit-packing optimization for patch 5.
> So was there a final resolution with PCH?  IIRC from our meeting PCH 
> blew things up by filling one of the tables.

I believe you're referring to a case I mentioned where I used 8 bits for
the bit-packed ranges, and this led to running out of bits for storing
columns in a C++ source file after loading the PCH for the stdlib
(reaching LINE_MAP_MAX_LOCATION_WITH_COLS before the user's source file
had started, iirc).

The patch kit now uses 5 bits for the bit-packed ranges, so there's 3
more bits for columns than in that case = 8 times more room.