-
Notifications
You must be signed in to change notification settings - Fork 1.4k
[NFC] Vendor AsyncProcess
, make more tests async
#7679
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
Conversation
We'd like to implement more changes to `TSCBasic.Process` without fearing of breaking clients, in addition to the fact that TSC is deprecated. One thing in particular we need is backpressure logic when reading from process instances in plugins communication. Currently, without this logic a naive rewrite of plugins communication with structured concurrency is quite bug-prone. Thus `TSCBasic.Process` is slightly cleaned up and is vendored as `AsyncProcess` in this change. We also give it more coverage in tests by utilizing `async` overloads, which are the overloads we should be using more in the structured concurrency conversion of the SwiftPM codebase.
@swift-ci test |
@swift-ci test |
@swift-ci test windows |
@swift-ci test |
@swift-ci test windows |
Could we put this in its own module instead of "Basics", that module is massive and has so much conflated code that its really hard to reason about |
I'm not entirely convinced there's much benefit to splitting it, the downside would be that our Here for now I'd prefer to roughly keep the status quo: it was in |
Thats a fair point, but I think moving files over is a great opportunity for better hygiene. Mega modules are both slower to build both clean & incremental and bury the lead of the functionality they provide. IMO a good option for splitting the module is exposing async-process to the rest of SwiftPM via the basics module, e.g.: AsyncProcess -> Basics -> the rest of SwiftPM |
This won't work, as |
@swift-ci test |
@swift-ci test windows |
1 similar comment
@swift-ci test windows |
@swift-ci test windows |
1 similar comment
@swift-ci test windows |
@swift-ci test |
I skimmed through all of the renames and mostly read through AsyncProcess itself which looks good to me. |
…xd/async-process-tests # Conflicts: # Sources/Basics/Archiver/TarArchiver.swift # Sources/Build/BuildOperation.swift # Sources/Commands/PackageCommands/Format.swift # Sources/Commands/SwiftTestCommand.swift # Sources/DriverSupport/SPMSwiftDriverExecutor.swift # Sources/PackageLoading/ManifestLoader.swift # Sources/PackageLoading/PkgConfig.swift # Sources/PackageModel/SwiftSDKs/SwiftSDK.swift # Sources/SPMTestSupport/SwiftPMProduct.swift # Sources/SPMTestSupport/misc.swift # Sources/SourceControl/GitRepository.swift # Sources/Workspace/DefaultPluginScriptRunner.swift # Sources/XCBuildSupport/XcodeBuildSystem.swift # Tests/BuildTests/IncrementalBuildTests.swift # Tests/CommandsTests/APIDiffTests.swift # Tests/CommandsTests/BuildCommandTests.swift # Tests/CommandsTests/PackageCommandTests.swift # Tests/CommandsTests/PackageRegistryCommandTests.swift # Tests/CommandsTests/RunCommandTests.swift # Tests/CommandsTests/SwiftSDKCommandTests.swift # Tests/FunctionalTests/MiscellaneousTests.swift # Tests/FunctionalTests/PluginTests.swift # Tests/PackageModelTests/MinimumDeploymentTargetTests.swift
@swift-ci test |
@swift-ci test windows |
@swift-ci test |
@swift-ci test windows |
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.
very happy to see fewer tsc imports. I think with this change we shouldn't need ProcessEnvironmentBlock except for Git
Sources/Basics/AsyncProcess.swift
Outdated
} | ||
process.executableURL = executablePath.asURL | ||
process | ||
.environment = [String: String]( |
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 think this should be [String: String](environment)
@swift-ci test windows |
1 similar comment
@swift-ci test windows |
@swift-ci test windows |
1 similar comment
@swift-ci test windows |
@swift-ci test |
We'd like to implement more changes to `TSCBasic.Process` without fearing of breaking clients, in addition to the fact that TSC is deprecated. One thing in particular we need is backpressure logic (coming in a future PR) when reading from process instances in plugins communication with the host SwiftPM process. Currently without this logic, a naive rewrite of plugins communication with structured concurrency is quite bug-prone, as it loses messages ordering and can quickly fill up all memory with resource-intensive plugins. Thus `TSCBasic.Process` is slightly cleaned up and is vendored as `AsyncProcess` in this change. We also give it more coverage in tests by utilizing `async` overloads, which are the overloads we should be using more in the structured concurrency conversion of the SwiftPM codebase. (cherry picked from commit b86d22e) # Conflicts: # Tests/CommandsTests/PackageCommandTests.swift # Tests/FunctionalTests/MiscellaneousTests.swift # Tests/FunctionalTests/PluginTests.swift # Tests/FunctionalTests/TraitTests.swift
Includes these PRs cherry-picked off `main` * #7605 * #7660 * #7667 * #7682 * #7687 * #7690 * #7684 * #7679 **Explanation**: Cherry-pick of recent NFC changes, which makes it easier to cherry-pick actual bug fixes onto 6.0 due to the reduced number of merge conflicts. **Scope**: broad, includes both modules graph and llbuild-related changes. **Risk**: low, the test suite is passing, no functional changes are included, and cherry-picked changes were incubated on `main` for some time. **Testing**: Existing automated test suite. **Issue**: N/A **Reviewers**: @xedin @MaxDesiatov @rauhul --------- Co-authored-by: Pavel Yaskevich <[email protected]> Co-authored-by: Danny Mösch <[email protected]> Co-authored-by: Rauhul Varma <[email protected]>
We'd like to implement more changes to
TSCBasic.Process
without fearing of breaking clients, in addition to the fact that TSC is deprecated.One thing in particular we need is backpressure logic (coming in a future PR) when reading from process instances in plugins communication with the host SwiftPM process. Currently without this logic, a naive rewrite of plugins communication with structured concurrency is quite bug-prone, as it loses messages ordering and can quickly fill up all memory with resource-intensive plugins.
Thus
TSCBasic.Process
is slightly cleaned up and is vendored asAsyncProcess
in this change. We also give it more coverage in tests by utilizingasync
overloads, which are the overloads we should be using more in the structured concurrency conversion of the SwiftPM codebase.