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.
