The same kind of change that we did for `SwiftLanguageServer`. Instead of caching build settings inside `ClangLanguageServerShim`, always call into `BuildSystemManager` to get the build settings.
Instead of storing build settings inside the language servers based on update notifications from the build system, always call into the `BuildSystemManager` to get the build settings.
Overall, I think this is a much clearer separation of concerns and will allow us to remove `SourceKitServer.documentToPendingQueue` in a follow-up commit as `SwiftLanguageServer` can always directly call into `BuildSystemManager` to get build settings and we don’t need to wait for the initial notification to receive the first build settings.
This requies `BuildServerBuildSystem` to keep track of the build settings it has received from the BSP server.
`ClangLanguageServer` still caches build settings locally. `ClangLanguageServer` will change to the same pull-based model in a follow-up commit.
Unfortuantely, we have a few potential out-of-order exeuction possibilities while we migrate everything else to also be asyncronous. But those should be low-probability issues that we can fix in follow-up commits, so I think it’s fine for now. All of these places are marked with `FIXME: (async)`
Since we moved `BuilderServerHandler` and `ClangLanguageServerShim` to directly conform to `MessageHandler`, `SourceKitServer` was the only type inheriting from `LanguageServerEndpoint` and we can thus remove the type.
Previously, the folding range of a block of line comments was ended after the newline of the last line comment, which would usually be the line of the function’s start. That caused VS Code to not show a folding range for the function body itself since it started on the same line that the line comment folding range ended.
Rewrite the trivia folding logic so that the folding range of those line comments ends on the line of the last line comment.
Fixes#803
rdar://114428202
I noticed that the initial package loading can take ~5s. It’s good behavior to inform the client that sourcekit-lsp is busy reloading the package, showing the user that semantic functionality might not be ready yet.
https://github.com/apple/sourcekit-lsp/issues/620
rdar://112498447
We were registering new diagnsotics in `currentDiagnostics` when the diagnostics got pushed to us by sourcekitd, but not when they were pulled using the diagnostic request.
Fixes#776
rdar://112539108
I noticed that the initial package loading can take ~5s. It’s good behavior to inform the client that sourcekit-lsp is busy reloading the package, showing the user that semantic functionality might not be ready yet.
https://github.com/apple/sourcekit-lsp/issues/620
rdar://111917300
We weren’t semantically highlighting references to actors because we missed the `ref_actor` case from the sourcekitd `annotations` response.
Fixes#694
rdar://104573568
