PATH: check definite unassigment to final variables

Mon Dec 3 18:27:00 GMT 2001

Ok - here it is, what today's earlier patches have led up to.
The big patch to implement checking for assignment to final
variables (locals and fields) following the rules using the
concept of "definite unassignment" as defined in the second
edition of the Java Language Specification. Whew.
This means that code like the following should now work:
 final int fld;
 { if (foo()) fld = 1; else fld = 2; }
while the following will fail:
 final int fld;
 { if (foo()) fld = 1; }
Actually, we do violate the rules in at least one area: The
extra complication dealing with loop statements discussed in
the JLS. The JLS uses rules involving "hypothetical
assignment". This looked like being more painful than seemed
justified, so I implemented something simpler: Disallow
all assignments inside loops to finals declared outside it.
This might disallow some assignments that should strictly
speaking be allowed, but I don't think it matters.
As a bonus, we get rid of a bunch of code, with a net code-size
reduction of over 100 lines.
I haven't checked this in yet. I am doing one more boostrap and
check first. That will uncover at least one regression: With the
new algorithm libjava.compile/BlankFinal.java now fails where it
didn't use to. That is because the testcase is wrong - the compiler
really *should* reject the program. Tom, you checked the testcase
in - I don't know what you want to do about it - change it to a
"non-compile" testcase?
One more note: I temporarily disabled the static class
initialization optimization. I'll look into that next, but
I think it will be easier for me to figure out the exiting code
and how it needs to be fixed after checking these patches in.
-- 
	--Per Bothner
per@bothner.com http://www.bothner.com/per/
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: final.patch
URL: <http://gcc.gnu.org/pipermail/java/attachments/20011203/f47903de/attachment.ksh>