Summary: | [1.5][compiler] Eclipse compiler fails to reject invalid code with primitives autoboxed to generics | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Victor <vwss1984> | ||||||||
Component: | Core | Assignee: | Kent Johnson <kent_johnson> | ||||||||
Status: | VERIFIED FIXED | QA Contact: | |||||||||
Severity: | trivial | ||||||||||
Priority: | P3 | CC: | Olivier_Thomann, philippe_mulet, vwss1984 | ||||||||
Version: | 3.4 | ||||||||||
Target Milestone: | 3.5 M6 | ||||||||||
Hardware: | All | ||||||||||
OS: | Windows XP | ||||||||||
Whiteboard: | |||||||||||
Attachments: |
|
Description
Victor
2009-02-13 09:13:47 EST
Test case: [public class X { public <T extends Integer> T m1() { return 35; } public <T extends Integer> T m2() { return new Integer(35); } public static void main(String[] args) { System.out.println(new X().m1()); } }] javac 1.5, 1.6 and 1.7 are properly rejecting the code. javac 1.6: X.java:3: incompatible types found : int required: T return 35; ^ X.java:7: incompatible types found : java.lang.Integer required: T return new Integer(35); ^ 2 errors javac 1.7 (b44): X.java:3: incompatible types found : int required: T return 35; ^ X.java:7: incompatible types found : java.lang.Integer required: T return new Integer(35); ^ 2 errors javac 1.5: X.java:3: incompatible types found : int required: T return 35; ^ X.java:7: incompatible types found : java.lang.Integer required: T return new Integer(35); ^ 2 errors Created attachment 125658 [details]
Proposed patch and testcase
Released fix and tests for 3.5M6 I think there is more than the return statement to fix. e.g. public class X<T extends Integer> { T foo(T t) { t = 5; // we should complain here too foo(6); // we do reject it ok already (why?) return t; } } Also I am not convinced this is the right fix. I suspect we have erasure conversion fooling us here... Reopening Looking deeper, I think the fix is reasonable. However, there are more situations to fix in the same way, see test case below: field decl, local decl, assignment (the rest seems fine since cannot cause grief) public class X<T extends Integer> { T field = 12; T foo(T t) { t = 5; foo(6); T t1 = t == null ? t : 8; T t2 = 9; T[] t3 = { 10 }; perform(10); return 7; } T bar(T t) { int i = 0; t = i; foo(i); T t1 = t == null ? t : i; T t2 = i; T[] t3 = { i }; perform(i); return i; } void baz(T t) { int i = t; i+= t; } void perform(T... t) {} } I would also like a 3.4 version of the fix, given it feels an obvious case (for 3.4.x) Created attachment 125920 [details]
Proposed patch and testcase
Created attachment 125935 [details]
Proposed patch and testcase for 3.4.x
Released fix and test for 3.5M6 Released into 3.4.x branch (post 3.4.2) Verified for 3.5M6 using I20090309-0100. |