Bug 251523 - [1.5][compiler] Should still flag Enum#valueOf override
Summary: [1.5][compiler] Should still flag Enum#valueOf override
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.5   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.5 M3   Edit
Assignee: Kent Johnson CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-10-21 08:05 EDT by Philipe Mulet CLA
Modified: 2009-05-07 03:32 EDT (History)
2 users (show)

See Also:


Attachments
Proposed patch (3.65 KB, patch)
2008-10-21 08:25 EDT, Philipe Mulet CLA
no flags Details | Diff
In progress patch (4.41 KB, patch)
2008-10-21 09:42 EDT, Philipe Mulet CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Philipe Mulet CLA 2008-10-21 08:05:39 EDT
Integration 10/21/2008.

Regression introduced by fix for bug 146768
The following code should be rejected:

public enum X {
	;
	private X valueOf(String arg0) { return null; }
}
Comment 1 Philipe Mulet CLA 2008-10-21 08:25:05 EDT
Created attachment 115681 [details]
Proposed patch
Comment 2 Philipe Mulet CLA 2008-10-21 09:31:07 EDT
The patch is not good enough.

BTW, we also need to handle properly a more complex case:

public enum X {
        ;
        private X valueOf(String arg0) { return null; }
        private X valueOf(String arg0) { return null; }
        private X valueOf(String arg0) { return null; }
        
        void foo() {
        	valueOf("");
        }
} 

The generated problem type should still dump one valueOf method for consistency between batch/incremental compile. 

Ideally, it should keep the implicit synthetic method (considering the message indicates it taking precedence).
Comment 3 Philipe Mulet CLA 2008-10-21 09:42:16 EDT
Created attachment 115694 [details]
In progress patch

This patch still doesn't address the problem Type issue. It does ensure reporting a problem against each dup methods (including the first one), and should handle enum specials ok (nuking all user dup methods).

Code in HEAD seems to only report a problem against subsequent dup methods, and not original one any longer (where I noticed some tests expected all methods to be flagged)
Comment 4 Kent Johnson CLA 2008-10-21 14:00:21 EDT
Released enum test164 for 3.5M3

Was fixed by new patch for bug 146760
Comment 5 David Audel CLA 2008-10-28 10:11:54 EDT
Verified for 3.5M3 using I20081026-2000 build.