Bugzilla – Full Text Bug Listing
| Summary: | [1.7-][compiler] "Bound mismatch" in eclipse 4.4, compiles with javac | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Igor Fedorenko <igor> |
| Component: | Core | Assignee: | Sasikanth Bharadwaj <sasikanth.bharadwaj> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | srikanth_sankaran, stephan.herrmann |
| Version: | 4.4 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Mac OS X | ||
| See Also: | https://git.eclipse.org/r/42177 | ||
| Whiteboard: | stalebug | ||
At 1.8 we find a solution. Any volunteer to analyse why we don't find the same at 1.7? Sasi, please take a look. Moving to M3 The difference, I think is that in 1.8, we are able to arrive at the provisional result Type Bounds: TypeBound U#1 = java.util.List Dependency U#1 <: T#0 TypeBound T#0 :> java.util.List TypeBound T#0 :> capture#1-of ? TypeBound T#0 = java.lang.Object while this does not happen in 1.7 mode. It looks to me like that the constraint T is a super type of U is not considered at all in org.eclipse.jdt.internal.compiler.lookup.ParameterizedGenericMethodBinding.inferFromArgumentTypes(Scope, MethodBinding, TypeBinding[], TypeBinding[], InferenceContext), thereby causing the bounds check to fail. Analyzing further. @Srikanth, any inputs on where I should be looking? Interestingly, this doesn't compile even in 4.2.2 and 4.3.2. (In reply to Sasikanth Bharadwaj from comment #4) > The difference, I think is that in 1.8, we are able to arrive at the > provisional result It could well be that we should not compile this code at all, I'll take a look later this week and let you know what I find. I believe but I am not sure if InferenceContext18.getReturnProblemMethodIfNeeded is overly permissive and needs tightening. I think the line that reads: if (InferenceContext18.SIMULATE_BUG_JDK_8026527 && expectedType != null && method.returnType instanceof ReferenceBinding) { should read instead: if (InferenceContext18.SIMULATE_BUG_JDK_8026527 && usesUncheckedConversion() && expectedType != null && method.returnType instanceof ReferenceBinding) { Not sure. What I have noticed is that it permits patently inapplicable methods to get through occasionally. According to comment 0 we would be looking for a way to accept this at 1.7, not for a way to reject at 1.8. Have we changed our minds? :) (In reply to Stephan Herrmann from comment #6) > According to comment 0 we would be looking for a way to accept this at 1.7, > not for a way to reject at 1.8. > > Have we changed our minds? :) Taking a closer look, while the last sentence of comment#5 needs investigation on its own, it is unconnected to this issue. That applicability succeeded in 1.8 is enough to expect inferFromArguments to succeed at 1.7. Sasi see why that fails. (In reply to comment #6) > According to comment 0 we would be looking for a way to accept this at 1.7, not > for a way to reject at 1.8. > > Have we changed our minds? :) The post inference bounds check fails in this case, because List is incompatible with the capture binding. Introducing the additional constraint T >: List when collecting substitutes of U helps us arrive at a solution and accept this code, or, excluding the capture from super constraints of T, neither of which seems valid from a spec point of view. Wondering if this also belongs to the same category as bug 425203 Moving to M5 Hopefully will be able to address this one with the fix for bug 425203, moving to M6 New Gerrit change created: https://git.eclipse.org/r/42177 I do not see a solution to this yet. Moving out because this always existed and works at 1.8. (In reply to Sasikanth Bharadwaj from comment #12) > I do not see a solution to this yet. Moving out because this always existed > and works at 1.8. When you say "I do not see a solution to this yet", do you mean you tried to fix this bug but didn't find a good/acceptable solution? Or do you mean nobody fixed or provided a patch for this yet? (In reply to comment #13) > (In reply to Sasikanth Bharadwaj from comment #12) > > I do not see a solution to this yet. Moving out because this always existed > > and works at 1.8. > > When you say "I do not see a solution to this yet", do you mean you tried to fix > this bug but didn't find a good/acceptable solution? Or do you mean nobody fixed > or provided a patch for this yet? I meant I haven't been able to find a solution 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. If you have further information on the current state of the bug, please add it. 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 am not quite sure what to make out of this, but the following class does not compile in eclipse 4.4M6 (and Y20140315-0700 in java 7 mode) and compiles with javac 1.7.0_45-b18 and 1.8.0-b132. Eclipse Y20140315-0700 support compiles the code in java-8 mode too, so I am really confused now -- how List.class can possibly extend an unknown type? Or does "unknown type" actually mean "anything that extends Object"? ==== SimplerTest.java package test; import java.util.List; public class SimplerTest { public static interface Parameterized<T> { public T getParameter(); } public static <T, U extends T> void assertInstanceOf(T actual, Class<U> expectedType) {} public void test() { Parameterized<?> q = null; assertInstanceOf(q.getParameter(), List.class); } } ==== error message Bound mismatch: The generic method assertInstanceOf(T, Class<U>) of type SimplerTest is not applicable for the arguments (capture#1-of ?, Class<List>). The inferred type List is not a valid substitute for the bounded parameter <U extends T>