Re: PR 15787 Poor error message with if and blocks

[Mark Mitchell <mark at codesourcery dot com>]

Manuel López-Ibáñez wrote:

> Well, in my testcase there is actually and 'if' previously to the
> else, what is missing is '}'. In that case, if we skip the 'else' and
> continue, we report:
> 
> gcc/testsuite/g++.dg/parse/else.C:8: error: 'else' without a previous 'if'
> gcc/testsuite/g++.dg/parse/else.C:13: error: expected `}' at end of input
> 
> Which is wrong, since there is a previous 'if' and we are not really
> expecting anything at end of input. 

It's not "wrong" per se; the statement the compiler is making is
accurate in that the "else" has no corresponding "if" (maybe
"corresponding" or "associated") is a better word that "previous"), and
as a programmer it tells you that the "else" on line 8 is confusing the
compiler.

The problem with error-recovery is that the compiler can't always guess
what you meant to do.  We can use various heuristics, but as long as
programmers can figure out what to fix relatively easily, we're doing
well enough.  We don't want to build in too many complicated heuristics
because we'll sometimes assume that the programmer meant to do one
thing, when they actually mean to do another, and that could be very
confusing.

For example, given:

  if (x) {
   (i == 3) f();
   else {
   }
 }

the problem probably isn't that the closing curly brace for the if is
missing -- rather, it's probably that there's a missing "if" in the
inner scope before (i == 3)!  But, diagnosing that is going to be hard.

So, I'd suggest we not try to get too clever.

> On the other hand, detecting whether we are in the body of an "if" or
> not would need a new field in cp_parser (or is there other way to
> check this?).

Yes.

> We currently have in_unbraced_linkage_specification_p,
> in_declarator_p, in_template_argument_list_p, in_statement,
> in_switch_statement_p,   in_type_id_in_expr_p, implicit_extern_c,
> translate_strings_p, and in_function_body. I think we could have
> in_if_body and detect the situation.

Yes, that would be the right way to do it.

> Do you think this would be overly complicated?

I think it would, but I think it is probably not that much of a win for
the user, and I think we would still want the else-without-if
diagnostic, so I would just implement that, and move on.  I wouldn't
necessarily reject a patch to do the more complicated thing, but I don't
really think it's worth it.

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713