| Summary: | [generalize type] introduces duplicate methods in presence of overloading [refactoring] | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Friedrich Steimann <steimann> | ||||
| Component: | UI | Assignee: | Kenneth Styrberg <kenneth> | ||||
| Status: | VERIFIED FIXED | QA Contact: | Roland Grunberg <rgrunber> | ||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | akiezun, dirk_baeumer, kenneth, markus.kell.r, rgrunber | ||||
| Version: | 3.0 | ||||||
| Target Milestone: | 4.17 M3 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows 2000 | ||||||
| See Also: |
https://git.eclipse.org/r/c/jdt/eclipse.jdt.ui/+/165862 https://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=0c492a7e053a1776db4485d5542f78d6179c552e |
||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
Created attachment 14104 [details]
sample project reproducing the bug
Frank, can you please comment. Confirmed. The failure to correctly deal with overloaded methods is indeed a known issue. I can create a fix for it, but it will be >1 month before I have time. The solution is basically to generate additional constraints for parameters and return types of methods that are overloaded if the signatures of these methods refer to the class from which we're extracting the interface. Dirk: we should perhaps defer fixing this problem until Markus is done with the overhaul of the type constraints infrastructure. What do you think? -Frank As long as the fix doesn't depend on the new infrastrucuture or new features there I would not introduce an unnecessary dependencies between them. So if not I would opt to fix it. Deferring post 3.1 This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. New Gerrit change created: https://git.eclipse.org/r/c/jdt/eclipse.jdt.ui/+/165862 Gerrit change https://git.eclipse.org/r/c/jdt/eclipse.jdt.ui/+/165862 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=0c492a7e053a1776db4485d5542f78d6179c552e Anything pending here for 4.17 M3? I don't think so. I'm waiting for M3 to do more testing on solved bugs. Setting to RESOLVED (FIXED) Verified for 4.17 M3 using I20200818-0900 build |
Version: 3.1.0 Build id: 200408070010 I guess this is a known issue, but nevertheless ... public class A { public void m(C c) {c.n();} } public class B extends A { public void m(C c) {} public void m(I c) {} } public class C implements I { public void n() {}; } public interface I { public abstract void n(); } generalizing type of c in A.m(C c) offers I, which makes B.m(I c) duplicate. See attached. -- Friedrich