ctolkmit / checker-framework

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

AssertionError during type argument inference #404

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
Compile the attached Java class using `javac -processor 
org.checkerframework.checker.nullness.NullnessChecker -version -verbose 
-AprintErrorStack -AprintAllQualifiers StringUtil.java`

What is the expected output? What do you see instead?
I expect the compilation to complete successfully. Instead, an AssertionError 
is thrown. See the attached compiler output.

What version of the product are you using? On what operating system?
I built the "trunk" versions of jsr308-langtools, annotation-tools and 
checker-framework from source, as described in the manual, using jdk1.8.0_31. 
I'm running linux.

Please provide any additional information below.
Didn't try to debug the issue beyond providing this minimal (?) test case, 
sorry.

Original issue reported on code.google.com by stephan...@gmail.com on 28 Feb 2015 at 10:53

Attachments:

GoogleCodeExporter commented 9 years ago
The log shows that I used version 1.8.9. Turns out this is because I used an 
old checkout of the code and performed only an `hg pull`, without an `hg 
update`. I just *properly* updated the working directory and re-ran the test 
using version 1.8.11. Can confirm the ticket is still valid.

Original comment by stephan...@gmail.com on 4 Mar 2015 at 9:52

GoogleCodeExporter commented 9 years ago
Thanks for the bug report! I verified that the issue still occurs in our 
working repository.

Original comment by wdi...@gmail.com on 17 Mar 2015 at 4:30

GoogleCodeExporter commented 9 years ago

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

GoogleCodeExporter commented 9 years ago

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

GoogleCodeExporter commented 9 years ago
This test case also illustrates a type argument inference problem with multiple 
dependencies.
Re-opened the issue, as the test case is @skipped.

Original comment by wdi...@gmail.com on 27 May 2015 at 7:34

GoogleCodeExporter commented 9 years ago
 It looks like this test previously passed before we fixed the JDK/Issue12 problems (as of the time of this writing the JDK/Issue12 fix is being passed around as a bundle).

When type argument inference fails on Issue404 (for the reasons stated in other 
emails), it infers a wildcard for the type arguments that could not be 
inferred.  The bound annotations of this wildcard come from the type parameter 
to which its an argument.  The annotations on the type parameter in this case 
come from the JDK and have changed (correctly) because of the Issue12/JDK fixes.

So, while the error currently emitted when using the Issue12 bundle should not 
be emitted in the long run, it should be until we fix type argument inference 
to handle these particular cases.

Original comment by jbu...@cs.washington.edu on 27 May 2015 at 9:28