Re: [Patch] Java: Definite [Un]Assignment Issues

[Per Bothner <per at bothner dot com>]

Ranjit Mathew wrote:

> The first three - 16.2.{9,10,11}-definite-unassign-pass-3 - existed before
> my patch and represent our decision to simplify the handling of loops w.r.t.
> definite [un]assignment. See the comment for the "case LOOP_EXPR" in
> check_init() in java/check-init.c for reference. Unless we want to change
> that decision, I recommend that we simply mark these as expected "failures".

I have no objection to "changing that decision", I just didn't think
getting this working was a priority.  I obviously would prefer that
we have it 100% correct.  I also prefer an implementation that is
both reasonably fast and reasonably simple.

I think implementing tests like the following need not be very
complicated:
  Assuming V is definitely unassigned before e, V is definitely
  unassigned after S.
Basically, you run the check_init an extra time, but with the variables
unassigned.  This is the "Assuming V is definitely unassigned" part.
You then intersect that result with the existing tests.  Complications
are suppressing spurious errors during the auxiliary test, plus handling
continue statements.  (Of course I haven't looked at this stuff in a
while, so I may be off track.)

> a. Surprisingly for me, we were not at all marking "blank final" local
>    variables that represent the entities for which the whole "definite
>    unassignment" brouhaha in JLS 2 Chapter 16 is about!
>
>    I define DECL_LOCAL_FINAL_IUD in java-tree.h that is similar to - in fact
>    the same as - DECL_FIELD_FINAL_IUD, that I use to mark final
>    local variables that are initialised in their declaration. This is
>    being done in declare_local_variables() in parse.y in my patch.

Why?  My quick and dirty tests seem to show that:
  final int x = 10;
and
  final int x;
  x = 10;
are handled the same way and both give the errors I'd expect.

Which testcase is wrong before your patch and correct after?

I'll get back to you on the check_bool_init patch.
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/