conservativeUninferredTypeArguments on 2.10.1 causes incompatible type errors

[neilccbrown]

I have some issues with -AconservativeUninferredTypeArguments on the checker framework 2.10.1 that show up for example with streams and collectors. Here is a very simple class:

import java.util.List;
import java.util.stream.Collectors;
import java.util.stream.Stream;

public class Streaming
{
    public static void example()
    {
        List<String> listA = Stream.of("A").collect(Collectors.<String>toList());
    }
}

If I run this on 2.10.1 (JDK 8u144) with the Nullness checker and -AconservativeUninferredTypeArguments I get:

Streaming.java: [assignment.type.incompatible] incompatible types in assignment.
  found   : @UnknownKeyFor ? extends @UnknownKeyFor List<@UnknownKeyFor String>
  required: @UnknownKeyFor List<@UnknownKeyFor String>

I struggle to understand the issue with the error. I read it as: "you want to assign to A, but you have a subclass of A"; this should be fine shouldn't it? Similarly if I suppress the keyfor warning, I instead get:

Streaming.java: [assignment.type.incompatible] incompatible types in assignment.
   found   : @Initialized @NonNull ? extends @Initialized @NonNull List<@Initialized @NonNull String>
   required: @UnknownInitialization @Nullable List<@Initialized @NonNull String>

Again I think that the first type should be able to be used as an assignment to the second. I'm willing to add a further annotation if that is what would solve it, but I can't see what annotation would solve this error.

Some further notes: I already provide the generic type to the toList class to get it compiling with conservativeUninferredTypeArguments on earlier versions. I initially wondered if this could be solved by providing an explicit type to the collect function, but I can't type this function because the second parameter to collect can't be specified (it's hidden by the definition of toList) unless maybe I add a generic helper function, which seems a very long way round. From the error message alone it does feel like it might be a regression in the type checking.

I tried with 2.10.0 and it compiles fine (as it did in earlier versions), so whatever changed to cause this was in 2.10.1 specifically.

[smillst]

-AconservativeUninferredTypeArguments has been removed and this test case type checks.