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
`SwiftPMWorkspace.reloadPackage` called `loadPackageGraph`, which causes package resolution and could thus update `Package.resolved`. This caused race conditions when `swift package update` was run from terminal while sourcekit-lsp is running since sourcekit-lsp was notified about the file changes and thus reloaded the pacakge to get build settings for the modified files.
Set `forceResolvedVersions` to only resolve packages based on the versions in `Package.resolved`, eliminating this problem.
Fixes https://github.com/apple/sourcekit-lsp/issues/707
rdar://105173375
Generate swiftinterface for symbol lookup
When a symbol definition returns it is in a swiftinterface file, create textual version of swiftinterface and return that in response.
Extend OpenInterface to also seatch for a symbol
Fix warning
Syntax changes after review
Move module name split into OpenInterfaceRequest
Use group names when running open interface request
Requested changes from PR
rename symbol to symbolUSR
Cleanup OpenInterfaceRequest.init
Fix tests
Added testDefinitionInSystemModuleInterface
Use SwiftPMPackage test module
Added version of buildAndIndex that includes system symbols
Merge buildAndIndexWithSystemSymbols with buildAndIndex
Added specific test project for system swiftinterface tests
Add multiple tests for various system modules
In addition to Swift Concurrency, Swift 5.5 also introduces `get throws` properties, which would allow us to fix numerous warnings related to non-throwing `AbsolutePath.init` deprecation.
SKSupport now requires a link against Foundation, update the build
system to track that dependency.
Co-authored-by: Max Desiatov <m_desiatov@apple.com>
The dependency on `TSCUtility` was strictly for identifying the platform
of execution. This logic is relatively self-contained and effectively an
extension over an enumeration. Replicate this logic with updates for new
syntactic improvements. This allows us to partially reduce dependency on
swift-tools-support-core. The dependency on TSCBasic is more complicated
to remove due to the extensive use of `AbsolutePath`.
Co-authored-by: Alex Hoppen <alex@alexhoppen.de>
Building upon the infrastructure that requests the lexical structure of the document from SwiftSyntax, redo the folding ranges request using the tree directly. This corrects a number of inconsistencies in the tests mostly due to incorrect SourceLocations in the semantic ASTs and the line comment merging logic.
We are moving to a better model for TSC's path APIs in apple/swift-tools-support-core#353. The previous API is still available (but deprecated) as much as possible, but since SourceKit-LSP was using `resolveSymlinks` (which is now throwing) quite a bit, there are some changes necessary.
Re-core the "lexical" token stream on top of SwiftSyntax and call into the parser to (re-)generate these "lexical tokens" when the document changes. Leave the semantic tokens alone since they take some non-zero amount of name lookup to fully resolve references to fully replicate.
A declaration request is similar to a definition request, except that it is expected to return (potentially) many results across the workspace for a given reference. For example, an inline function or macro may have many declarations in the workspace, but only one "good" or canonical definition. For now, this is only implemented by forwarding the request on to clangd since I'm unfamiliar with a SourceKit query for this.
For languages like Swift that lack such a sharp declaration/definition split, we could potentially use this request to provide navigable metadata on linked definitions. For example, the declaration for a type reference would include all extensions of that type in the workspace.
