renaming of files and packages causes symbols to get out of sync

[martinlippert]

The symbol index gets out of sync when (all tested in VSCode):

• renaming a Java source file (that contains symbols): old symbol stays around + new symbol created
• renaminig a package (that contains classes with symbols): old symbols stay around, new symbols not being created

Need to double check whether this happens in Eclipse as well, probably depending on the events about file changes that we receive.

[martinlippert]

It looks like some file watch events are coming through with a duplicated / in the path (between the project root and the project content), so that the symbol index doesn't find (and remove) outdated symbols from those paths.

After debugging through this, Alex filed microsoft/vscode#210517, but it seems like another extension is responsible for this: the Project Manager for Java. Once you have that extension installed, the file watcher events contain the duplicated /. If you don't have that extension installed or deactivated, the events look fine again.

[bpasero]

@martinlippert this sounds like an issue with creating a file system watcher with a path that has a trailing slash or backslash. That should be avoided:

https://github.com/microsoft/vscode/blob/a7d0bc898241b7c049ccdf628b9af4a6242e6a29/src/vscode-dts/vscode.d.ts#L2221-L2226

I am thinking to make a change in VS Code to address this, but it would still be good to fix the extension as well.

[martinlippert]

Okay, once I disable the Project Manager for Java (for the moment), I can observe this behavior:

• renaming a Java source file (that contains symbols): old symbols removed + new symbols created
• renaminig a package (that contains classes with symbols): old symbols stay around, new symbols still not being created

It looks like in the case of renaming a package, the language server doesn't receive any events for the files inside of the renamed packages, even though the Java tooling changes the content of those files nicely (switching the package statement to match the renamed folder structure).

[martinlippert]

@martinlippert this sounds like an issue with creating a file system watcher with a path that has a trailing slash or backslash. That should be avoided:

https://github.com/microsoft/vscode/blob/a7d0bc898241b7c049ccdf628b9af4a6242e6a29/src/vscode-dts/vscode.d.ts#L2221-L2226

I am thinking to make a change in VS Code to address this, but it would still be good to fix the extension as well.

@bpasero Thanks a lot for looking into this and for the pointer to the doc about the trailing slash. Will let the maintainers of the Package Manager for Java extension know. Should definitely be fixed there as well. But also great to see that you added a fix to VSCode itself to prevent this in the future, much appreciated.

[martinlippert]

More precise analysis of the renaming of packages use case:

• if the java classes inside of the package are not open in an editor and the package gets renamed on the file explorer:
  • we don't get an event about the old java source files being deleted
  • the changed java source files get opened in editors (in dirty state)
  • when saving all the files, we get a file changed event for those files
  • but we never got any file deleted or file created event

This seems to make sense since the files are technically not deleted and not created on disc, if you rename a parent folder. The java language tooling opens those docs in editors and updates the package statement (seems fine, too) and when saving the files, their content is stored to disc with the corresponding doc and file events. But it looks like the language server doesn't get any information about the fact that - in the end - the uri of those docs changed.