-
Couldn't load subscription status.
- Fork 320
Adopt swift-tools-protocols #2324
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
I expect I'll need to iterate on this a bit. swiftlang/swift#84882 needs to land before it's testable in CI |
cecc4f7 to
c77d687
Compare
|
@swift-ci test |
c77d687 to
6de2320
Compare
|
@swift-ci test |
|
@swift-ci test Windows |
6de2320 to
31793f4
Compare
|
@swift-ci test |
31793f4 to
84b1416
Compare
|
@swift-ci test |
|
@swift-ci test Windows |
40a68e0 to
8f0f529
Compare
8f0f529 to
83337ec
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
High-level comment: I’d like to investigate if we can reduce the dependency on ToolsProtocolsSwiftExtensions further but that can be a follow-up investigation.
| 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
| } | ||
|
|
||
| extension BuildTargetIdentifier: CustomLogStringConvertible { | ||
| @_spi(SourceKitLSP) extension BuildTargetIdentifier: @retroactive CustomLogStringConvertible { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, hit submit to early
| @@ -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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Adopt the new package and remove duplicated code