The `WorkspaceConfiguration.default` was being used to populate
the `Workspace`; there was an extra step here needed to assure that
we are propagating the trait configuration to the workspace.
The added test assures that non-default traits that are enabled are
indeed processed as enabled.
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.
testToolsets: sourcekit-lsp is built against a just-built SwiftPM,
which can use macOS 10.13 as the minimum for packages with no explicit
platforms requirement. The preparation step runs the toolchain's
'swift build', which can use a higher macOS minimum deployment target.
The resulting module embeds a higher deployment target, causing a
spurious mismatch diagnostic when the other target imports it.
testBasicSwiftArgs (swiftbuild variant): swift-build can clamp the
deployment target to the SDK's MinimumDeploymentTarget, which can be
above the 10.13 the BSP reports, so the expected triple no longer
matches.
Fix by explicitly setting the deployment target to 13.0 in both test
packages via 'platforms: [.macOS(.v13)]'.
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.
There was feedback in #2621 to update how the `.buildSystem_{config}`
file was be created. While looking as this change, I converted one test
to a parameterized and also ensure the `.buildSystem_{config}` file is
created in the `createFiles()` call.
Relates to #2621
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.
SwiftPM PR #9985 introduce files in the scratch path whose contents
indicate which build system was used to build artifact for a given build
configuration. if this file exist, use it's contents to infer the build
system. Otherwise, fallback to the existing behaviour.
Fixes: #2576
The test was constructing the percent-encoded file URL from `filePath`,
which uses native OS path separators. On Windows this produced a
backslash-separated path inside a `file://` URL, making the URL
malformed. Fix by replacing `+` with `%2B` in `absoluteString` instead,
which is already a well-formed URL string with forward slashes on all
platforms.
rdar://175272642
Binary targets backed by remote `.artifactbundleindex` URLs cause
SwiftPM to re-extract the artifact bundle into the scratch directory
on every package load. The resulting file-change events (delete +
create) for the extracted files triggered another reload, causing an
infinite loop.
Add `isInScratchDirectory` to `fileEventShouldTriggerPackageReload`
to filter out events before the build-settings check. It covers
both the configured scratch directory and the default `.build/`
directory (which receives regular `swift build` output even when
a custom scratch path is configured).
Also add tests using local zip-based binary targets to cover both
the default and custom-scratch-path scenarios. Local zips are used
in the tests to avoid a network dependency; they exercise the same
`isInScratchDirectory` code path even though the infinite loop in
practice requires a remote `.artifactbundleindex` target (where
SwiftPM's checksum mismatch causes re-extraction on every load).
https://github.com/swiftlang/sourcekit-lsp/issues/2615
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.
`inProgressData` was always storing `ContinuousClock.now + debounceDuration`
instead of the computed `targetDate`, causing the debounce deadline to reset
on every call rather than being fixed at the time of the first `scheduleCall`.
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.
Bri Peticca
Rintaro Ishizaki
Steffeeen
femaref
Alex Hoppen
Edward Lee
G.M_YOO
25harsh
Bassam Khouri
Alexander Skvortsov
Owen Voorhees
Paul LeMarquand