Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
martinlippert opened this issue Apr 16, 2024 · 6 comments
Closed
Assignees
Labels

Comments

@martinlippert
Copy link
Member

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
Copy link
Member Author

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
Copy link

bpasero commented Apr 17, 2024

@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
Copy link
Member Author

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
Copy link
Member Author

@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
Copy link
Member Author

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.

martinlippert added a commit that referenced this issue Apr 22, 2024
…n if there are no events for contained files being send immediately
martinlippert added a commit that referenced this issue Apr 22, 2024
@martinlippert
Copy link
Member Author

Fixed with 96ce861.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants