This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 00/10] Overhaul of diagnostics (v5)
- From: David Malcolm <dmalcolm at redhat dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Fri, 23 Oct 2015 17:25:13 -0400
- Subject: Re: [PATCH 00/10] Overhaul of diagnostics (v5)
- Authentication-results: sourceware.org; auth=none
- References: <1442957171-22904-1-git-send-email-dmalcolm at redhat dot com> <1445632918-29617-1-git-send-email-dmalcolm at redhat dot com> <562AA2F8 dot 7040400 at redhat dot com>
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.