| Summary: | [compiler] bounds check succeeds in the presence of wildcards but fails in their absence | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Sasikanth Bharadwaj <sasikanth.bharadwaj> |
| Component: | Core | Assignee: | JDT-Core-Inbox <jdt-core-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | jarthana, stephan.herrmann |
| Version: | 4.8 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. I just happened to check this with latest ECJ and Javac and now we both reject this code. Stephan, any idea what happened here? If not, it will help if you can run your magic tool to find out since when this change came about. The change happened between these versions: accept: Eclipse Compiler for Java(TM) v20190710-0739, 3.19.0, Copyright IBM Corp 2000, 2015. All rights reserved. reject: Eclipse Compiler for Java(TM) v20190903-0936, 3.19.0, Copyright IBM Corp 2000, 2015. All rights reserved. From a quick scan I couldn't find a bug from that interval that sounds very much related? Do you want me to do a commit level bisect, to find the exact change? |
Consider this example public class X { public static void main(String argv[]) { f(new ArrayList<List<? extends String>>()); // remove wildcard to get error } static <Q extends List<Integer>> String f(List<? super Q> c) { return null; } } This code compiles fine in eclipse but javac complains about the method not being applicable because of bounds mismatch. Note that eclipse too gives the same error if we remove the wild card from either the invocation or the declaration of the method f. Although I'm not 100% certain which behavior is right, the fact that removing the wildcard changes eclipse's behavior makes me think we may have a bug