Commit Graph

22 Commits

Author SHA1 Message Date
Rintaro Ishizaki 83de30d29f Migrate atomic call sites to Synchronization.Atomic and ThreadSafeBox
Replace AtomicBool/UInt8/UInt32/Int32 from
ToolsProtocolsSwiftExtensions with Synchronization.Atomic<T> where
the storage is a static, module-level let, or class stored property.
For local lets captured by @Sendable closures (where Atomic's
~Copyable nature prevents capture), use ThreadSafeBox<T> instead.
2026-05-21 10:58:34 -07:00
Anthony Latsis 6b19657739 Enable ExistentialAny 2025-12-02 12:27:27 +00:00
Owen Voorhees f04b971726 Adopt swift-tools-protocols 2025-10-31 14:11:11 -07:00
Alex Hoppen 76847dbf27 Do not try to infer build settings from a sibling file if determining the target timed out 2025-10-16 07:44:54 +02:00
Alex Hoppen 9dff775010 Enable InferIsolatedConformances and NonisolatedNonsendingByDefault
This allows us to easily get rid of some `@_inheritActorContext`. The others seem to be a little more tricky and I haven’t spent too much time at trying to figure out how to remove the attribute from those.
2025-10-09 00:46:48 +02:00
Alex Hoppen 4fe68eebfb Use activeProcessorCount instead of processorCount in short-lived use-cases
According to https://developer.apple.com/documentation/foundation/processinfo/activeprocessorcount

> Whereas the processorCount property reports the number of advertised processing cores, the activeProcessorCount property reflects the actual number of active processing cores on the system. There are a number of different factors that may cause a core to not be active, including boot arguments, thermal throttling, or a manufacturing defect.

For short-lived workloads like `concurrentMap` we want to parallelize across the number of cores that are currently active, so use `activeProcessorCount` instead. The only case where we want to continue using `processorCount` is the computation of concurrent tasks for `TaskScheduler` because the value is stored for the lifetime of the SourceKit-LSP process and we don’t want to limit parallelism if SourceKit-LSP was launched during a time of thermal throttling.

I stumbled across this while working on #2302
2025-09-22 09:51:41 +02:00
Alex Hoppen c142b601ff Add a timeout for workspace/buildTargets and buildTarget/sources requests
This allows us to provide functionality based on fallback settings for unresponsive BSP servers.

Fixes #2252
2025-09-01 16:12:41 +02:00
Alex Hoppen d887490990 Merge pull request #2231 from ahoppen/exhaustive-swift-format
Apply exhaustive swift-format configuration from swift-syntax
2025-08-11 21:02:32 +02:00
Alex Hoppen 98cd30bb1c Apply exhaustive swift-format configuration from swift-syntax
Apply the exhaustive swift-format configuration from https://github.com/swiftlang/swift-syntax/pull/3117 to sourcekit-lsp. Also apply all automatic formattings.
2025-08-11 09:23:39 +02:00
Alex Hoppen 0b3db5e49b Fix a couple build warnings 2025-08-04 12:32:39 +02:00
Alex Hoppen 14cfd50582 If sourcekitd or clangd don’t respond to a request for 5 minutes, terminate them and use crash recovery to restore behavior
This should be a last stop-gap measure in case sourcekitd or clangd get stuck, don’t respond to any requests anymore and don’t honor cancellation either. In that case we can restore SourceKit-LSP behavior by killing them and using the crash recovery logic to restore functionality.

rdar://149492159
2025-05-07 13:43:28 +02:00
Alex Hoppen a691ee3440 Be a little more pedantic about making sure that we cancel bodyTask and timeoutTask in withTimeout and withTaskPriorityChangedHandler
I have not been able to reason out any concrete issues that this might fix but these are my best guesses to fix the underlying issue of https://github.com/swiftlang/sourcekit-lsp/pull/2088
2025-03-25 14:13:52 -07:00
Alex Hoppen 58bce8225f Add a concurrentForEach method to start a concurrent task for each element in a collection
This is simpler to reason about than creating a `TaskGroup`.
2025-02-26 16:27:56 -08:00
Alex Hoppen 820b454994 Merge pull request #1780 from ahoppen/withtimeout-priority-escalation
Fix a race condition that caused `withTimeout` to not escalate the priority of the body
2024-10-29 13:02:18 -07:00
Alex Hoppen 0b7b565783 Fix a race condition that caused withTimeout to not escalate the priority of the body
rdar://137678566
2024-10-24 16:24:07 -07:00
Alex Hoppen 5bae73fca8 Use fallback build settings if build system doesn’t provide build settings within a timeout
When we receive build settings after hitting the timeout, we call `fileBuildSettingsChanged` on the delegate, which should cause the document to get re-opened in sourcekitd and diagnostics to get refreshed.

rdar://136332685
Fixes #1693
2024-10-16 10:55:29 -07:00
Alex Hoppen 77f02fc706 Yield TimeoutError before cancelling body task in withTimeout
Otherwise, the body task might finish before we yield the `TimeoutError` and thus `withTimeout` would not actually throw a `TimeoutError`.

rdar://137171114
2024-10-08 15:26:02 -07:00
Alex Hoppen 86653b3c45 When withTimeout hits a timeout, don’t wait for cooperative cancellation before returning
Previously, when we hit the timeout in `withTimeout`, we just cancelled `body` but relied on cooperative cancellation before the caller could continue. Since the caller is obviously no longer interested in the operation, we can return with `CancellationError` immediately.

Fixes #883
rdar://116705684
2024-09-30 15:55:09 -07:00
Alex Hoppen 794d4936fe Revert "Use fallback build settings if build system doesn’t provide build settings within a timeout"
This reverts commit 78217ec6a6.
2024-09-27 12:32:47 -07:00
Alex Hoppen 78217ec6a6 Use fallback build settings if build system doesn’t provide build settings within a timeout
When we receive build settings after hitting the timeout, we call `fileBuildSettingsChanged` on the delegate, which should cause the document to get re-opened in sourcekitd and diagnostics to get refreshed.

rdar://136332685
2024-09-26 17:50:58 -07:00
Alex Hoppen 2877675bd5 Adopt package access level
Change a l public declarations to the `package` access level, accept for:
- The `LanguageServerProtocol` module
- The `BuildServerProtocol` module
- `InProcessClient.InProcessSourceKitLSPClient`
- `LanguageServerProtocolJSONRPC` (I would like to create a more ergonomic API for this like `InProcessSourceKitLSPClient` in the future, but for now, we’ll leave it public)

Unfortunately, our pattern of marking functions as `@_spi(Testing) public` no longer works with the `package` access level because declarations at the `package` access level cannot be marked as SPI. I have decided to just mark these functions as `package`. Alternatives would be:
- Add an underscore to these functions, like we did for functions exposed for testing before the introduction of `SPI`
- Use `@testable` import in the test targets and mark the methods as `internal`

Resolves #1315
rdar://128295618
2024-07-19 09:54:30 -07:00
Alex Hoppen b479b2e874 Create a SwiftExtensions module
This allows us to share common Swift utility functions between SourceKit-LSP and LSPLogging.
2024-06-04 07:06:44 -07:00