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

[Liam Miller-Cushon]

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>
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/2c7c06b8/attachment.html>