6 Commits

Author SHA1 Message Date
Owen Voorhees
f04b971726 Adopt swift-tools-protocols 2025-10-31 14:11:11 -07:00
Alex Hoppen
634ec92921 Move ClangLanguageService to its own module 2025-08-11 09:02:34 +02:00
Alex Hoppen
1cfa8db1d8 Require Swift 6 to build SourceKit-LSP
This significantly cleans up our `import` statements
2025-03-07 08:05:49 -08:00
Alex Hoppen
8cd831b55d Adopt InternalImportsByDefault 2024-09-27 09:17:13 -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
80a35aabe8 Translate the semantic token legend used by clangd to the semantic token legend used by SourceKit-LSP
clangd uses a completely different semantic token legend than SourceKit-LSP (it doesn’t even adhere to the ordering of the pre-defined token types) but we were passing index offsets from clangd through assuming that clangd uses the same legend, which was incorrect.

When retrieving semantic tokens from clangd, translate the semantic tokens from clangd’s legend to SourceKit-LSP’s legend.

rdar://129895062
2024-06-26 09:30:16 +02:00