RFR: 8293348: A false cyclic inheritance error reported

Vicente Romero vromero at openjdk.org
Wed Sep 7 18:25:45 UTC 2022

On Mon, 5 Sep 2022 16:10:54 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider these two classes:
> non-sealed interface T2 extends T {}
> sealed interface T permits T2 {}
> With a bit non-standard set-up, it may happen that:
> - as part of `TypeEnter.HierarchyPhase`, `Check.checkNonCyclicInternal` is called for `T2`,
> - that will mark T2 as LOCKED, and call `checkNonCyclicInternal` for its supertype `T`, which is uncompleted,
> - `T` will be completed, so `TypeEnter.HierarchyPhase` will be called for it,
> - `TypeEnter.HierarchyPhase` for `T` will try to attribute the permitted types of `T`,
> - that will invoke `Check.checkNonCyclicInternal` for `T2` again,
> - but the class is already locked, and hence a cycle error is produced.
> The proposed solution is to defer permitted type handling to a later point in time, specifically to the `HeaderPhase`. The `HierarchyPhase` should only handle the type hierarchy (i.e. the supertypes of a given type), and should not handle cycles. Hence the `HeaderPhase` seems like a better place to handle the permitted types, similarly to type variable bounds handling.
> Setting `isPermittedExplicit` is moved to `Enter` - seems the value of the flag can be inferred easily from the AST node, and can simply be used later.

looks sensible


Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10171

More information about the compiler-dev mailing list