16002 – [3.4 regression] Strange error message with new parser (original) (raw)

Description Richard Biener 2004-06-15 15:31:15 UTC

void foo(void) { double Q *= 5.0; }

causes gcc 3.4 to print (same for mainline)

te.cpp: In function void foo()': te.cpp:3: error: expected primary-expression before "double" te.cpp:3: error: expected ;' before "double"

while 3.3.4 printed the clearly superior

te.cpp: In function void foo()': te.cpp:3: error: parse error before *=' token

EDG is even better

te.cpp(3): error: expected a ";" double Q *= 5.0; ^

Comment 1 Wolfgang Bangerth 2004-06-15 15:56:00 UTC

Hm, yes. In fact, the second line is not helpful at all, since if I insert a semicolon before the 'double', I of course get the same error as before ;-) This problem here seems so obvious that I would
rate it as low priority, though.

As a general remark: I believe that many of these dreaded "expected primary-expression before XXX" messages are so unhelpful because they wrongly state the context XXX. In this case, we are actually quite happy with what we see until we get to the *= operator. We certainly don't expect anything else before "double", everything is fine up to that point. I have no clue where this comes from, but it seems we should instead print the token where things start go wrong, not the first token of the expression. I think that this probably holds for a good number of the cases where we print this error message.

W.

Comment 2 Giovanni Bajo 2004-06-16 10:16:16 UTC

Not so easy, though. The parser tries several different constructs that can happen at statement level (function declaration, variable declaration, etc.). They are all equally possible, and they all fail at different tokens. So the error "expected primary expression before XXX", it actually means "starting from XXX, I could not find a valid primary expression".

In this case, I think we should consider the variable declaration to be OK even without ';' so that we emit a missing semicolon error, and then skip all the token till the end of the line.

Comment 3 Wolfgang Bangerth 2004-06-16 13:53:13 UTC

In this case, yes. In general: if we can't find a valid sequence of tokens starting somewhere, why don't we say "starting at XXX", rather than "before XXX"?

W.

Comment 4 Mark Mitchell 2004-07-17 07:39:01 UTC

The right thing to do here is to notice that after "double" -- not followed by a parenthesis -- there are no non-declaration alternatives. Then, we should commit to the tentative parse, and that would get us a better error message.

In other words, the improvement is to avoid backtracking in this case.

Comment 5 Mark Mitchell 2004-08-29 18:51:56 UTC

Postponed until GCC 3.4.3.

Comment 6 Mark Mitchell 2004-09-17 02:39:21 UTC

Working on a fix.

Comment 8 Mark Mitchell 2004-09-17 07:10:41 UTC

Fixed in 4.0, but will not be marked as fixed until backported to 3.4.

Comment 9 Ulrich Weigand 2004-10-05 16:30:21 UTC

It appears the test case for this bug (error18.C), but not the fix, was committed to the 3.4 branch, causing a test suite regression there. Was this intentional?

Comment 10 Mark Mitchell 2004-10-16 00:08:12 UTC

It was an accident that error18.C was committed on the branch. I've now removed it.

Comment 11 Mark Mitchell 2004-11-01 00:45:16 UTC

Postponed until GCC 3.4.4.

Comment 13 Giovanni Bajo 2005-07-28 10:24:14 UTC

Fixed also for GCC 3.4.5.