Community
Participate
Working Groups
I20070525-1350 The following test case raises two errors with JDT, no errors with javac 1.5.0_12 or 6_02: public class X<T> { public void bar(K<T, Object> p) { new Y(p); // err1 new Y((J<T, Object>) p); // err2 new Y((I<T, Object>) p); } } class Y<T, U> { Y(I<? extends T, ? extends U> p) { } Y(J<T, ? extends U> p) { } } interface I<T, U> { } interface J<T, U> extends I<T, U> { } interface K<T, U> extends I<T, U>, J<T, U> { } Build I20070523-0010 (aka a bit later than RC1, with was 20070517-1700) shows no error, but three warnings only (as javac does when using -Xlint:unchecked). Note that if J does not extend I, both JDT and javac complain on line err1.
Reverting the change of bug 18761 fixes the problem.
Released inactive test cases AmbiguousMethodTest#60 and 61 in HEAD.
(In reply to comment #1) > Reverting the change of bug 18761 fixes the problem. This is not the right bug number. Did you mean bug 188960 ?
No. Bug 188741 (one digit wrong, apologies).
Current thinking is that Scope#2591 should acknowledge the fact that one and two methods may get rawified *by the same token* (which is the case here, since this is Y getting rawified that rawifies both constructors), and that in this case there is no point in unrawifying two alone (nor in unrawifying anyone, indeed). I will dig a bit deeper along this line.
Created attachment 69682 [details] Discussion basis (a prototype that works, plus split test cases) This is meant to get the discussion starting. The suggested patch memorizes methods substitutions in the stack above isAcceptableMethod for the test cases that we want to fix. A few caveats: - marking the methods themselves, which has design problems anyway, proved to be too strong, as the methods returned by computeCompatibleMethod are cached; - considering only changes due to the call to computeCompatibleMethod at Scope#3330 proved insufficient, breaking at least one of the AmbiguousMethodTest-s; - relying upon wasInferred to capture changes due to the call to computeCompatibleMethod at Scope#1123 proved insufficient as well; - this patch only prototypes a working solution; I have not spent much time proof-reading it yet; - tests are on their way at the time of writing.
Tests pass.
Created attachment 70019 [details] Proposed patch Was too aggressive with previous change for bug 188741 This is a simple tweak that recognizes methods from raw types
Risk: The change is simple and has a low risk of causing new problems. The fix for bug 188741 did not handle the case when the second method is from a raw type already, in which case we should not switch back to the original method. Benefits: This is a regression of sorts from 3.3RC2. Its a testcase from actual code, so the fix is necessary for some users.
Much better way to make the difference between 'raw' and 'rawified'. Also checked that the suggested patch passed the code that raised the bug. Hence +1. Additional remark: since toCheck is used only once, you may consider not declaring at all and using its value instead in the call to needsUncheckedConversion.
*** Bug 191029 has been marked as a duplicate of this bug. ***
+1. Test cases from bug 191029 should be added as regression tests.
Bug 191029 is really a duplicate of the original bug 188960 The testcase for that bug is AmbiguousMethodTest test059 Added the additional test as test059a
Created attachment 70140 [details] Updated patch
Created attachment 70148 [details] Correct updated patch
+1 for 3.3rc4
+1 for 3.3 RC4
Released into HEAD for 3.3RC4
Verified for 3.3RC4 using I20070606-0010.
