Created attachment 82634 [details]
may be something helpful in log?

it had to be changed to:
            String getName = GeneratorUtils.computeGetterName(field, isUpperCase);
            String setName = GeneratorUtils.computeSetterName(field, isUpperCase);

but looks like textual replacement occurred on wrong position (old one?)

Most likely a source generator bug. But we need a reproducible test case. The messages.log does not contain anything
related unfortunately.

I tried to reproduce with following sources without success:

import javax.lang.model.element.VariableElement;
class GeneratorUtils {
    static String computeGetterName(VariableElement field) {
	throw new UnsupportedOperationException("Not yet implemented");
    }
    static String computeSetterName(VariableElement field) {
	throw new UnsupportedOperationException("Not yet implemented");
    }
}

and 

import javax.lang.model.element.VariableElement;
public class UsageClass {
    void m() {
	VariableElement field = null;
	boolean isUpperCase = true;
	String getName = GeneratorUtils.computeGetterName(field);
	String setName = GeneratorUtils.computeSetterName(field);
    }
}

I did the Change Method Parameters refactoring to add a parameter 'boolean isUpperCase with default value isUpperCase'
for GeneratorUtils.computeGetterName(field) and later for GeneratorUtils.computeSetterName(field). No matter if it was
invoked inside GeneratorUtils.java

Could you provide your sources (project) here or privately to my email?

And the last question are your at local or remote filesystem?

I have got it. It is necessary to close UsageClass.java and restart IDE to be sure the document was released. Now do
those above described refactorings inside GeneratorUtils.java and you should get broken Usages class.

import javax.lang.model.element.VariableElement;
public class UsageClass {
    void m() {
	VariableElement field = null;
	boolean isUpperCase = true;
	String getName = GeneratorUtils.computeGetterName(field, isUpperCase);
	String setName = GeneratorUtils.computeSet, isUpperCaseterName(field);
                                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^
    }
}

Reassigning to java/source.

Hi, Jan, great that you reproduced it. 
You are right that document wasn't yet opened in IDE before.

Btw, after restart of IDE I have seen probably related issue:
- try to rename method declaration then try to use find usages for new named method => it is not found in closed file.
if I open the second file => rename was successful

FS: sources are local, but opened through shared NFS folder net/d-espb04-127-81/export/devarea/trunk/cnd.refactoring (it
is C++ support of NB)

Vladimir, it sounds like a race condition that dbalek has already been hunting. CCing guys that may be interested in
failing index.

Jan, I'm sure that is a showstopper for FCS. 
I have to manually fix all broken code and then restart IDE to continue work.
It wasn't the case with 6.5

Marking as showstopper for 6.7

Obvious problem, parser is recreated but on the staled snapshot.

jet-main: 580220052898

Waiting for review (Dev) and verification (Jirka) ... would be nice to have this in release67 ...

verified in trunk

please integrate the fix in release67 clone
thanks

Integrated into 'main-golden', will be available in build *200905270201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/580220052898
User: Tomas Zezula <tzezula@netbeans.org>
Log: #165803:second change method parameters broke code

outstanding piece of code!
many thanks!!!

Integrated into release67 clone as changeset:   e045818961bc

verified in 6.7rc1