RFR: 8373094: javac may fail because of unattributed break in a loop

[Vicente Romero]

On Fri, 5 Dec 2025 16:32:43 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider a case like this:
> 
> package test;
> public class Intermediate<T> extends Base<T> {}
> 
> package test;
> public class Base<T> {
>     public void t(Missing<T> m) {}
> }
> package test;
> public class Missing<T> {}
> 
> this is compiled, and then `Missing` is deleted. Then a test file is compiled with the above classes on the classpath:
> 
> $ cat src/test/Test.java 
> package test;
> public class Test extends Intermediate<String> {
>     private void test() {
>         while (true) { break; }
>     }
> }
> $ javac -XDdev -XDshould-stop.at=FLOW -d classes -classpath classes src/test/Test.java
> src/test/Test.java:2: error: cannot access Missing
> public class Test extends Intermediate<String> {
>        ^
>   class file for test.Missing not found
> 1 error
> An exception has occurred in the compiler (25.0.1). Please file a bug against the Java compiler via the Java bug reporting page (https://bugreport.java.com) after checking the Bug Database (https://bugs.java.com) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you.
> 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.clearPendingExits(Flow.java:631)
>         at jdk.compiler/com.sun.tools.javac.comp.Flow$AliveAnalyzer.visitMethodDef(Flow.java:619)
> ...
> 
> 
> The reason is that the `CompletionFailure` will be thrown from `chk.checkCompatibleSupertypes(tree.pos(), c.type);`, and since that's before attributing the method bodies, the method bodies will remain blank. And hence the `break` will have no target set, and `Flow` will fail on it.
> 
> I spent some time trying to figure out if we could improve handling on `CompletionFailure`s more generally, so that we would not need to catch them on more-or-less arbitrary places. But everything I was able to do so far didn't really improve the situation. So the proposal herein is to catch and handle the `CompletionFailure` on some place.

lgtm

-------------

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28680#pullrequestreview-3546716029