This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Build: 201210100934 NB refactoring support renames a C function to a name of an existent one leading to compilation error: "previous definition of 'f1' was here" Reproducible: Always Steps to Reproduce: 1. Create a C file with the following code: int f1(){ return 1; } int f2(){ return 2; } int main(){ printf("%d", f1()); } 2. Apply the rename to the f2 function, typing in the New Name f1 (NB silently do that): int f1(){ return 1; } int f1(){ //renamed function: f2 -> f1 return 2; } int main(){ printf("%d", f1()); } 3. The resulting code does not compile: refactoring-rename.c:5: error: redefinition of 'f1' refactoring-rename.c:1: error: previous definition of 'f1' was here
Same result in NB 7.3 Beta 2 Build 201211062253
(In reply to comment #1) > Same result in NB 7.3 Beta 2 Build 201211062253 It is not a regression. All builds has such behavior.
Not a P1 by all means (as long as Undo work fine). Dear user, please specify what is expected behavior from your point of view? BTW, I've seen some cases when users appreciated the implemented behavior. I use this when I want to use one variable instead of two. Just need to delete the definition of either one after rename. It all sounds like a request for a small enhancement - warning, not a bug.
Dear Leonid. By the refactoring point of view, this is a bug, since for any refactoring, the ide shouldn't change the behavior of the program (by definition of refactoring). In this case, the IDE must prevent to do this kindle of changing. For example, Eclipse CDT does not permit this refactoring since there is another function with the same name. I think NB could do the same: show the conflict and does not permit this transformation. Can I reopen the case? Thank you.
(In reply to comment #4) > Dear Leonid. > > Can I reopen the case? > > Thank you. You totally can reopen if you feel it is right thing t do, but please keep it P3 or enhancement. You can specify that how it compares to CDT to justify it is a P3 bug. I still think that both behavior could be appreciated by different people. Requesting a warning asking to user to proceed or not in case of collision is a reasonable thing.
I ask about to reopen the issue because I didnt know after my comment 4 if It would be reopened for someone. > I still think that both behavior could be appreciated by different > people. The problem is that it could invalidate refactoring, and the developers could give up to use those tools. If refactoring is to preserve behavior after transformations, and an IDE does not do that because some users think its better the other way, all refactoring theory and rules would be in check. This is not a matter of taste, but of correctness. Do you see? > Requesting a warning asking to user to proceed or not in case of > collision is a reasonable thing. I think its a good start. About eclipse behavior in this case, they are still analysing this case (It is an opened bug I report. I thought it was close, sorry). But in the macro case of the 223942 bug (http://netbeans.org/bugzilla/show_bug.cgi?id=223942), they show the window attached to this case. Note that Eclipse still do the function rename refactoring, but not the macro one because it is conflicting. So, to Eclipse, for example, those issues are separated. Even so, do you think the 223942 bug has to be attached to this one? Thank you. ps.: about refactoring: the refactoring theory says that refactoring tools should do refactoring in version1 of a code only if the refactored code (say versionRefactored) keeps the same behavior of version1 in all the possible executions of versionRefactored. If not, they should not do. That is, refatoring tools have to protect the developer being more conservative.
Created attachment 129476 [details] Eclipse behavior after a macro rename to a name of an existent one Eclipse does not perform macro rename refactoring if there is another macro with the same name. It would leads to a change behavior of the code.