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

Diagnostics are not refreshed after build when a new file is added #1116

Closed
wojciech-kulik opened this issue Mar 3, 2024 · 1 comment · Fixed by #1180
Closed

Diagnostics are not refreshed after build when a new file is added #1116

wojciech-kulik opened this issue Mar 3, 2024 · 1 comment · Fixed by #1180

Comments

@wojciech-kulik
Copy link

wojciech-kulik commented Mar 3, 2024

Steps to reproduce:

  1. Add a new file with some class.
  2. Reference this class within the same target.
  3. Build the project using xcodebuild command.

Actual result:
The build succeeds, LSP doesn't print any errors in the log, LSP still shows issues:
image

Expected result:
LSP should be automatically refreshed and errors should disappear.

Workaround:
Restart LSP (in Neovim :LspRestart).

Version:
Sourcekit-lsp provided by Xcode Version 15.2 (15C500b)

Related issue:
wojciech-kulik/xcodebuild.nvim#56

Notes:
I reproduced it both in Neovim and Visual Studio Code, so I guess it's not the LSP client's fault.

@ahoppen
Copy link
Collaborator

ahoppen commented Mar 3, 2024

Tracked in Apple’s issue tracker as rdar://123971779

ahoppen added a commit to ahoppen/sourcekit-lsp that referenced this issue Apr 17, 2024
…ule` file has been changed

When the client sends us `workspace/didChangeWatchedFiles` notification of an updated `.swift` file, we should refresh the other open files in that module since they might be referencing functions from that updated file.

If a `.swiftmodule` file has been updated, we refresh all the files within the package since they might import that module. Technically, we would only need to refresh files that are in module that are downstream of the updated module but we don’t currently have that information easily available from SwiftPM. Also, usually, if the client has a file from a low-level module open, he’ll be working on that module which means that such an optimization won’t help. The real solution here is to wait for us to finish preparation (which we would exactly know when it finishes since sourcekit-lsp would schedule it) but for that we need to implement background preparation.

Fixes apple#620
Fixes apple#1116
rdar://99329579
rdar://123971779
ahoppen added a commit to ahoppen/sourcekit-lsp that referenced this issue Apr 18, 2024
…ule` file has been changed

When the client sends us `workspace/didChangeWatchedFiles` notification of an updated `.swift` file, we should refresh the other open files in that module since they might be referencing functions from that updated file.

If a `.swiftmodule` file has been updated, we refresh all the files within the package since they might import that module. Technically, we would only need to refresh files that are in module that are downstream of the updated module but we don’t currently have that information easily available from SwiftPM. Also, usually, if the client has a file from a low-level module open, he’ll be working on that module which means that such an optimization won’t help. The real solution here is to wait for us to finish preparation (which we would exactly know when it finishes since sourcekit-lsp would schedule it) but for that we need to implement background preparation.

Fixes apple#620
Fixes apple#1116
rdar://99329579
rdar://123971779
ahoppen added a commit to ahoppen/sourcekit-lsp that referenced this issue Apr 23, 2024
…ule` file has been changed

When the client sends us `workspace/didChangeWatchedFiles` notification of an updated `.swift` file, we should refresh the other open files in that module since they might be referencing functions from that updated file.

If a `.swiftmodule` file has been updated, we refresh all the files within the package since they might import that module. Technically, we would only need to refresh files that are in module that are downstream of the updated module but we don’t currently have that information easily available from SwiftPM. Also, usually, if the client has a file from a low-level module open, he’ll be working on that module which means that such an optimization won’t help. The real solution here is to wait for us to finish preparation (which we would exactly know when it finishes since sourcekit-lsp would schedule it) but for that we need to implement background preparation.

Fixes apple#620
Fixes apple#1116
rdar://99329579
rdar://123971779
plemarquand pushed a commit to plemarquand/sourcekit-lsp that referenced this issue Apr 24, 2024
…ule` file has been changed

When the client sends us `workspace/didChangeWatchedFiles` notification of an updated `.swift` file, we should refresh the other open files in that module since they might be referencing functions from that updated file.

If a `.swiftmodule` file has been updated, we refresh all the files within the package since they might import that module. Technically, we would only need to refresh files that are in module that are downstream of the updated module but we don’t currently have that information easily available from SwiftPM. Also, usually, if the client has a file from a low-level module open, he’ll be working on that module which means that such an optimization won’t help. The real solution here is to wait for us to finish preparation (which we would exactly know when it finishes since sourcekit-lsp would schedule it) but for that we need to implement background preparation.

Fixes apple#620
Fixes apple#1116
rdar://99329579
rdar://123971779
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants