On Mar 26, 2012, at 1:56 PM, Steven Bosscher wrote:
> This patch is one way to address PR44982.
That's a great idea, I like it. There is only one problem that I know of that
prevents it from going in now. We emit errors/warnings from below finalize and
there is a feature in which we emit all the reasonable error and warning
messages that we can with one compile. There is a certain class of power user
that actually wants to see all the errors or warnings in a given compile, for
them, this is a feature. If you want to move the analysis for those to before
finalize, then I think this is a good way to fix the problem, until then I
think we should fix this in the normal way. The usual way to fix this would be
to find the bit that had the error_mark_node in it, and then do as much as you
can, but, then to bubble up error_mark_node or otherwise end processing.
> I see no good reason to cgraph_finalize_compilation_unit if there were parse
> errors.
It is actually a feature people use, even if you don't have any users or your
user base is too small to have ever met one. I have. The time the feature
allows to be saved, can be measured in days and weeks.
> it seems to me that those warnings are not very meaningful after parse errors
> (-Wuninitialized after a
> parse error??),
But you're wrong.
int f = &sdf;
main() {
int i;
printf("%d", i);
}
is a program that has parse errors and certainly, any and all the errors after
the first line that don't involve f in any meaningful way, are meaningful and
valuable to some people. I understand you don't see the value in them, that's
all right. They aren't valuable or meaningful to you, I get it. But, are you
willing to accept it when I assert that there is a class of people for which
this is a feature, they are meaningful and valuable?
> and errors from the middle end are mostly for exotic
> code (involving asm()s and the like). Bailing out after parse errors
> is therefore IMHO the right thing to do for the common case.
Some are for very exotic things, yes, but not all of them. Actually, I started
reviewing them, none of them seem that exotic to me. Take for example:
int f() { return this->i; } // { dg-error "" "no member named i" }
Really, exotic?
register int y; /* { dg-warning "file-scope declaration of 'y' specifies
'register'" } */
Again, I don't see the value in not giving the warning.
static int f2(void); /* { dg-error "used but never defined" } */
No exactly unheard of.
int x[]; /* { dg-warning "array 'x' assumed to have one element" } */
Gosh, seems reasonable.
hash_unique_table (size_t n, hasher, key_equal,
value_allocator & a):table (n, a) // { dg-error
"is not a direct base" }
This one I can see being nice to get with certain refactoring operations on
large code bases.
static_assert( I % 2 == 1, "I must be an odd number"); // { dg-error "odd
number" }
What, you mean my static_asserts are gonna go away, but we _liked_ them.
case low ... high : return i + 1; // { dg-error "previously" }
case 5 : return i + 2; // { dg-error "duplicate" }
duplicate case statements, awe... What's next?
void Look(W& w) { w.x = 3; } // { dg-error "private within this
context" }
Bye bye access control, I guess it was overrated.
I was going to go through them all, but I have to stop now, my stomach doesn't
feel well. I was only 38% of the way though them. Did you actually review
them, all of them?
What is so very wrong with fixing this in the normal way? I can envision
beefier analysis and code checking that runs very late in the compilation
process in order to get the most accurate analysis out of it. It seems
reasonable to permit that, even in the presence of parse errors, for all the
same reasons we want to see that a case statement was a duplicate, or that
something was never defined.
