Bug 215843 - [1.5][compiler] Compiler error with generic covariant
Summary: [1.5][compiler] Compiler error with generic covariant
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.3.1   Edit
Hardware: PC Windows XP
: P3 major (vote)
Target Milestone: 3.3.2   Edit
Assignee: Philipe Mulet CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-01-18 14:22 EST by Divyanshu Sharma CLA
Modified: 2008-02-04 12:26 EST (History)
3 users (show)

See Also:
philippe_mulet: pmc_approved+


Attachments
Proposed patch (3.09 KB, patch)
2008-01-21 08:33 EST, Philipe Mulet CLA
no flags Details | Diff
Better patch (5.79 KB, patch)
2008-01-22 06:45 EST, Philipe Mulet CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Divyanshu Sharma CLA 2008-01-18 14:22:04 EST
While using generic covariant as in class below, return a compile time error in eclipse 3.3.1 at line

           SubInterface sub3 = sub1.and(sub2);

However, it compiles fine with Sun JDK 1.5.0_06.


package test;

public class TestEclipseCovariant 
{
	public static void testCovariant(SubInterface sub1, SubInterface sub2)
	{
		SubInterface sub3 = sub1.and(sub2);
	}
	
	public interface SuperInterface<E> {

		public Number getNumber();
		
		public SuperInterface<E> and(SuperInterface<E> a);
		
	}

	public interface SubInterface extends SuperInterface
	{
		public Integer getNumber();
		
		public SubInterface and(SuperInterface s);
	}
}
Comment 1 Philipe Mulet CLA 2008-01-21 07:39:03 EST
Reproduced with latest. Thanks for the testcase. Our lookup seems to pick the superclass method by mistake.
Comment 2 Philipe Mulet CLA 2008-01-21 08:14:02 EST
Lookup properly isolates the following 2 candidates:
1. X.SubInterface and(SuperInterface#RAW)
2. SuperInterface#RAW and(SuperInterface#RAW) 

but tiebreak (Scope#mostSpecificMethodBinding(...)) decides (2) is the best match.

I believe the problem is coming from Scope#isAcceptableMethod(...) which seems to reject the scenario where both methods have identical types, 
and original super method argtype wasn't raw. I don't get what this test is intending to achieve.
Deleting the check makes the problem go away. Didn't find any regression in existing tests.

Kent - what do you think ?
Comment 3 Philipe Mulet CLA 2008-01-21 08:33:09 EST
Created attachment 87394 [details]
Proposed patch
Comment 4 Philipe Mulet CLA 2008-01-21 09:31:44 EST
Oops, there is a regression in AmbiguousMethodTest#test014h.
Comment 5 Kent Johnson CLA 2008-01-21 13:23:59 EST
Instead of removing the 5 lines from Scope, I suggest we change it to:

if (oneParam == twoParam) {
  if (twoParam.leafComponentType().isRawType()) {
    // must detect & reject this case
    // when Y<U> extends X<U>
    // void foo(Y y) {}
    // <T extends X<Object>> void foo(T t) {}
    // foo(T) will show up as foo(Y#RAW) and not foo(X#RAW)
    // Y#RAW is not more specific than a rawified X<T>
    if (twoParam.leafComponentType().erasure() != two.original().parameters[i].leafComponentType().erasure())
      return false;
  }
  continue;
}
Comment 6 Philipe Mulet CLA 2008-01-22 06:15:26 EST
But now, we would fail to accept the following code:

public class X { 
	<T extends G<X>> void a3(T x) {}
	<T extends F<X>> void a3(T x) {}

	public static void ambiguousCases() { 
		H<X> hx = null;
		H hraw = null;
		new X().a3(hx);
		new X().a3(hraw);
	} 
}
class F<T1> {}  
class G<T2> extends F<T2> {}
class H<T3> extends G<T3> {}
Comment 7 Philipe Mulet CLA 2008-01-22 06:45:26 EST
Created attachment 87506 [details]
Better patch

Here is a patch which addresses the latter issue.
Comment 8 Philipe Mulet CLA 2008-01-22 09:32:51 EST
Added GenericTypeTest#test1232-1241.
Kent - what do you think ?
Comment 9 Kent Johnson CLA 2008-01-22 11:11:22 EST
looks good
Comment 10 Philipe Mulet CLA 2008-01-22 11:57:32 EST
Released for 3.4M5.
Fixed
Comment 11 Philipe Mulet CLA 2008-01-22 13:05:30 EST
This is a regression over 3.2.2.
Candidating for 3.3.2. Jerome ?
Comment 12 Jerome Lanneluc CLA 2008-01-22 17:13:40 EST
Asking for PMC approval to backport to 3.3.2 since:
- valid code is rejected
- this is a regression comparing to 3.2.2
- the fix is simple
Comment 13 Philipe Mulet CLA 2008-01-23 04:54:38 EST
+1 for 3.3.2
Comment 14 Philipe Mulet CLA 2008-01-23 04:55:17 EST
Released for 3.3.2 (same patch)
Fixed
Comment 15 David Audel CLA 2008-01-24 05:57:51 EST
Verified for 3.3.2 using build M20080123-0800
Comment 16 Jerome Lanneluc CLA 2008-02-04 12:26:59 EST
Verified for 3.4M5 using I20080204-0010