Bug 353089

Summary: [1.7][compiler] Incorrect name clash error with ecj
Product: [Eclipse Project] JDT Reporter: Ayushman Jain <amj87.iitr>
Component: CoreAssignee: Srikanth Sankaran <srikanth_sankaran>
Status: VERIFIED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: jarthana, satyam.kandula
Version: 3.7Flags: satyam.kandula: review+
Target Milestone: 3.7.1   
Hardware: All   
OS: All   
Whiteboard:
Attachments:
Description Flags
Proposed patch none

Description Ayushman Jain CLA 2011-07-26 06:01:27 EDT
BETA_JAVA7

import java.util.*;

interface A {
int get(List<String> l);
}

interface B  {
int get(List<Integer> l);
}

interface C  extends A, B { 
int get(List l);      // name clash error here
}

This code compiles fine with javac 7b147, not with ecj.
Comment 1 Ayushman Jain CLA 2011-07-26 06:02:51 EDT
This was fixed in javac 7 via oracle bug http://bugs.sun.com/view_bug.do?bug_id=7020657
Comment 2 Ayushman Jain CLA 2011-07-26 07:27:04 EDT
Another example, may be related :

public abstract class Bug extends SuperBug
{
	abstract <T extends Bug> T clone () throws CloneNotSupportedException;
}

class SuperBug
{
	@Override
	public SuperBug clone () throws CloneNotSupportedException
	{
		return (SuperBug) super.clone ();
	}
}

This also compiles fine with javac7b147
Comment 3 Srikanth Sankaran CLA 2011-08-08 02:39:21 EDT
(In reply to comment #2)
> Another example, may be related :

I think this problem is unrelated - as this is not a regression with respect
to 3.6.

The comment# 0 test case is a regression introduced by the fix for 
bug 334306
Comment 4 Srikanth Sankaran CLA 2011-08-08 03:30:36 EDT
(In reply to comment #3)


> The comment# 0 test case is a regression introduced by the fix for 
> bug 334306

The fix for bug 334306 brought this out, but looks like the problem got
introduced at the time of the fix for bug 175987. Why is the code

	if (one.declaringClass.isInterface()) {
		for (int i = 0; i < length; i++)
			if (!areTypesEqual(oneArgs[i], twoArgs[i]))
				return false;
	} else {

even there in org.eclipse.jdt.internal.compiler.lookup.MethodVerifier15.areParametersEqual(MethodBinding, MethodBinding) ???
Comment 5 Srikanth Sankaran CLA 2011-08-08 04:55:59 EDT
(In reply to comment #2)
> Another example, may be related :

I think this test case is the same as the one in bug 345947 and so
this piece will be worked on as part of that fix. I'll add a comment
to that bug carrying over this test case. This bug itself is not a
regression with respect to 3.6.
Comment 6 Srikanth Sankaran CLA 2011-08-08 04:57:02 EDT
Created attachment 201058 [details]
Proposed patch

To make the review easier, I have preserved the original indentation.
Before releasing I'll reindent the code.
Comment 7 Srikanth Sankaran CLA 2011-08-08 04:57:46 EDT
Satyam, please review, TIA.
Comment 8 Srikanth Sankaran CLA 2011-08-08 05:36:24 EDT
Released in HEAD and 3.7 maintenance branch.
Comment 9 Satyam Kandula CLA 2011-08-09 06:42:45 EDT
There is a difference between ecj and javac7 when the line ' int get(List l); ' gets commented out. I have filed bug 345947 to track it. This change in behavior is not caused by this bug fix. 

Otherwise, the changes look good. Hence +1 for the changes.
Comment 10 Satyam Kandula CLA 2011-08-09 06:44:19 EDT
(In reply to comment #9)
> There is a difference between ecj and javac7 when the line ' int get(List l); '
> gets commented out. I have filed bug 345947 to track it. This change in
> behavior is not caused by this bug fix. 
> 
> Otherwise, the changes look good. Hence +1 for the changes.

I actually meant bug 354229 and not bug 345947.
Comment 11 Jay Arthanareeswaran CLA 2011-08-25 06:42:57 EDT
Verified for 3.7.1 RC2 with build M20110824-0800.
Comment 12 Ayushman Jain CLA 2011-09-14 12:35:42 EDT
Verified for 3.8M2 using build I20110911-2000.