Community
Participate
Working Groups
I'll attach a sample project with what appear to be bogus bound mismatch errors. There are also big differences between the results reported by the Eclipse compiler verse the javac compiler for these examples. For Container, Eclipse reports errors for function "f"'s "b", "d", and "g" parameters as having errors; javac reports errors for the "f" and "g" parameters. I believe eclipse is right and that javac missed "b" and "d". In Container2, Eclipse reports errors for function "f"'s "b", "d" and "f" parameters as having errors but the error for parameter "f" appears bogus; javac reports only the bogus error for "f" but neither of the other correct ones. In Container3, Eclipse reports errors for function "g"'s "b", "d", "f", "g", and "j" but the error for parameter "f" appears bogus; javac reports errors for "f", "g", "i" and "j" so is reporting the same bogus "f" and another bogus "i" while missing "b" and "d". Also in Container3, Eclipse reports errors for function "h"'s "b", "d", "f", "g", "i", and "j" parameters where "f" and "i" appear to be bogus; javac reports errors only for "f", "g", and "i", and "j", so again missing "b" and "d" and reporting the same bogus "f" and "i". It would help me a great deal defining my Ecore constraints on the generics support in Ecore if I can be sure which behavior is correct (and why)...
Created attachment 56175 [details] Project containing the sample
Could you please specify the Eclipse build id?
I'm using 3.3M4, i.e., Build id: I20061214-1445. For javac I'm using $ "/cygdrive/c/Program Files/IBM/Java50/bin/javac" -version javac 1.5.0
Re: comment 0 > For Container, Eclipse reports errors for function "f"'s "b", "d", and "g" > parameters as having errors; javac reports errors for the "f" and "g" > parameters. I believe eclipse is right and that javac missed "b" and "d". In the light of bug 202404, I believe eclipse was wrong there as well for 'b' and 'd'. Note that I do not see eclipse (3.3) reporting an error against 'f';
I think the fix for bug 104649 is responsible for the missing diagnosis on 'f'. Reverting the fix as it is no longer needed to address bug 104649 (i.e. the fix was wrong, and other changes - likely for bug 202404 did address the original problem).
Created attachment 78424 [details] Proposed patch
Added GenericTypeTest#test1168-1170 Released for 3.4M2. Fixed
Reopening. My fix breaks the following testcase: import java.util.List; public class X { static <U extends List<U>> U foo(U u) { List<U> v = null; foo(v); return u; } } ---------- foo(v); ^^^ Bound mismatch: The generic method foo(U) of type X is not applicable for the arguments (List<U>). The inferred type List<U> is not a valid substitute for the bounded parameter <U extends List<U>> ----------
Actually, the previous test change is actually expected. Closing as fixed. But only released for 3.4M3. Released for 3.4M3.
should backport to 3.3.2
Released for 3.3.2 Fixed
Checked that we are now consistent with javac (6_03 b05) for the initially provided test cases. Verified for 3.4 M3 using build I20071029-0010. BTW, Philippe, were the 'duplicate A and B' errors in test1170 introduced on purpose?
Good catch. Fixed the test (note that it was still testing properly, since we were resilient enough).
Fix is safe, and quite important for EMF.
+1 for 3.3.2
Verified for 3.3.2 using build M20080123-0800. I've also fixed test #1170 in R3_3_maintenance stream.
