Community
Participate
Working Groups
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(""); } }
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.
