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

[Vicente Romero]

looks good,

Vicente

On 4/17/20 3:47 PM, Jan Lahoda wrote:
> 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
>>