RFR: 8320220: Compilation of cyclic hierarchy causes infinite recursion
Vicente Romero
vromero at openjdk.org
Mon Feb 24 15:26:01 UTC 2025
On Wed, 19 Feb 2025 18:15:51 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:
> This input currently causes an infinite loop:
>
> interface A extends B, C {}
> interface B extends A {}
> interface C extends A {}
>
> However, less complicated cycles are handled properly.
>
> When a cycle is found, we currently:
> (a) Emit a warning; and
> (b) Set the symbol's type to the error type.
>
> These two steps are done in `Check.noteCyclic()`.
>
> Step (b) is what normally prevents the infinite loop from happening later in the compilation. But we only do this for the first class in the loop, presumably because it would be too verbose to do (a) for every class in the loop. But that means we're also only doing (b) for the first class in the loop.
>
> In more complicated scenarios like the bug example, that means some classes in the cycle can escape without (b) being applied. But this is incorrect (or, at least, weirdly indeterminate) because a loop is a loop no matter which class you start with.
>
> So the solution is to continue to do (a) only to the first class in the cycle but do (b) for every class in the cycle.
src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 2380:
> 2378: seenClasses.stream()
> 2379: .filter(s -> !s.type.isErroneous())
> 2380: .filter(ClassSymbol.class::isInstance)
wouldn't a ClassSymbol method be better here like ClassSymbol::isSubClass?
src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 2381:
> 2379: .filter(s -> !s.type.isErroneous())
> 2380: .filter(ClassSymbol.class::isInstance)
> 2381: .map(ClassSymbol.class::cast)
this method will invoke Class::isInstance again, probably better to just do `(c -> (ClassSymbol)c)`?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/23704#discussion_r1967861336
PR Review Comment: https://git.openjdk.org/jdk/pull/23704#discussion_r1967865748
More information about the compiler-dev
mailing list