Change in inference behaviour after JDK-8078093

Maurizio Cimadamore maurizio.cimadamore at
Fri Jan 15 22:25:16 UTC 2016

Hi Liam,
it's likely a regression in handling of unchecked calls introduced by 
that fix.

On a closer look, the problem seems to be caused by the fact that the 
code in Attr::checkMethod reuses the same Warner object (a problem that 
keeps biting us :-() - as the new code shares more state than the 
previous speculative-based implementation, the compiler ends up 
resetting the Warner when checking 'destination.get()' so that the 
compiler loses track of the fact that it had already encountered an 
unchecked warning during the applicability check of the first argument 
(Class <: Class<L>) - subsequently, the call is not flagged as 
unchecked, and a spurious inference error is then thrown.

I will fix it.



On 15/01/16 19:48, Liam Miller-Cushon wrote:
> It reproduces in jdk9-dev at head, and bisects to the fix for 
> JDK-8078093 [1][2]. Earlier versions of javac do not report the error. 
> Is this a bug?
> === ===
> abstract class Test {
>   interface One {}
>   interface Two<I extends One> { I get(); }
>   interface Three<T> {}
>   interface Four<T> {}
>   <E extends Two<?>, L extends Three<E>> Four<L> f(Class raw, E 
> destination) {
>     return g(raw, destination.get());
>   }
>   abstract <I extends One, E extends Two<I>, L extends Three<E>> 
> Four<L> g(
>       Class<L> labelClass, I destinationId);
> }
> ===
> $ javac
> error: incompatible types: inference variable I has incompatible bounds
>     return g(raw, destination.get());
>             ^
>     equality constraints: CAP#1
>     lower bounds: One
>   where I,E,L are type-variables:
>     I extends One declared in method <I,E,L>g(Class<L>,I)
>     E extends Two<I> declared in method <I,E,L>g(Class<L>,I)
>     L extends Three<E> declared in method <I,E,L>g(Class<L>,I)
>   where CAP#1 is a fresh type-variable:
>     CAP#1 extends One from capture of ?
> 1 error
> [1]
> [2]

More information about the compiler-dev mailing list