RFR: JDK-8222035: Unused variable declaration causes inference error

[Maurizio Cimadamore]

Thanks for testing Liam.

We will check if disabling the InferenceCOntext::min optimization 
affects the outcome in this example - if so then I think we have an 
issue. If not, then it looks like there was an issue before which now 
got fixed. In other words, the most important bit, in the context of 
this fix, is that there should be no behavior change introduced by the 
context optimization. If there is, we have to address it.

Maurizio

On 10/04/2019 18:03, Liam Miller-Cushon wrote:
> I did some testing and a found a single example where this fix rejects 
> code that was previously accepted. Is this change expected?
>
> (I don't have any concerns either way: this pattern is not common, it 
> involves rawtypes, and there's an easy work-around.)
>
> ```
> import java.util.Map;
> import java.util.function.Function;
> import java.util.stream.Collector;
> import java.util.stream.Stream;
>
> abstract class A {
>
>   abstract static class T<K> {
>     abstract String f();
>   }
>
>   abstract <E> Function<E, E> id();
>
>   abstract static class ImmutableMap<K, V> implements Map<K, V> {}
>
>   abstract <T, K, V> Collector<T, ?, ImmutableMap<K, V>> toImmutableMap(
>       Function<? super T, ? extends K> k, Function<? super T, ? 
> extends V> v);
>
>   ImmutableMap<String, T<?>> test(Stream<T> stream) {
>     return stream.collect(toImmutableMap(T::f, id()));
>   }
> }
> ```
>
> A.java:20: error: incompatible types: cannot infer type-variable(s) 
> T,K,V,E
>     return stream.collect(toImmutableMap(T::f, id()));
>                          ^
>     (argument mismatch; Function<A.T,A.T> cannot be converted to 
> Function<? super A.T,? extends A.T<?>>)
>   where T,K,V,E are type-variables:
>     T extends Object declared in method 
> <T,K,V>toImmutableMap(Function<? super T,? extends K>,Function<? super 
> T,? extends V>)
>     K extends Object declared in method 
> <T,K,V>toImmutableMap(Function<? super T,? extends K>,Function<? super 
> T,? extends V>)
>     V extends Object declared in method 
> <T,K,V>toImmutableMap(Function<? super T,? extends K>,Function<? super 
> T,? extends V>)
>     E extends Object declared in method <E>id()
> 1 error
>
> On Tue, Apr 9, 2019 at 2:24 PM Vicente Romero 
> <vicente.romero at oracle.com <mailto:vicente.romero at oracle.com>> wrote:
>
>     thanks,
>     Vicente
>
>     On 4/9/19 4:37 PM, Maurizio Cimadamore wrote:
>     > Looks good!
>     >
>     > Maurizio
>     >
>     > On 09/04/2019 18:17, Vicente Romero wrote:
>     >> Hi Maurizio,
>     >>
>     >> Thanks for your comments, please see the updated webrev at [1]
>     >>
>     >> Vicente
>     >>
>     >> [1] http://cr.openjdk.java.net/~vromero/8222035/webrev.01/
>     >>
>     >>
>     >>
>     >> On 4/9/19 12:56 PM, Maurizio Cimadamore wrote:
>     >>> Looks good - few comments:
>     >>>
>     >>> * there's an HashSet still used at line 404:
>     >>>
>     >>> Set<Type> deps = minMap.getOrDefault(t.qtype, new
>     >>> HashSet<>(Collections.singleton(t.qtype)));
>     >>>
>     >>> This should be fixed too.
>     >>>
>     >>> * In this statement:
>     >>>
>     >>>
>     ((UndetVar)asUndetVar(eq)).setInst(inferenceContext.asInstType(t));
>     >>>
>     >>> It would be better to cache the instantiated type outside the
>     loop
>     >>> since it doesn't change.
>     >>>
>     >>> Maurizio
>     >>>
>     >>>
>     >>> On 09/04/2019 17:51, Vicente Romero wrote:
>     >>>> Hi all,
>     >>>>
>     >>>> Please review fix for [1] at [2]. The issue is random and
>     very hard
>     >>>> to reproduce with a regression test. Apart from the use of
>     >>>> non-ordering preserving data structures, the root cause was
>     early
>     >>>> resolution of the inference context which was leading, in this
>     >>>> case, to inexact instantiation of some inference variables.
>     >>>>
>     >>>> Thanks,
>     >>>> Vicente
>     >>>>
>     >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8222035
>     >>>> [2] http://cr.openjdk.java.net/~vromero/8222035/webrev.00/
>     >>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190410/87000d98/attachment.html>