Community
Participate
Working Groups
Build ID: I20080617-2000 Steps To Reproduce: 1. Start with this class: public class RecursiveMethodSignature { public static void main(String[] args) { System.out.println(factorial(42, false)); } // try to remove "dummy" parameter here private static int factorial(int n, boolean dummy) { if (n < 2) return 1; else return n * factorial(n-1, dummy); } } 2. Invoke "Change method signature" on factorial method. 3. Remove the "dummy" parameter and click ok. Actual Result: You get an error that the removed parameter is still used. If you continue anyway, no error remains since the parameter is only used in the recursive call. Expected Result: There should be no error. Maybe a warning. More information: In the current state, as I cannot rely on this errors in the preview, I usually ignore this error and look what happens. It would be nice if I could rely on that error - i. e. it only appears if there will really be an error present afterwards.
Also happens for non-static methods. Simpler test case: // try to remove parameter 'n' private int foo(int n) { return foo(n); }
*** Bug 137175 has been marked as a duplicate of this bug. ***
*** Bug 408387 has been marked as a duplicate of this bug. ***
(In reply to comment #3) > *** Bug 408387 has been marked as a duplicate of this bug. *** I'm not sure why I didn't find this bug. Thanks for the cross-ref. Note, that bug 408387 comment 1 has some pondering about implementation strategies.
The TempOccurrenceAnalyzer in ChangeSignatureProcessor.DeclarationUpdate.checkIfDeletedParametersUsed() should do something similar to ReferenceUpdate.isRecursiveReference() and handle method references specially if they point back to the original method. Arguments for parameters that will be deleted should be skipped. Don't forget about varargs. (In reply to bug 408387 comment #1) We usually do the analysis independent of the actual rewrite. Just depending on nodes that are deleted by an ASTRewrite is brittle, since the nodes could be deleted for many reasons (e.g. because they are moved to another place).
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.
For the record: Still happens in 2019-12, still relevant for me. But probably I'll have to write the same again in 2029...
(In reply to Michael Schierl from comment #7) > For the record: Still happens in 2019-12, still relevant for me. > > But probably I'll have to write the same again in 2029... Right, unless you or someone else provides a fix ;-).
For the record: Still happens in 2022-12, still relevant for me. (The Genie is getting more aggressive, complaining after 2 years now and not after 10)
For the record: Still happens in 2023-12, still relevant for me. See you in two years :D
