resolving several ivars to the same capture?
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Thu Oct 23 15:10:23 UTC 2025
On 23/10/2025 15:53, Maurizio Cimadamore wrote:
>>> Yes, but that means that we will generate “spurious” capture
>>> variables during inference which will end up in the result.
>>> Depending on the case, this might result in failures.
>>
>> define "spurious"! 🙂
> I think Dan has explored this topic in more details and might have
> more examples of when the extra captures generated during
> incorporation might lead to bad inference results. I'll leave this
> with him.
Actually, here's a possible example:
class Test {
static class A<X> { }
static class B<X> { }
static class C<X> extends B<X> { }
static <Z> void m(A<? extends B<Z>> a) { }
static void test(A<C<?>> a) {
m(a);
}
}
Here we run the subtyping check:
A<C<?>> <: A<? extends B<Z>>
Which leads to
C<?> <: B<Z>
C<#CAP1> <: B<Z>
Which leads to
Z == #CAP1
Ok, so the inferred type for m's parameter is A<? extends B<#CAP1>>
But is our actual argument (A<C<?>>) compatible with that? Let's check
A<C<?>> <: A<? extends B<#CAP1>>
Which leads again to:
C<?> <: B<#CAP1>
C<#CAP2> <: B<#CAP1>
false
Since we capture _again_, we end up with _two_ capture variables,
incompatible with each other.
So, inference was able to get to some kind of solution, but
unfortunately the inferred type is not compatible with the actual
argument we started with.
Maurizio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20251023/48203134/attachment-0001.htm>
More information about the compiler-dev
mailing list