[PATCH 00/22] RFC: Overhaul of diagnostics

[David Malcolm]

On Mon, 2015-09-14 at 13:42 -0600, Jeff Law wrote:
> On 09/14/2015 11:43 AM, Bernd Schmidt wrote:
> > It's hard to provide meaningful review under these conditions. My advice
> > would be to resubmit the things that are ready now and can stand on
> > their own so that we can get them out of the way first. Also, gather
> > memory/time information before posting the patches if that seems likely
> > to be important. For example, patch 21 looks quite cool but also
> > potentially expensive, I'd probably want that to be restricted by param
> > to identifiers of a maximum length (for both identifiers being compared).
> I think David is looking for some feedback on some of this stuff. 
> There's clearly some design/implementation issues in those middling 
> patches.  The thought behind showing the later patches is so that folks 
> can generally see where this work is trying to go.

Indeed: my hope was that it would be helpful to see the kinds of
diagnostics I was hoping to be able to print, as that motivates both the
changes to diagnostics_show_locus, and efforts to try to capture and
store range information somehow within our IR.
I can post more screenshots if it will be helpful.

> One of my big worries is the memory consumption.

Yes.  Clearly the implementation I have in patch 12 isn't going to fly;
ideas welcome.   One thing I may try next is to only try to track the
ranges as the trees are constructed, immediately discarding them once
we've done that first level of error-checking... basically to not store
it beyond the frontends (for example to stuff it into c_expr in the C
FE).   That might be a useful compromise: hopefully letting us make a
lot of diagnostics more readable, without bloating the memory
requirements.  That's my hope, anyway :)


> > For the most part I declare myself agnostic as to whether this is an
> > improvement or not, and leave that for others to comment on. I
> > personally prefer single-line errors without much noise.
> I wasn't a fan of rich location diagnostics, carets, etc.  However, now 
> that I'm doing more C++ bits, I'm seeing the utility of this kind of stuff.

FWIW, I've mostly been holding off on adding ranges to the C++ FE in the
hope that the delayed folding branch will get merged soon (since
otherwise its unclear what to base the changes on); hence I only touched
a few places where token ranges were in use; I didn't attempt tree
ranges.

> > I see lots of unit tests implemented as plugins - have we decided that
> > this is the mechanism we want to use for this kind of thing?
> A lot of the plugin-based testing is stuff that's painful to test 
> end-to-end.  Probably the best way to think of those tests is they're 
> trying to directly test internal state.

Right.  The new plugins allow us to exercise the underlying machinery
unit by unit, and this is good for sanity (in particular, mine).

The unit tests in this patch kit use source code, which is going to be
the case for some tests, and fits neatly into the
gcc.dg/plugin/plugin.exp pattern, but not every test fits this pattern.

By contrast, if we want to e.g. verify that gengtype generates sane
mark&sweep routines, that doesn't necessarily need specific source code.
This latter style of test is what I was thinking of in the other patch
kit I posted here:
https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00765.html
("[PATCH 00/17] RFC: Adding a unit testing framework to gcc").
It's kind of a pain to write a plugin each time we poke at a data
structure,  and run it with an empty source file, so my thinking was to
consolidate those tests that simply exercise internal data structures
into a single unit-test plugin, and run all the tests within it.

In particular, my hope is that this style of test could (a) help us
track down bugs earlier [1] and (b) be dramatically faster: I want us to
be measuring e.g. how many 100s or 1000s of unit tests per second we can
run, rather than having to fork/exec subprocesses for just a few tests
each time.

(Though that's probably a different discussion).

Thanks for the comments.  Hope the above sounds sane.
Dave

[1] I *hate* tracking down gengtype bugs; I'm keen to give us direct
test coverage for the code it generates, so we can track down bugs
immediately, rather than with multi-hour gdb sessions...