On a hunch I:
 - exited the ide
 - removed .netbeans/dev/var/cache/cnd/model
 - restarted ide and did the refactor again

but it had the same doubling effect.

Hi Todd,
trying the simplest

namespace Timeline {

    class TlFilter {
    };

    class TlFader : public TlFilter {

        enum ParamEnum {
            Token1, Token2
        };
        
    private:
        
        ParamEnum param;
    };
}

renames ParamEnum->ParamToken correctly.
Any ideas how to reproduce?

If I create a new project, it works for me too. But going back to the project where it goes wrong, it continues to double what I want, even if I quit-remove model-restart-refacor-rename.

What details can I give you that will point at the cause?

Todd,
Can you try empty project and C&P content of problematic file there, then check (may be construction complexity have some meaning)

Btw, do you know about line feeds used in problematic file?

Vladimir, what about your "diagnostic" feature?

Todd, 
Can you press Ctrl+Alt+Shift+M and select checkbox "File Code Model", then OK and check that position of enum declaration in output corresponds to it's real position in file 
i.e. if you see:
FUNCTION DEFINITION Cpu  [35:1/1638-38:2/1816] ConstructorDefinitionImpl SCOPE: cpu.cc
it means that Cpu is declared from line 35, column 1 till line 38 column 2

Sorry I haven't commented on this. I have since tried to reproduce using the same release on windows 7 and on a different linux machine. Both tests used the entire codebase, but the refactoring was just fine.

I now think that it must be due to some state under ~/.netbeans/dev/... I'm working at home today and possibly tomorrow, and won't get a chance to work on the linux machine where this error occurs for a few days.

It appears my theory about the state under ~/.netbeans/dev is correct. Specifically, it appears to be caused by the contents of two files:

   .netbeans/dev/var/cache/all-ergonomics.dat
   .netbeans/dev/var/cache/all-resources.dat

More specifically, I tried removing large numbers of files under .netbeans/dev, reran the ide, and did a refactor. If the refactor still doubled up, I shut down the ide and removed more files. If the refactor worked correctly, I'd restore everything and start removing other files. Eventually I narrowed it down to the two files above. If either or both files were removed before running the ide, refactoring a name "x" to "y" would work correctly; if they were restored to the state in the attachment, the refactor would result in "yy".

As a final test, I created a fairly clean .netbeans/dev as follows:
 - removed .netbeans/dev
 - restarted the ide
 - restored all my options
 - exited the ide
 - restored the files in the attachement to (the newly created) .netbeans/dev/var/cache
 - restarted the ide and showed that refactoring was still broken

So you should be able to recreate the condition.

 I've attached all 6 all-* files.  I still have the entire "bad" .netbeans/dev directory if you want it, but the tgz file is 45MB. As it is, the attachment is 10MB.

Created attachment 105770 [details]
broken files from .netbeans/var/cache/all-*

Todd,
This is very very interesting :-)

Can you do the following:
- each time you download new ide version => comment out with '#' cluster "ergonomics" in 
${nb-dist}/etc/netbeans.clusters file (responsible for .netbeans/dev/var/cache/all-ergonomics.dat file)

If doubling of names disappear => we can reassign it to ergonomics

Restoring the "bad" files, I confirmed that the problem is still in 201102100500. But after commenting out "ergonomics" in ${nb-dist}/etc/netbeans.clusters the doubling no longer occurs.

As a side note, after doing the test above, I uncommented "ergonomics" and removed all of the var/cache/all-* files. Yet there must be some second order effect of those broken files, because the doubling of the name as the result of a refactor still happens. The only way out was to remove .netbeans/dev and restart the ide.

I really don't have time to burn on this, and I'd like to see someone there apply the steps above to repeat the problem in house.

Jarda, please, evaluate. I'm lost...
Any ideas why ergonomics can corrupt something in C++ Refactoring?
And why disabling ergonomics fixes it?

If I create file Timeline.cpp and put following into it:

