4 Commits

Author SHA1 Message Date
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
6599292ff5 Add infrastructure to write tests for Swift macros
Add a default package manifest that defines two targets:
 - A macro target named `MyMacro`
 - And executable target named `MyMacroClient`

It builds the macro using the swift-syntax that was already built as part of the SourceKit-LSP build.
Re-using the SwiftSyntax modules that are already built is significantly faster than building swift-syntax in each test case run and does not require internet access.
2024-05-31 21:37:00 -07:00