RFR: JDK-8215482: check for cycles in type variables can provoke NPE

[Maurizio Cimadamore]

It seems that another thing that your path is doing is storing all the 
type vars to check keyed by outermost class, so that only when you have 
finished entering the outermost symbol you actually start checking all 
pending typevars for cycles. I guess this delay is necessary otherwise 
you would hit a problem anyway when checking Bc for cyclicity?

Have you consider moving the attribution and cyclicity check in 
different type enter phases? For instance, leave attribution in 
HeaderPhase, but move the cycle check in MembersPhase ?

Maurizio

On 11/01/2019 16:47, Vicente Romero wrote:
> Please review the fix for [1] at [2]. The NPE showed up in code like:
>
> class Outer<A extends Outer.Inner, B> {
>     class Inner<Bc extends B> {}
> }
>
> here attribution of type variable `A` during type enter phase will 
> trigger attribution of class `Inner` while type variable `B` hasn't 
> been attributed yet and thus its bound is still set to null. A similar 
> problem arose a while ago see [3]. The issue provoking the current bug 
> is that checks for cycles in type variables are done as soon as the 
> type variable is attributed but in cases like the one above we can't 
> do that until the type variable for the outer class has been 
> attributed too.
>
> My first try was to create a fixup table that maps the outer type to 
> the list of type variables defined by it or its members that happen to 
> be types too, and once the compiler finish entering the outer class it 
> would be safe to check for cycles in all the concerning type 
> variables. I had a mild success here as there were some trivial cases 
> that were working before that started failing. I realized that it was 
> because the annotation processing phase was setting all the types to 
> null, no bueno. So I decided to clone the type variables to be stored 
> in the fixup table and do the cycle check on the clones which is what 
> the current patch is doing.
>
> Thanks,
> Vicente
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8215482
> [2] http://cr.openjdk.java.net/~vromero/8215482/
> [3] https://bugs.openjdk.java.net/browse/JDK-6660289
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190111/33f9b0b4/attachment.html>