Migrate remaining AtomicBool / AtomicUInt32 usages in test cases to
ThreadSafeBox / Atomic.
- Closure-captured `AtomicBool` flags become `ThreadSafeBox<Bool>` for
now. We will revisit this when eliminating ThreadSafeBox.
- One `AtomicUInt32` counter (SourceKitDRegistryTests.swift's
`nextToken`) to `Atomic<UInt32>`.
vscode provides an alternative action if the target of goto definition is in the same character range we requested.
this requires the start and end in the LSP response to be properly set, so vscode can see that the current character
is actually part of the request
Previously, language services were held in a global registry on
SourceKitLSPServer and shared across workspaces, requiring complex
lifetime tracking (isImmortal, shutdownOrphanedLanguageServices) to
decide when to tear them down. In practice, every language service
already stored workspace-specific properties (buildServerManager,
semanticIndexManagerTask), so sharing them across workspaces was never
truly safe. Giving each Workspace its own service instances simplifies
lifetime management: services are created when needed and shut down
with their workspace.
Remove LanguageService.isImmortal, the workspace parameter from
canHandle(toolchain:), and the initialize/clientInitialized protocol
requirements.
Use IndexedSingleSwiftFileTestProject with -ignore-module-source-info
to force the generated interface code path. Without this, CI toolchains
(built from source) resolve String to actual stdlib source files, causing
GetReferenceDocumentRequest to receive a file:// URI instead of
sourcekit-lsp://, resulting in an "Invalid Scheme" error.
Closing a generated interface document (sourcekit-lsp:// URI) was
removing the language service for the originating source file because
both share the same buildSettingsFile key. Guard the removal so it
only happens when no other open document shares that key.
Relates to #2209
- **`sourcekit/workspace/symbolNames`** — returns a flat, deduplicated
list of every symbol name in the workspace index (source and indexed
system modules). Clients use this to drive their search UI locally.
- **`sourcekit/workspace/symbolInfo`** — given a list of exact symbol
names, returns `WorkspaceSymbolItem` for each occurrence across all
workspaces, for display in the search result list. Source-file symbols
get `SymbolInformation` with a `file://` location. SDK/stdlib symbols
get a `WorkspaceSymbol` with `location: .uri(…)` The client must call
`workspaceSymbol/resolve` after the user selects an SDK/stdlib symbol to
obtain the concrete interface location.
- **`workspaceSymbol/resolve`** — resolves the deferred
`WorkspaceSymbol` location from `sourcekit/workspace/symbolInfo`. Parses
the `?module=` value into `moduleName`/`groupName`, finds a real source
file via `mainFiles(containing:)`, calls `openGeneratedInterface`, and
returns the symbol with `location` replaced by a full
`sourcekit-lsp://generated-swift-interface/` URI + range (or a temp
`file://` path for clients without `workspace/getReferenceDocument`
support).
Revert the earlier behavior change and add regression test coverage for both modes of `includeDeclaration`. sourcekit-lsp already handles this per the LSP spec.
These tests pin the behavior so it cannot regress.
Related to #2638
References should return use sites, not the definition itself.
The textDocument/references request was including the symbol's own definition, adding noise when navigating from a definition.
This change removes .definition from the roles set when includeDeclaration is true. The existing testReferencesInMacro test was also updated to apply the same principle consistently across the macro case.
Fixes#2638
Introduce `SourceKitDCore` as the protocol boundary between dylib
lifecycle management and the high-level `SourceKitD` API. Its single
lifecycle entry point, `initializeService(api:notificationCallback:)`,
receives the already-loaded `sourcekitd_api_functions_t` from
`SourceKitD.init(core:)`.
`SourceKitDCoreImpl` is the standard implementation: `init` opens the
dylib; `initializeService` registers any plugin paths, calls
`api.initialize()`, and wires the notification handler; `deinit` calls
`shutdown()` and closes the handle. Pre-initialized conformances
implement `initializeService` as a no-op.
Wire a `sourcekitdCoreInjector` hook through `Hooks` so an embedding
host can return a pre-initialized `SourceKitDCore` for a given toolchain
path, preventing `sourcekitd_initialize()` from being called a second
time.
Declare `SourceKitDCoreForPlugin` at its use sites so each call site
can express the exact deinit behavior it needs: `dlclose` for handles
acquired via `RTLD_NOLOAD`, and `leak` for externally-owned handles.
Previously, we always recomputed the inlay hints by calling into
SourceKit. If the document that we compute inlay hints for has recently
changed, SourceKit may need a bit of time to recompute the semantic
analysis. The inlay hints may thus need roughly 200-700ms to be
computed. This causes flickering in VSCode as it removes the old inlay
hints immediately and only displays them again when SourceKit-LSP
returned them.
With this commit we cache the inlay hints and recompute them in the
background. After the recompute is finished we use
`workspace/inlayHint/refresh` request to tell the client to refresh its
inlay hints. On each textDocument/didChange request the cached inlay
hints are shifted according to the text edits to ensure their positions
are still correct. This avoids the flickering as we can always return
the cached inlay hints immediately. The returned hints may however
temporarily show outdated type information until the background
recompute is finished.
When the client opts in to `workspace/tests/refresh` or
`workspace/playgrounds/refresh` via experimental client capabilities,
SourceKit-LSP now maintains a proactive cache of the current test and
playground lists and sends the corresponding `workspace/.../refresh`
notification whenever the cache changes. `workspaceTests()` /
`workspacePlaygrounds()` then serve subsequent fetch requests directly
from the cache.
Add `EntryPointManager`: runs background scans, stores the results,
fires callbacks on changes:
- Start scanning when build targets are updated including initial
updates, any watched files are changed, and index is updated.
- Send '/refresh' server initiated requests when the cache has changed.
- Coalesces rapid invalidations by cancelling any in-flight refresh task.
Also:
- Simplify `SourceKitIndexDelegate` from an `actor` with `AtomicInt32`
to a plain `class`, since it is only called from IndexStoreDB's
internal serial dispatch queue.
When semantic test discovery encounters XCTest methods in an extension it adds the extension definition to the root items list for each child test method. With N test methods, the same extension root appears N times, each copy receiving all N children. After merging, this produces N*N test items instead of N.
The bug is normally masked by the syntactic index, which provides correct results that take priority via combineTests(). This bug was exposed while I was debugging why tests generated by build plugins would appear multiple times. Turns out because they don't exist on disk at the time of the syntatic scan only the semantic results are used, which surfaced the issue.
The fix is to track already-added extension USRs to ensure each extension added once as a root item.
If we have a source item `include/Test.h` that gets copied to `build/Test.h`, we currently don’t provide any semantic functionality for `build/Test.h`. Improve the build settings fallback logic to construct fallback build settings for `build/Test.h` based on `include/Test.h`.
Consolidate all test that test functionality for copy destinations. Also rename the test case because not only headers may be declared as copied using `copyDestinations`.
When semantic test discovery encounters XCTest methods in an extension
it adds the extension definition to the root items list for each child
test method. With N test methods, the same extension root appears N
times, each copy receiving all N children. After merging, this produces
N*N test items instead of N.
The bug is normally masked by the syntactic index, which provides
correct results that take priority via `combineTests()`. This bug was
exposed while I was debugging why tests generated by build plugins would
appear multiple times. Turns out because they don't exist on disk at the
time of the syntatic scan only the semantic results are used, which
surfaced the issue.
The fix is to track already-added extension USRs to ensure each extension
added once as a root item.
Related issue: https://github.com/swiftlang/vscode-swift/issues/2162
Remove hand-written `init?(fromLSPDictionary:)` / `encodeToLSPAny()`
from LSPAnyCodable types, relying instead on the default implementations
backed by `LSPAnyEncoder`/`LSPAnyDecoder`
If the SwiftPM build server is slow to respond, we may get document symbols based on a `SyntaxTreeManager` with fallback build settings, which would not contain the `_test_EverythingUnexpected` experimental feature and which would thus fail.
Similar issues existed in other tests as well.
Rintaro Ishizaki
Steffeeen
femaref
Alex Hoppen
Edward Lee
G.M_YOO
25harsh
Alexander Skvortsov
Owen Voorhees
Paul LeMarquand
Bhushan-Aditya
Pavel Kroupa
Doug Gregor