lovubuntu / checker-framework

Automatically exported from code.google.com/p/checker-framework
0 stars 0 forks source link

Unexpected 'incompatible type' error with deferred types #329

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
# What steps will reproduce the problem?

Run the nullness checker over the following program:

===
abstract class Test {
  interface Flag<T> {}

  abstract <X> void setExtension(X value);
  abstract <T> T getValue(Flag<T> flag);

  void f(Flag<String> flag) {
    setExtension(getValue(flag));
  }
}
===

# What is the expected output? What do you see instead?

I expected the analysis to pass. Instead:

$ ~/jsr308/checker-framework-1.8.1/checker/bin/javac -version 
-XDverboseResolution=deferred-inference -processor 
org.checkerframework.checker.nullness.NullnessChecker Test.java

Test.java:8: Note: Deferred instantiation of method <X>setExtension(X)
    setExtension(getValue(flag));
                ^
  instantiated signature: (String)void
  target-type: <none>
  where X is a type-variable:
    X extends Object declared in method <X>setExtension(X)
Test.java:8: error: [argument.type.incompatible] incompatible types in argument.
    setExtension(getValue(flag));
                         ^
  found   : ? extends @Initialized @NonNull String
  required: ? extends X extends @Initialized @Nullable Object

# What version of the product are you using? On what operating system?

javac 1.8.0-jsr308-1.8.1
x86_64 GNU/Linux

# Please provide any additional information below.

I think it should be true that "? extends @Initialized @NonNull String" <= "? 
extends X extends @Initialized @Nullable Object".

The checker framework started emitting an error for this case some time after 
v1.7.2.

Original issue reported on code.google.com by cus...@google.com on 15 May 2014 at 8:39

GoogleCodeExporter commented 9 years ago
Thanks for the bug report!
I think the problem is that at the moment we don't perform method type argument 
inference for void methods. By doing this we would infer the correct type for 
"setExtension" and the error would go away.
I don't think there is a connection to deferred types.

I have a first implementation of a fix for this issue, but it needs more spins 
on other generic test cases.
I'll push this after the June 2 release. 

Original comment by wdi...@gmail.com on 28 May 2014 at 4:16