[SR-16080] SourceKit-LSP isn't aware of changes in other files

[adam-fowler]

Previous ID	SR-16080
Radar	None
Original Reporter	@adam-fowler
Type	Bug

Environment

swift-driver version: 1.45.2 Apple Swift version 5.6 (swiftlang-5.6.0.323.62 clang-1316.0.20.8)

Visual Studio Code: 1.65.2

vscode-swift: 0.4.1

Additional Detail from JIRA

Votes	0
Component/s	SourceKit-LSP
Labels	Bug
Assignee	None
Priority	Medium

md5: 00ca6d48e63005108f7d259bffdb1d9a

Issue Description:

Changes in one file are not always registered by another.

Repro:

• Create a new project

• Open VSCode

• Create a file and add a struct called Test

• Create a second file and add a function using a struct called Test2

• Go back to first file and rename Test to Test2 such that your code will compile

• The "cannot find type 'Test2' in scope" error still displays

• Compile the project (notice it compiles fine)

• The "cannot find type 'Test2' in scope" error still displays.

• The only way to fix this is to edit the second file and re-type Test2

Expected:

Changes that fix an error in another file should register as fixing that error

[ahoppen]

This is a non-trivial problem to solve. We don’t know which files are currently displayed to the user and we don’t want to re-compute live issues for all open files since that’s a waste of resources. A workaround for this would be to close and re-open the file in SourceKit-LSP when it receives focus in VSCode because this will cause diagnostics to be re-computed.

We might want to a pull-diagnostics model using the textDocument/diagnostic request introduced in SourceKit-LSP 3.17. That would allow the client to pull new diagnostics when a file receives focus.

[ahoppen]

rdar://95596860

[tristanlabelle]

Hello @ahoppen , I'm from The Browser Company, and we are tracking this issue as a concern for the developer experience with Swift on Windows. We'd be open to looking into fixing it and I first wanted to loop back with project maintainers as to whether this is being or has been investigated already, or if you have any additional info that would help someone looking into this. Does fixing this necessarily imply implementing support for pull diagnostics? Are there smaller fixes that might give us a quick win? What would be the estimated cost of a fix (days, weeks, months?) Thanks for any pointers!

[ahoppen]

I don’t think anyone has actively looked into this issue. My comment from last year is pretty much still the current state. I’m happy to assist you in the design. I think that implementing pull-diagnostics is the proper approach here and it shouldn’t be too difficult because sourcekitd (the service that backs the Swift’s semantic functionality) now has a request for that as well (search for RequestDiagnostics in https://github.com/apple/swift).

As to how long it will take to fix it, I would guess that it will be in the order of days if you are not familiar with SourceKit-LSP but have a general understanding of LSP in general.

[adam-fowler]

@tristanlabelle great work. Looking forward to checking this out.