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

[Vicente Romero]

I think that given that there are raw types in the picture and that 
there is a workaround we should be fine going for the change,

Vicente

On 4/10/19 1:03 PM, 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/0844c111/attachment-0001.html>