Summary: | [1.5][compiler] Invalid type mismatch for after generic method inference | ||||||
---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Philipe Mulet <philippe_mulet> | ||||
Component: | Core | Assignee: | Philipe Mulet <philippe_mulet> | ||||
Status: | VERIFIED FIXED | QA Contact: | |||||
Severity: | normal | ||||||
Priority: | P3 | CC: | dvorak.radek, Ed.Merks, give.a.damus, jerome_lanneluc, kent_johnson, richard.gronback | ||||
Version: | 3.5 | ||||||
Target Milestone: | 3.5 M6 | ||||||
Hardware: | PC | ||||||
OS: | Windows XP | ||||||
Whiteboard: | |||||||
Attachments: |
|
Description
Philipe Mulet
2009-02-04 09:01:20 EST
Problem comes from better implementation for 15.12.2.6 released during 3.5M5. Inference is more sensitive to unchecked conversions, and does perform erasure conversion in presence of unchecked argument types... BUT in this case, it should not occur. However, the method lookup tiebreak code is triggering more generic inference, and performs indirectly a side effect on the original invocation site. Philippe - why does X being an abstract class cause the error ? We do not report an error with this case: // abstract class X implements I { class X implements I { public <T1, U1 extends Visitor<T1>> T1 accept(U1 v) { return null; } <T2, U2 extends Visitor<T2>> void test(U2 v) { T2 t = this.accept(v); // type mismatch error if X is abstract } } interface I { <T3, U3 extends Visitor<T3>> T3 accept(U3 v); } interface Visitor<T4> {} But we do report the type mismatch once X is made abstract. As soon as we detect the need for a tiebreak, like with abstract super types etc... we may run into this bug, as it may perform more than one inference on same invocation site (msg send) and possible pollute it with transient tiebreak/raw method information. Created attachment 124700 [details]
Proposed patch
Sent bin patch to Ed for testing. Improvements near JLS 15.12.2.6 were captured by bug 258798. Released for 3.5M6. Fixed A binary patch is available at: http://www.eclipse.org/jdt/core/patches/org.eclipse.jdt.core_3.5.0.fix263633.jar ? To install on 3.5M5: 1. Shut down Eclipse 2. Rename eclipse/plugins/org.eclipse.jdt.core_3.5.0.v_936.jar to eclipse/plugins/org.eclipse.jdt.core_3.5.0.v_936.jar.disabled 3. Download org.eclipse.jdt.core_3.5.0.fix263633.jar (from link above) to eclipse/plugins 4. Rename eclipse/plugins/org.eclipse.jdt.core_3.5.0.fix263633.jar to eclipse/plugins/org.eclipse.jdt.core_3.5.0.v_936.jar 5. Restart Eclipse These steps will not work if launching Eclipse with '-clean'... but it shouldn't be necessary nowadays anyway. Yes, this fix eliminate the compilation problems in QVT. Verified for 3.5M6 using I20090310-0100 |