Bugzilla – Full Text Bug Listing
| Summary: | [1.5][compiler] Dup Enum#valueOf(...) should keep the synthetic one | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Philipe Mulet <philippe_mulet> | ||||
| Component: | Core | Assignee: | Kent Johnson <kent_johnson> | ||||
| Status: | VERIFIED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | david_audel | ||||
| Version: | 3.5 | ||||||
| Target Milestone: | 3.5 M3 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
e.g.
public enum X {
;
private int valueOf(String arg0) { return 0; }//11
void foo() {
int i = valueOf("");
}
}
I'd expect 2 errors: 1 for dup #valueOf(...) definition, one for type mismatch since #valueOf(...) in synthetic form is returning an X.
Added EnumTest#test166-167 (reflecting current behavior) Created attachment 115952 [details]
Proposed patch with testcases
Philippe - please take a look
I like the new behavior in the tests, this is what I was hoping for initially. Looks good to me. Philippe - when 3 duplicates exist, we only complain about the first one once
because of :
if (methodDecl == null) {
methodDecl = method.sourceMethod();
Fix and tests released for 3.5M3
Verified for 3.5M3 using I20081026-2000 build. |
Head as of 10/22/08 In presence of dup enum special method, the compiler should internally keep the synthetic binding for valueOf since this is the implicit one mentionned in problem report. In the case below, the binding kept is "int valueOf(...)" (and it is persisted in problemType). It is different from "X valueOf(...)" implicitly added. public enum X { ; static int valueOf(String arg0) { return 0; }//9 } public class Other { void foo() { int i = X.valueOf(""); } }