Delete `Collection+Only.swift`, `Duration+Seconds.swift`,
`FileManagerExtensions.swift`, `PipeAsStringHandler.swift`, and
`URLExtensions.swift` from `Sources/SwiftExtensions/`. The same
APIs now live in swift-tools-protocols as `@_spi(SourceKitLSP)
public` declarations.
Update each call site to add `@_spi(SourceKitLSP) import
ToolsProtocolsSwiftExtensions` next to the existing
`import SwiftExtensions`. Add the
`_ToolsProtocolsSwiftExtensionsForPlugin` dependency and the
`ToolsProtocolsSwiftExtensions=_ToolsProtocolsSwiftExtensionsForPlugin`
module alias to the `SwiftSourceKitClientPlugin` target in both
`Package.swift` and the corresponding `CMakeLists.txt`.
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.
CMake was previously doing this itself before 4.0, but seems to be
inserting `/usr/bin/*` now. Resolve the `/usr/bin` trampoline ourselves
in a similar fashion to swiftly (but with xcrun).
Resolves rdar://163462990.
Replace usages of `Optional.map` and `Optional.flatMap` by if expressions or other expressions.
I personally find `Optional.map` to be hard to read because `map` implies mapping a collection to me. Usually the alternative constructs seem clearer to me.
The modulo operator associated `0` and `100`, so the computation here was essentially `handle?.numericValue ?? (0 % 100)`, equivalent to `handle?.numericValue ?? 0`, which means that we didn’t acutally perform modulo operations on the numeric value, which means that we would exceed the maximum number of `os_log_t` objects after some time.
rdar://162891887
Rename `LineTable.replace(utf8Offset:length:with)` to `tryReplace`
and bail if the provided range is out of bounds of the buffer. This
ensures we match the behavior of SourceKit when handling an
`editor.replacetext` request.
rdar://161268691
When resolving documentation for code completion items, we fetch full
documentation through the newly added
`swiftide_completion_item_get_doc_full_copy` SourceKitD function, if not
found we fallback to brief documentation as before using
`swiftide_completion_item_get_doc_brief`.
> [!NOTE]
> Unlike brief documentation, SourceKitD doesn't cache full
documentation for completion results to avoid bloating memory with a lot
of large strings.
>
> As of now, SourceKit-LSP doesn't cache completion item documentation
either, should we introduce a new full documentation cache (e.g. using
`LRUCache`)?
- I think there are valid calls with mixing inline and trailing closures (notably `Debouncer`), so I’m considering whether we should disable that rule.
- The `forEach` rule is a little annoying because we have `forEach` on `SKDResponseArray`. But it caught two cases of using `forEach` on arrays, so I think it’s worth keeping.
There is only one real class that implements the `SourceKitD` protocol, so there really isn’t any need for the protocol + class split at all. Unify them to make code simpler to reason about.
I feel like the implementations are actually simpler if we split them. This will also allow us to add more advanced logic to the JSON compilation database build system in the future, such as inferring the toolchain from the compile command.
We need to jump through a few extra hoops when the SourceKit plugin is located in SourceKit-LSP’s build folder and we are using `sourcekitd_plugin_initialize` instead of `sourcekitd_plugin_initialize_2`.
This adds a sourcekitd plugin that drives the code completion requests. It also includes a `CompletionScoring` module that’s used to rank code completion results based on their contextual match, allowing us to show more relevant code completion results at the top.
Rintaro Ishizaki
Ben Barham
Anthony Latsis
Alex Hoppen
Owen Voorhees
Hamish Knight
Ahmed Elrefaey