RFR: JDK-8243047: javac may crash when processing exists in class initializers

[Jan Lahoda]

Oops, sorry for that! Fixed here:
http://cr.openjdk.java.net/~jlahoda/8243047/webrev.01/

A diff from previous:
http://cr.openjdk.java.net/~jlahoda/8243047/webrev.delta.00.01/

Thanks,
     Jan

On 17. 04. 20 19:41, Vicente Romero wrote:
> Hi Jan,
> 
> The fix looks good, there seems to be an issue in the combo test though 
> at enum: Block, there is no difference in the arguments of STATIC and 
> INSTANCE and in the arguments of STATIC_INITIALIZER and INITIALIZER,
> 
> Thanks,
> Vicente
> 
> On 4/17/20 5:25 AM, Jan Lahoda wrote:
>> Hi,
>>
>> For code like:
>> ---
>> public class ExitInInitializer {
>>     {return;}
>> }
>> ---
>>
>> If javac is invoked like:
>> $ javac -XDshould-stop.at=FLOW -XDdev ExitInInitializer.java
>>
>> javac eventually crashes with:
>> java.lang.AssertionError
>>         at 
>> jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155)
>>         at 
>> jdk.compiler/com.sun.tools.javac.util.Assert.check(Assert.java:46)
>>         at 
>> jdk.compiler/com.sun.tools.javac.comp.Flow$AliveAnalyzer.visitMethodDef(Flow.java:558) 
>>
>>
>> The reason is that the the (invalid) "return" in the intializer is 
>> added to pendingExits, but not removed as the end of the initializer, 
>> and when analyzing method, javac checks pendingExits are empty.
>>
>> The proposed solution is to clear pendingExits at the end of 
>> initializers. The asserts that an error had to be reported for such 
>> exits is preserved, so there shouldn't be a danger of accidentally 
>> letting incorrect compilation pass.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~jlahoda/8243047/webrev.00/
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8243047
>>
>> How does this look?
>>
>> Thanks,
>>     Jan
>