Re: Patch: PR 4509

[Per Bothner <per at bothner dot com>]

Tom Tromey wrote:

> This fixes PR java/4509.
> 
> There were a couple problems here:
> 
> * When generating bytecode, if the first part of a COMPOUND_EXPR
>   couldn't complete normally, we still generated bytecode for the
>   second part.


Well, normally the first part of a COMPOUND_EXPR can't complete
normally. the second part is unreachable, which is an error.
The only exception I know off-hand is the condition part of a
do-statement , which is what java/4509 is.  Perhaps we should not
use a COMPOUND_EXPR here.

You might add a comment that "this can only legally be unreachable
in the case of a do-while" or words to that effect.

> * When generating a LOOP_EXPR, there's no point in generating the
>   `goto' back to the beginning if the loop body can't complete
>   normally.


That seems reasonable.


> * When building a COMPOUND_EXPR, we weren't correctly computing
>   whether it can complete normally.  I think we have to take both
>   parts into account.


We do, since we emit an error if the first part doesn't complete
normally.

>   I'm not completely sure the new code is
>   correct, since I don't understand why the old code was written the
>   way it was.


I believe the reason was to avoid cascading error messages.  I.e. for:

   break;
   stmt1;
   stmt2;

we only want a single error message at stmt1, not another one at stmt2.
So your change here is only ok if you make sure this doesn't happen.
The goal is to complain about all cases of unreachable statements, no
cases where the code is valid, *and* avoid duplicate uninformative
error messages.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/