Adopt swift-tools-protocols #2324
Conversation
owenv
requested review from
ahoppen,
bnbarham,
hamishknight and
rintaro
as code owners
|
I expect I'll need to iterate on this a bit. swiftlang/swift#84882 needs to land before it's testable in CI |
owenv
force-pushed
the
owenv/adopt-swift-tools-protocols
branch
from
cecc4f7 to
c77d687
Compare
|
@swift-ci test |
owenv
force-pushed
the
owenv/adopt-swift-tools-protocols
branch
from
c77d687 to
6de2320
Compare
|
@swift-ci test |
|
@swift-ci test Windows |
owenv
force-pushed
the
owenv/adopt-swift-tools-protocols
branch
from
6de2320 to
31793f4
Compare
|
@swift-ci test |
owenv
force-pushed
the
owenv/adopt-swift-tools-protocols
branch
from
31793f4 to
84b1416
Compare
|
@swift-ci test |
|
@swift-ci test Windows |
owenv
force-pushed
the
owenv/adopt-swift-tools-protocols
branch
10 times, most recently
from
40a68e0 to
8f0f529
Compare
owenv
force-pushed
the
owenv/adopt-swift-tools-protocols
branch
from
8f0f529 to
83337ec
Compare
| let buildSettingsFromBuildServer = await orLog("Getting build settings") { | ||
| if fallbackAfterTimeout { | ||
| try await withTimeout(options.buildSettingsTimeoutOrDefault) { | ||
| try await SwiftExtensions.withTimeout(options.buildSettingsTimeoutOrDefault) { |
There was a problem hiding this comment.
Why do we need to module-qualify this? Shouldn’t this be at a below-SPI access level in swift-tools-protocols and thus there wouldn’t be a name conflict?
There was a problem hiding this comment.
| } | ||
|
|
||
| extension BuildTargetIdentifier: CustomLogStringConvertible { | ||
| @_spi(SourceKitLSP) extension BuildTargetIdentifier: @retroactive CustomLogStringConvertible { |
There was a problem hiding this comment.
Hmm, should this conformance be in swift-tools-protocols? Seems like most people would need to add it. Though I’m not quite sure which module that conformance would live in.
There was a problem hiding this comment.
We could put it in LanguageServerProtocolTransport although it's a bit of a stretch
| @@ -234,18 +234,20 @@ struct SourceKitLSP: AsyncParsableCommand { | |||
| fatalError("failed to redirect stdout -> stderr: \(strerror(errno)!)") | |||
| } | |||
|
|
|||
| LoggingScope.configureDefaultLoggingSubsystem("org.swift.sourcekit-lsp") | |||
There was a problem hiding this comment.
Hmm, this is a little tricky. We’d need to do the same in at least one other places (part from test execution), namely when launching a SourceKitLSP server in-processes using InProcessClient
| @@ -82,6 +83,10 @@ private func createBuildServerManager( | |||
| } | |||
|
|
|||
| final class BuildServerManagerTests: XCTestCase { | |||
| override func setUp() async throws { | |||
There was a problem hiding this comment.
I really dislike having this setUp function in every single test case. Should we instead have a custom class that inherits from XCTestCase and that all our test cases inherit from?
Also, could we make LoggingScope.subsystem not fatalError if no default logging subsystem was set? Instead, maybe just use org.swift or default and log a fault that no logging subsystem has been set? There’s no need to crash the process just because no logging subsystem has been configured.
There was a problem hiding this comment.
I can get behind not crashing, swiftlang/swift-tools-protocols#16
2 participants
Adopt the new package and remove duplicated code