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