Re: -ftree-check for review

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Nic" == Nic Volanschi <nic.volanschi@free.fr> writes:

Tom> Ok... I hadn't read the details of the patch, so I did not realize
Tom> this.  This doesn't strike me as a very robust way to go.

Nic> What do you mean by robust? I can see several possible meanings:
[...]

Nic> 2) it critically relies on the dumper, so when changing the AST,
Nic> the dumper has to be modifier accordingly. That's true, but
Nic> anyways the dumper needs to be in sync with the AST, otherwise
Nic> it's no more useful to its first function - debugging. Stressing
Nic> the dumper might be a way to see this very quickly.

This is what I meant.  This approach turns the dumper from something
that is a convenience to GCC developers to something that is required
for proper operation of other parts of GCC.  So, that's surprising.

Nic> 3) it doesn't warn you if you provide incorrect C
Nic> patterns. That's probably what you meant, didn't you? That's also
Nic> right, and I clearly recognize that this is the main disadvantage
Nic> of unparsed patterns wrt parsed patterns.  However, what will
Nic> happen? These patterns simply won't match anything, but you will
Nic> not get any nasty error.

Thanks for bringing this up.  This also does seem like a possible
problem, since doesn't it mean that errors of various kinds can't be
caught?  I'm thinking in particular that a change to GCC in this area
might invalidate a user's script -- which could go unnoticed.  Or, a
user could have an incorrect script but not ever see a diagnostic
about it, leading him to believe that the check is working when in
fact it is not.

I guess this goes back to having a solid definition of the condate
language and a somewhat strict parser.


Please realize that I can't approve or reject your patch.  I'm trying
to understand what this is about, and presenting my view about
potential problems, since I see this as more than a mere patch but
really a major new user-visible addition -- and consequently a
potential major new maintenance burden.  In any case the reviewer,
whoever that may be, is who you must please -- not me.  HTH.

Tom