7 Commits

Author SHA1 Message Date
Owen Voorhees
f04b971726 Adopt swift-tools-protocols 2025-10-31 14:11:11 -07:00
Alex Hoppen
fbaa7ce75e When PipeAsStringHandler is destroyed, ensure that we flush any pending data
Otherwise, we would not handle the last line if it didn’t end with a newline character.
2025-08-28 09:05:14 +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
Paul LeMarquand
5ab04546e8 Fixup some import related warnings
This patch fixes up:
- 1 File 'Foo.swift' is part of module 'module'; ignoring import
  warning
- 70 "Instance method 'foo' cannot be used in an '@inlinable'
  function because 'module' was not imported by this file" warnings
- 2 "Result of call 'foo' is unused" warnings
2024-07-05 14:11:55 -04:00
Alex Hoppen
9618df80a0 Add documentation about each module's purpose and move some files between modules
The purpose of the different modules wasn’t clearly defined, which lead to inconsistent responsibilities between the different modules. Define each module’s purpose and move a few files between modules to satisfy these definitions.

There are a few more larger changes that will need to be made for a fully consistent module structure. These are FIXMEs in the new Modules.md document and I’ll address them in follow-up PRs.
2024-06-25 07:47:45 -07:00