Summary: | [1.4/1.5] [compiler] incorrect error about incompatible operand | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Thomas Watson <tjwatson> | ||||||
Component: | Core | Assignee: | Srikanth Sankaran <srikanth_sankaran> | ||||||
Status: | VERIFIED DUPLICATE | QA Contact: | |||||||
Severity: | normal | ||||||||
Priority: | P3 | CC: | Olivier_Thomann | ||||||
Version: | 3.7 | ||||||||
Target Milestone: | 3.7 M4 | ||||||||
Hardware: | PC | ||||||||
OS: | Mac OS X - Carbon (unsup.) | ||||||||
Whiteboard: | |||||||||
Attachments: |
|
I wonder if we should not check if java.lang.Class is generic before creating a parameterized type binding for "byte.class". (In reply to comment #0) > Created an attachment (id=182531) [details] > test project > > This setup may be considered bogus. Basically we have a project compiling with > the jsr14 flag but compiling against the J2SE 1.4 class library. To reproduce > you must have a 1.4 VM configured into your workspace and import the attached > project. > > It complains about code like this: > > Class type == null; > if (type == byte.class) <== fails here > return; [Srikanth slapping himself on his forehead] I should have anticipated this problem. This is really the other side of the coin so to speak as is obvious from https://bugs.eclipse.org/bugs/show_bug.cgi?id=328827#c3 That bug was fixed the method isEquivalentTo in the TypeBinding hierarchy. We should also fix the method isProvablyDistinct in the TypeBinding hierarchy. Patch will follow shortly. (In reply to comment #2) > I should have anticipated this problem. This is really the > other side of the coin so to speak as is obvious from > https://bugs.eclipse.org/bugs/show_bug.cgi?id=328827#c3 https://bugs.eclipse.org/bugs/show_bug.cgi?id=323633#c14 does anticipate these issues. FWIW. (In reply to comment #0) > Created an attachment (id=182531) [details] > test project > > This setup may be considered bogus. Basically we have a project compiling with > the jsr14 flag but compiling against the J2SE 1.4 class library. The oddity with the set up is just a red herring. The problem is the same as in bug 329588. In establishing type equivalence, we need to be prepared to see a type in one of three forms : as a parameterized form, a raw form or a "plain" (1.4) form. I'll add a regression test and close this as a duplicate of bug 329588. (In reply to comment #1) > I wonder if we should not check if java.lang.Class is generic before creating a > parameterized type binding for "byte.class". This does fix the current problem, but the more general fix is already committed via the fix to bug 329588 Created attachment 182557 [details] Regression test junit for test case corresponding to comment# 0 TypeBinding Class is now not provably distinct from Class<java.lang.Byte> *** This bug has been marked as a duplicate of bug 329588 *** Released regression test in HEAD for 3.7 M4 *** Bug 329589 has been marked as a duplicate of this bug. *** Verified using I20101207-0250 (4.1 I-build) |
Created attachment 182531 [details] test project This setup may be considered bogus. Basically we have a project compiling with the jsr14 flag but compiling against the J2SE 1.4 class library. To reproduce you must have a 1.4 VM configured into your workspace and import the attached project. It complains about code like this: Class type == null; if (type == byte.class) <== fails here return;