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.
One of my big worries is the memory consumption.
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.
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.
Jeff
