Skip to content

Adding a new workspace folder breaks things #1974

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

Open
musjj opened this issue Mar 3, 2023 · 10 comments
Open

Adding a new workspace folder breaks things #1974

musjj opened this issue Mar 3, 2023 · 10 comments
Labels
bug Something isn't working Info Needed More information is required

Comments

@musjj
Copy link

musjj commented Mar 3, 2023

How are you using the lua-language-server?

NeoVim

Which OS are you using?

Windows

What is the issue affecting?

Completion, Diagnostics/Syntax Checking, Hover, Libraries

Expected Behaviour

Addding new workspace folders should not break anything.

Actual Behaviour

Right now, adding a new workspace folder breaks two things, diagnostics and require statements:

  • You can fix the diagnostic errors by hooking to the workspace/diagnostic/refresh handler to manually refresh it, but even then this is very unreliable and prone to not working:
    sumneko_lua doesn't work across multiple projects neovim/nvim-lspconfig#2366

  • require statements that refers to modules in the new workspace folder also does not resolve correctly (hovering over the module string will display the byte length, instead of the resolved path). This means that completions from the required module will also be missing. So far I can't find any way to fix this without restarting neovim entirely.

Other LSP servers doesn't have this problem. Adding a new workspace folder should just work without any additional steps.

Reproduction steps

  1. Initialize the LSP server with a root directory
  2. Add a new workspace folder using workspace/didChangeWorkspaceFolders
  3. Opening a file from that workspace folder results in diagnostic errors and modules not being resolved correctly

Additional Notes

No response

Log File

No response

@sumneko
Copy link
Collaborator

sumneko commented Mar 6, 2023

Please provide your log

@sumneko sumneko added the Info Needed More information is required label Mar 6, 2023
@musjj
Copy link
Author

musjj commented Mar 6, 2023

https://gist.github.com/musjj/fd726d9b809eba569ff28039ab248ce3
Actually, it seems that the buggy requires is caused by a plugin, never mind that.
The diagnostic issue still persists though.

@sumneko
Copy link
Collaborator

sumneko commented Mar 6, 2023

I have fixed this problem in v3.6.7. Can you test which version it started to break?

@musjj
Copy link
Author

musjj commented Mar 6, 2023

I'm using 3.6.13, the latest stable version. I'll try out the latest commit later on.

@musjj
Copy link
Author

musjj commented Mar 7, 2023

Tried commit 81cffaa, still experiencing this issue.

@sumneko
Copy link
Collaborator

sumneko commented Mar 8, 2023

I'm using 3.6.13, the latest stable version. I'll try out the latest commit later on.

Could you try out if it appears in v3.6.7?

@musjj
Copy link
Author

musjj commented Mar 8, 2023

Sorry about that, I mistakenly thought that 3.6.7 is a version higher than 3.6.13.

Tried out 3.6.7, and yes, I'm still experiencing this issue.

@sumneko
Copy link
Collaborator

sumneko commented Mar 8, 2023

#1810

So this fix dose not work, I will look into again.

@chrisgrieser
Copy link

chrisgrieser commented Apr 4, 2023

Also have exactly the same issue – as soon as you open a second workspace, there "undefined global" is all over the place. In addition, in the second workspace, some capabilities like renaming of variables also sometimes being broken (though I cannot produce that one reliably)

I have had this issue for a while now, haven't made a report because there were already various issues for that already. But they all got closed by now, while the problem at hand still persists for me. 🙁

@sumneko sumneko added the bug Something isn't working label Apr 24, 2023
@flrgh
Copy link
Contributor

flrgh commented Jun 22, 2024

Tried to do some debugging on this today, but I haven't figured out the issue.

I'm guessing it's dependent upon some order of operations in the server or in the client, because I can't reproduce it 100% of the time by doing this:

  1. Open somefile.lua in /path/to/workspace
  2. Open up another file outside of the workspace
  3. Wait and observe diagnostics on the opened file

I did manage to capture server logs from one instance where I got the bug and one instance where I did not:

Each time I opened the same file from the same $PWD and then opened the same external file.

In the ok case, you can see there are 12 diagnostic entries for [...]/nvim/runtime/lua/vim/shared.lua:

[16:56:36.749][debug][#0:script/provider/diagnostic.lua:330]: publishDiagnostics file:///home/michaelm/.local/share/nvim/runtime/lua/vim/shared.lua 12

...whereas in the bugged case, 12 entries are initially published, but ~10s later a second diagnostic update happens with 68 entries:

[16:58:23.803][debug][#0:script/provider/diagnostic.lua:330]: publishDiagnostics file:///home/michaelm/.local/share/nvim/runtime/lua/vim/shared.lua 12
[16:58:34.087][debug][#0:script/provider/diagnostic.lua:330]: publishDiagnostics file:///home/michaelm/.local/share/nvim/runtime/lua/vim/shared.lua 68

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working Info Needed More information is required
Projects
None yet
Development

No branches or pull requests

4 participants