inference trouble with recursive generics and raw types

Stephan Herrmann stephan.herrmann at berlin.de
Tue Nov 5 03:01:46 PST 2013


On 11/04/2013 05:38 PM, Dan Smith wrote:
> This is essentially the same issue that you reported on October 10, right?

I'm sorry, I thought these might be independent bugs for different
combinations of ingredients. Looking at the JDK bug it indeed looks
more like one general problem indeed.

In that case I only disagree with ranking that bug at P4.
We want to reject programs that can be compiled with all known compilers.
People won't like this, but perhaps this can be communicated as a task
connected to the migration from Java 7- to Java 8. OTOH, people already
have a Java 8 EA in their hands and don't see this migration task.
Is there a way we can coordinate this step between compilers and
ensure this happens clearly before shipping?

Here's a little statistic to show relevance of this issue:
from a particular test suite of ~8000 test cases, ~2000 currently
trigger type inference, 132 are failing, 97 trigger the situation
where inference tries to match a parameterized type against a raw type.
A _assume_ that most of these cases have been written in response
to various bug reports from users, reflecting occurrences in real
world software.


>> I see type inferencing regarding the invocation of read(..)
>> producing the following:
>> [...]
>> (d) incorporation of (b) and (c) yields this constraint:
>> ⟨Bar<Foo> <: Bar<P#0>⟩
>> (e) reduction on (d) yields this type bound:
>> P#0 :> Foo
>> [...]
>>
>> Is there a mistake in my derivation?
>
> Nope, I agree with your explanation (except step (e) should be an eq bound, not a lower bound).

Oops, really?

 From ⟨Bar<Foo> <: Bar<P#0>⟩, 18.2.3 creates ⟨Foo <= P#0⟩.
Since neither Foo nor P#0 are wildcards I see 18.2.3 producing ⟨Foo <: P#0⟩,
further reduced to the bound Foo <: P#0 because P#0 is an inference variable.

What am I missing?

thanks,
Stephan





More information about the lambda-spec-observers mailing list