Community
Participate
Working Groups
Build 3.5M5 This is a regression over 3.5M4, identified by Ed Merks. The following code should compile clear (simple testcase extracted from QVT codebase). public abstract class X implements Visitable { public <T, U extends Visitor<T, ?, ?, ?, ?, ?, ?, ?, ?, ?>> T accept(U v) { return null; } public <T, U extends Visitor<T, ?, ?, ?, ?, ?, ?, ?, ?, ?>> T accept2(U v) { if (v == null) return this.accept(v); else return this.<T, U> accept(v); } } interface Visitable { <T, U extends Visitor<T, ?, ?, ?, ?, ?, ?, ?, ?, ?>> T accept(U v); } interface Visitor<T, C, O, P, EL, PM, S, COA, SSA, CT> { }
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
