Summary: | [compiler] ecj compiles the code that javac6 rejects | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Satyam Kandula <satyam.kandula> | ||||||
Component: | Core | Assignee: | Ayushman Jain <amj87.iitr> | ||||||
Status: | VERIFIED FIXED | QA Contact: | |||||||
Severity: | normal | ||||||||
Priority: | P3 | CC: | Olivier_Thomann, pwebster, remy.suen, srikanth_sankaran | ||||||
Version: | 3.7.1 | Flags: | srikanth_sankaran:
review+
|
||||||
Target Milestone: | 3.8 M3 | ||||||||
Hardware: | PC | ||||||||
OS: | Windows 7 | ||||||||
Whiteboard: | |||||||||
Attachments: |
|
Description
Satyam Kandula
2011-08-25 09:58:39 EDT
Created attachment 202217 [details]
proposed fix v1.0
I believe all's not well with the way we compare erasure of one method against the signature of another. This is because what we actually want to check is that if one method is foo(List<String>), and another is foo(List). erasure of first is foo(List), same as the second foo. But with the current approach when we compare params[index].erasure != params[index] , we actually end up comparing List<E> with List.
This patch tries to fix that. Passes all tests apart from one, which is a dup of the reported case here.
Srikanth, what do you think?
(In reply to comment #1) > Created attachment 202217 [details] > proposed fix v1.0 > > I believe all's not well with the way we compare erasure of one method against > the signature of another. This is because what we actually want to check is > that if one method is foo(List<String>), and another is foo(List). erasure of > first is foo(List), same as the second foo. But with the current approach when > we compare params[index].erasure != params[index] , we actually end up > comparing List<E> with List. > > This patch tries to fix that. Passes all tests apart from one, which is a dup > of the reported case here. > Srikanth, what do you think? (1) Can you please check whether the unrestored part of code from https://bugs.eclipse.org/bugs/attachment.cgi?id=146981 (essentially the changes to MethodBinding.java as others have been restored over two passes) has any effect on this bug without your patch ? (2) Can you check what was eclipse's behavior on this before Kent's original changes went in ? If things matched javac, why and how ? If things didn't match javac, then did it match HEAD without your patch ? (In reply to comment #2) > (1) Can you please check whether the unrestored part of code from > https://bugs.eclipse.org/bugs/attachment.cgi?id=146981 (essentially > the changes to MethodBinding.java as others have been restored over > two passes) has any effect on this bug without your patch ? No. I tried, but those changes don't have any effect. > (2) Can you check what was eclipse's behavior on this before Kent's > original changes went in ? If things matched javac, why and how ? > If things didn't match javac, then did it match HEAD without your > patch ? I tried 3.5.2 and he behaviour matches the current HEAD behaviour i.e. both are incompatible with javac6. I still stand by my analysis in comment 1. Patch looks ok to me. Created attachment 204248 [details]
fix + tests
Added regression test and updated a previous test to the new behavior (matches javac6 now)
Released commit 7cddbfa7d184b903e6606f21236d46be8958fe44 into HEAD for 3.8M3 Verified for 3.8 M3 using build id: N20111022-2000 |