Community
Participate
Working Groups
Build id: M20100825-0800 Eclipse compiler fails to diagnose name clash problems in certain scenarios. This is a regression introduced at the fix for bug 322001. Program demonstrating the problem: class Base<T> { T foo(T x) { return x; } } interface Interface<T>{ T foo(T x); } public class Derived extends Base<String> implements Interface<Integer> { public Integer foo(Integer x) { return x; } } Javac correctly complains: Derived.java:11: name clash: foo(T) in Base<java.lang.String> and foo(T) in Inte rface<java.lang.Integer> have the same erasure, yet neither overrides the other public class Derived extends Base<String> implements Interface<Integer> { ^ 1 error
We should target to close this for 3.6.1 as this is a regression over 3.6.
Created attachment 177519 [details] Patch under test This patch is not really a fix for the current problem, but consists of a backing out of the improper fix for bug 322001 and a refix of the problem that bug is concerned with. Here is a comment from the original fix: "We used to unconditionally check here for name clashes between the overridden inherited method and all other non-matching inherited methods with the same method selector here. This makes no sense when the current type is concrete as the overridden method has been effectively replaced and is hidden in the current class and cannot contribute to a clash." This reasoning fails to account for the fact that a class could inherit two methods one from an super interface and another from a super class that could potentially clash leading to the current issue.
Didn't review the patch in detail but I agree that this needs to get fixed in 3.6.1.
Note for reviewers: Since this involves a backing out of a recent change and a refix, you may find it easier to understand the patch by comparing: MethodVerifier15.java with version 1.113 SourceTypeBinding.java with version 1.177 MethodVerifyTests.java with previous version. Basically, the problem in bug 322001 was very similar to the one in bug 293615 In order to report a name clash between two inherited methods, we should look for a "method descriptor" clash and not a "method signature" clash. (Within the same class two methods that differ only in return type result in a clash i.e only signature counts when the two methods being checked for clash come from the same class. See http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6182950) (When looking at one inherited method and another from a class return type again counts, since the return type is allowed to vary in a co-variant manner.
- All JDT/Core tests pass. - Same patch for 3.6.1 - Regression tests added via org.eclipse.jdt.core.tests.compiler.regression.MethodVerifyTest.test212() Satyam, please review , TIA.
Patch looks good for me. +1 for 3.6.1
+1 Patch looks good.
Released in HEAD for 3.7 M2 in 3.6.x maintenance stream for 3.6.1 I'll leave this defect open for a while even as I test more. May add more regression tests if needed.
Additional testing didn't uncover any issues. Resolving as fixed.
Verified for 3.6.1 using build M20100827-0800.
Verified for 3.7M2 using I20100914-0100. I prefer javac's error message for this case.