(In reply to comment #2)
> namespace Timeline {
> 
>     class TlFilter {
>     };
> 
>     class TlFader : public TlFilter {
> 
>         enum ParamEnum {
>             Token1, Token2
>         };
> 
>     private:
> 
>         ParamEnum param;
>     };
> }

It is completely red. I started with empty C/C++ Static Library project.

(In reply to comment #14)
> If I create file Timeline.cpp 

OK, I got it: I need to create C++ file, not C with cpp extension. Unexpected.

Anyway then I renamed ParamEnum to ParamToken, and the file remains without errors.

Please read the detailed instructions for how to repeat this in comment #8 (http://netbeans.org/bugzilla/show_bug.cgi?id=194827#c8). You didn't say that you restored the var/cache/all-* files, so I assume you did not.

Common, guys, this is not a bug at all! The all-resources.dat contains classes that take precedence over those from JAR. If you change classes in your JAR, but touch all-resources.dat, then the old classes may be loaded.

Thus your way of reproducing the problem is not representative. This way I could break anything. Thus this bug should be marked as invalid.

I admit that the problem had happened. But when there is no representative way to reproduce it, it implies that this bug should be marked as worksforme.

> But consider how the system failed: as you point out, if you install 
> the file I provided it overrides the code in some other jar file. 
> This suggests three possible bugs worth fixing:
 
> all-resources.dat should contain some validation signature that 
> NB can use to prevent old, broken code inside it 
> from overriding current, correct code.

It does. If the .lastModified timestamp in cnd or any other cluster is newer than the all-resources.dat file, then the file is deleted and recreated.

By manually copying all-resources.dat file into your user directory you are changing its timestamp, thus the way to reproduce the problem is completely invalid.

> Its possible that the situation arose by upgrading from one dev version to
> another. Since the .dat file contains code, the installer should try to prevent > combinations of old .dat files and new code.

Right. And it does (or at least shall). Installer, shall create .lastModified files in each cluster and these files shall have newer timestamp than the old all-*.dat files. You can verify if this is still happening, but it used to work.

> Some version of all-resources.dat contained broken code that did this. 
> If you can find that version of code, you could could confirm that it is 
> either a coding error that has been corrected, or is actually still there.  

Someone can indeed confirm that, but I am not expert in refactoring, so I leave the debugging to someone else. My guess (especially when related to all-ergonomics.dat and all-resources.dat) is that some class is registered twice, or has been renamed and its old and new instances are both registered, etc. 

If Vladimir wants to hunt the refactoring problem in debugger, he can continue. I'd be interested in finding why the all-*.dat files and .lastModified files got out of sync. Finding cause of that would be very worthly. However for that I need different steps to reproduce than copying outdated cache files into user directory.

This is now occurring with a vengeance in the release below. Generally, if the refactor is done while pointing at an instance in the header file, the header file is correct, but the substitution in the .cc file is doubled.

This occurs even if I precede the event with:
 - exit the ide
 - rm -rf ~/.netbeans/dev/var/cache
 - restart the ide
 - refactor a member variable.

Product Version: NetBeans IDE Dev (Build 201108170601)
Java: 1.6.0_23; Java HotSpot(TM) Client VM 19.0-b09
System: Linux version 2.6.35.13-92.fc14.x86_64 running on i386; UTF-8; en_US (nb)
User directory: /home/toddb/.netbeans/dev
Cache directory: /home/toddb/.netbeans/dev/var/cache

Probably some completely unrelated report.

> Probably some completely unrelated report.
I'm not sure I understand your comment... I wrote the original report, and the symptom is largely the same: a doubled substitution.

There appears to be some confusion here... This new instance is repeatable even if .netbeans/dev/var/cache is removed and the ide is restarted. That is, it is no longer dependent on a broken cache. And given the definition of priority (http://wiki.netbeans.org/BugPriorityGuidelines), and the fact that the workaround for a bug in the editor is to manually fix the errors caused by the editor, this is a P2, not a P4.

Todd, are you able to reproduce it on Quote sample on your system?

Not sure what you mean by a "Quote sample", but I can reproduce it every time. Note that what I do is:
 - refactor a variable/member in the header file
 - replacement in the header file is file
 - replacement in every other source file is doubled

Last time it was the presence of some stale data in .netbeans/dev/var/cache, but I am removing that now before every run of the ide (I think you or Alex suggested that). On a hunch, I just now moved .netbeans/dev aside and after wrestling with preferences and startup, I cannot repeat it.

I think that means that the bug is caused by my environment. Although it does seem as if the ~/.netbeans environment is easily corruptible. Perhaps we should just close this bug again, and if appropriate, you might want to figure out how to file a bug that would capture environment corruption.

If you are interested, I could attach the broken ~/.netbeans/dev directory.  It compresses to 16MB if I remove ~/.netbeans/dev/var/cache. Do you want it?

Ok, the plot thickens...

The following procedure will repeat the issue:
 - start ide with old .netbeans/dev
 - save all options
 - mv ~/.netbeans/dev ~/.netbeans/dev.save
 - mkdir ~/.netbeans/dev ~/.netbeans/dev/etc
 - cp ~/.netbeans/dev.save/etc/netbeans.conf ~/.netbeans/dev/etc
 - <restart ide>
 - <restore all options, and allow ide to restart>
 - pick a method in a header file, refactor to a different name

... and as described above, the header file will be fine, but all other source files will have a doubled name. Options backup file is attached.

Product Version: NetBeans IDE Dev (Build 201108310601)
Java: 1.6.0_23; Java HotSpot(TM) Client VM 19.0-b09
System: Linux version 2.6.35.13-92.fc14.x86_64 running on i386; UTF-8; en_US (nb)
User directory: /home/toddb/.netbeans/dev
Cache directory: /home/toddb/.netbeans/dev/var/cache

Created attachment 110495 [details]
options export file.

My apologies for the double compression... the .zip file was not small enough, adding bzip2 compression got it under 10MB.

Todd, thanks for your config data.
Let me double check:
- if you start from clean userdir and do not import any settings from your old userdir => bug is not reproducible, right?

As about 'Quote sample': I do not have your sources and anyway most probably they are very big. So, small test case is always better. IDE is shipped with sample projects (File->New Project and choose Samples->C++ category) and one of them is C++ project 'Quote'
If it can be reproducible on Quote we can investigate it easier.

Thanks!
Vladimir.

Looking for Todd's confirmation that with clean userdir it works and with prev userdir even Quote doesn't work

> - if you start from clean userdir and do not import any settings from your old
userdir => bug is not reproducible, right?

Yes.