ctolkmit / checker-framework

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

'incompatible types' error with wildcards #338

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
I'm not certain this is a bug, but I expected the use of the wildcard below to 
be legal.

This issue only occurs with the given source ordering - if 'Foo' is before 
'Test' in the source list there are no errors. Perhaps this is related to a 
difference in handling between sources and pre-compiled classes?

Here's the repro:

=== Foo.java ===
interface Foo<T> {
  Class<T> get();
}
===

=== Test.java ===
class Test {
  static void m2(Foo<?> foo) {
    Class<?> clazz = foo.get();
  }
}
===

$ ~/jsr308/checker-framework-1.8.2/checker/bin/javac -processor 
org.checkerframework.checker.nullness.NullnessChecker Test.java Foo.java 

Test.java:3: error: [assignment.type.incompatible] incompatible types in 
assignment.
    Class<?> clazz = foo.get();
                            ^
  found   : @Initialized @NonNull Class<? extends @Initialized @Nullable Object>
  required: @UnknownInitialization @Nullable Class<? extends @Initialized @NonNull Object>

Original issue reported on code.google.com by cus...@google.com on 17 Jun 2014 at 9:34

GoogleCodeExporter commented 9 years ago
Thanks for the test case, I can reproduce the problem.
The behavior for both invocations should definitely be the same.
I think no error is the correct behavior.

Original comment by wdi...@gmail.com on 24 Jun 2014 at 8:19

GoogleCodeExporter commented 9 years ago

Original comment by Jonathan...@gmail.com on 8 Apr 2015 at 9:58

GoogleCodeExporter commented 9 years ago

Original comment by jtha...@cs.washington.edu on 18 Apr 2015 at 6:42