Refactor job response file handling to (hopefully) prevent regressions. #1036
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
You checked in a |
|
@swift-ci please test |
The new "emit module job" in Swift 5.6 was not marked as supporting response
files (even though it's a `swift-frontend` invocation, all of which should
support response files). This requires certain long `swiftc` invocations to
pass `-no-emit-module-separately` in order to succeed.
There are some other inconsistencies as well; for example, "emit PCM job"
as implemented today does not support response files, when it should.
This change refactors the interaction between `Tool`s and `Job`s. Whether
or not response files are accepted is a property of the **tool** (and the
toolchain), not of individual jobs. So, this adds a `supportsResponseFiles`
method to `Tool` that returns that value (with the toolchain as an argument
so that it can be conditional based on that, as it is for linking).
Then, instead of asking the toolchain for the path to a tool when creating
a job, you ask it for a `ResolvedTool`, which encapsulates the path and the
knowledge about response files. The path can still be overridden if needed
(as it is for linking in non-Darwin toolchains).
This change aims to prevent future regressions for response file handling
in a couple ways:
* When creating a job, the caller no longer has to remember to pass a
parameter indiciating whether it supports response files. (Worse,
that parameter was optional, so auto-complete could easily leave
it out!)
* When introducing a new **tool,** the exhaustive switch in
`Tool.supportsResponseFiles(in:)` requires the author of the change
to acknowledge how it handles response files.
* I've added regression tests to handle the common cases that involve
large command lines (compiling Swift and generating PCMs).
allevato
force-pushed
the
separate-module-response-files
branch
from
34c2972
to
7cf36a7
Compare
Oops! Gotta stop using CWD as my scratch space. Deleted 🔥 |
|
Hmm, did you test this on Windows? I suspect that if the C++ driver is used, this might cause some trouble. |
How can I test it on Windows? It looks like it's not reported among the standard CI checks. Can you be more specific about where you suspect this change would cause new problems? |
+@artemcm for details about the CI setup. You should be able to test this locally with something like:
I'm worried about the driver invocations being introduced which do not pass along |
The invocations introduced in the new test are the same form as the test above it; they're just used to test whether build planning is setting up response file behavior correctly on the jobs it creates, but doesn't invoke anything. As long as those tests pass (asking you offline, you said they do), then I believe these should as well, regardless of host platform. It may take me some time for me to get a working Windows build going, so if you could patch it in and test it out for me, that would also be appreciated 🙂 |
|
|
@swift-ci please test |
|
Thanks for the fast review, @artemcm! In the event that there's another Swift 5.6.x release, I'd love to cherry-pick this into that branch. Would that be possible? If a refactor like this is too high-risk to cherry-pick, would a smaller change that just adds |
copybara-service bot
pushed a commit
to bazelbuild/rules_swift
that referenced
this pull request
Sep 14, 2022
…lang/swift-driver#1036. PiperOrigin-RevId: 474288510
brentleyjones
pushed a commit
to bazelbuild/rules_swift
that referenced
this pull request
Jun 24, 2024
…lang/swift-driver#1036 PiperOrigin-RevId: 474288510 (cherry picked from commit 0fb1b0f) Signed-off-by: Brentley Jones <github@brentleyjones.com>
brentleyjones
pushed a commit
to bazelbuild/rules_swift
that referenced
this pull request
Jun 24, 2024
…lang/swift-driver#1036 PiperOrigin-RevId: 474288510 (cherry picked from commit 0fb1b0f) Signed-off-by: Brentley Jones <github@brentleyjones.com>
cgrindel-self-hosted-renovate bot
referenced
this pull request
in cgrindel/rules_swiftformat
Jul 9, 2024
This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [build_bazel_rules_swift](https://togithub.com/bazelbuild/rules_swift) | http_archive | major | `1.18.0` -> `2.0.0` | --- ### Release Notes <details> <summary>bazelbuild/rules_swift (build_bazel_rules_swift)</summary> ### [`v2.0.0`](https://togithub.com/bazelbuild/rules_swift/releases/tag/2.0.0) [Compare Source](https://togithub.com/bazelbuild/rules_swift/compare/1.18.0...2.0.0) #### What's Changed ##### Breaking Changes - The `swift_module=` tag on `cc_library` targets no longer does anything, and the `swift_c_module` rule was removed: [#​1191](https://togithub.com/bazelbuild/rules_swift/issues/1191) and [#​1224](https://togithub.com/bazelbuild/rules_swift/issues/1224) - Use the new `swift_interop_hint` aspect hint instead - There were also some changes to how the `apple_common.Objc` provider is handled (e.g. bazelbuild/rules_swift@d68b214) - The deprecated swift proto library rules were removed: [#​1193](https://togithub.com/bazelbuild/rules_swift/issues/1193) - The Bzlmod `module.compatibility_level` was increased: [#​1214](https://togithub.com/bazelbuild/rules_swift/issues/1214) - If you ruleset can support both pre-2.0 and post-2.0 **rules_swift**, please set `bazel_dep.max_compatibility_level = 2` instead of bumping your minimum supported version of **rules_swift** - The `swift.disable_system_index` feature is now enabled by default: [#​1252](https://togithub.com/bazelbuild/rules_swift/issues/1252) - Removed `swift.emit_symbol_graph` feature: [#​1229](https://togithub.com/bazelbuild/rules_swift/issues/1229) - Use the new `swift_symbol_graph_extract` rule - Removed the `swift.use_response_files` feature: [#​1275](https://togithub.com/bazelbuild/rules_swift/issues/1275) - Removed the `swift.bundled_xctests` feature: [#​1272](https://togithub.com/bazelbuild/rules_swift/issues/1272) - Removed the implicit output from swift_library: [#​1260](https://togithub.com/bazelbuild/rules_swift/issues/1260) - Moved `swift_usage_aspect` and `SwiftUsageInfo` from **rules_swift** into **rules_apple**: [#​1223](https://togithub.com/bazelbuild/rules_swift/issues/1223) - Manually specifying the `-index-store-path` flag while also using the `swift.index_while_building` is no longer supported: [#​1248](https://togithub.com/bazelbuild/rules_swift/issues/1248) - It is now an error to specify both `swiftinterface` and `swiftmodule` in `swift_import`: [#​1253](https://togithub.com/bazelbuild/rules_swift/issues/1253) ##### Deprecations - Moved rules and other build definitions into their own public files and deprecated the umbrella `swift.bzl` and `proto.bzl` files: [#​1231](https://togithub.com/bazelbuild/rules_swift/issues/1231), [#​1236](https://togithub.com/bazelbuild/rules_swift/issues/1236), and [#​1255](https://togithub.com/bazelbuild/rules_swift/issues/1255) - Please update your `load` statements as the `swift.bzl` file will be removed in the next major release ##### Other changes - Added support for symbol graph extraction with the `swift_symbol_graph_extract` rule: [#​772](https://togithub.com/bazelbuild/rules_swift/issues/772), [#​1195](https://togithub.com/bazelbuild/rules_swift/issues/1195), [#​1246](https://togithub.com/bazelbuild/rules_swift/issues/1246), [#​1270](https://togithub.com/bazelbuild/rules_swift/issues/1270), and [#​1271](https://togithub.com/bazelbuild/rules_swift/issues/1271) - Added support for the `fdo_instrument_order_file` feature: [#​1251](https://togithub.com/bazelbuild/rules_swift/issues/1251) - Added the `swift.add_target_name_to_output` feature, which allows multiple targets in a package to produce the same module name in the same build: [#​1098](https://togithub.com/bazelbuild/rules_swift/issues/1098) and [#​1217](https://togithub.com/bazelbuild/rules_swift/issues/1217) - Added the `swift.thin_lto` and `swift.full_lto` features to enable LTO: [#​1208](https://togithub.com/bazelbuild/rules_swift/issues/1208) - Added the `swift.propagate_generated_module_map` feature to propagate the generated module map: [#​1212](https://togithub.com/bazelbuild/rules_swift/issues/1212) - Added the `swift.headers_always_action_inputs` feature which causes all headers to always be included as inputs to `SwiftCompile` actions, even when using explicit modules: [#​1249](https://togithub.com/bazelbuild/rules_swift/issues/1249) - Added an API to compile a `.swiftinterface` file into a `.swiftmodule`: [#​1250](https://togithub.com/bazelbuild/rules_swift/issues/1250) - Added an XCTest observer to `swift_test` targets that generates a JUnit-style XML log at the path in the `XML_OUTPUT_PATH` environment variable defined by Bazel: [#​1222](https://togithub.com/bazelbuild/rules_swift/issues/1222), [#​1242](https://togithub.com/bazelbuild/rules_swift/issues/1242), [#​1263](https://togithub.com/bazelbuild/rules_swift/issues/1263), and [#​1273](https://togithub.com/bazelbuild/rules_swift/issues/1273) - Added a `discover_tests` attribute to `swift_test`: [#​1259](https://togithub.com/bazelbuild/rules_swift/issues/1259), [#​1266](https://togithub.com/bazelbuild/rules_swift/issues/1266), [#​1273](https://togithub.com/bazelbuild/rules_swift/issues/1273), and [#​1274](https://togithub.com/bazelbuild/rules_swift/issues/1274) - Added a mechanism to provide a list of protocol names for constant value extraction: [#​1170](https://togithub.com/bazelbuild/rules_swift/issues/1170) - Added a `swift_common.get_toolchain` helper function: [#​1226](https://togithub.com/bazelbuild/rules_swift/issues/1226), [#​1257](https://togithub.com/bazelbuild/rules_swift/issues/1257), and [#​1258](https://togithub.com/bazelbuild/rules_swift/issues/1258) - `resource_set` is now defined for `SwiftCompile` actions: [#​1241](https://togithub.com/bazelbuild/rules_swift/issues/1241) - Swift compiler sandboxing is now disabled when using Xcode 15.3+, which fixes nested sandboxing errors: [#​1206](https://togithub.com/bazelbuild/rules_swift/issues/1206) - We now correctly add `.swiftmodule` directories to the search path: [#​1245](https://togithub.com/bazelbuild/rules_swift/issues/1245) - We now correctly calculate the minimum supported OS when calculating the target triple for 'arm64-apple-ios<version>-simulator' targets: [#​1247](https://togithub.com/bazelbuild/rules_swift/issues/1247) - The new driver is now used on Xcode 14+ since it contains the fixes in [https://github.com/apple/swift-driver/pull/1036](https://togithub.com/apple/swift-driver/pull/1036): [#​1268](https://togithub.com/bazelbuild/rules_swift/issues/1268) - Removed some no-longer-relevant "supports X" features: [#​1267](https://togithub.com/bazelbuild/rules_swift/issues/1267) - Fixed LLDB expr evaluation for `swift_{binary,test}` targets only containing Swift in their `srcs`: [#​1269](https://togithub.com/bazelbuild/rules_swift/issues/1269) - Fixed usage of params files in `_swift_proto_compile`: [#​1283](https://togithub.com/bazelbuild/rules_swift/issues/1283) This release is compatible with Bazel 6.x LTS, 7.x LTS, and 8.x rolling releases. #### MODULE.bazel Snippet ```bzl bazel_dep(name = "rules_swift", version = "2.0.0", repo_name = "build_bazel_rules_swift") ``` #### Workspace Snippet ```bzl load("@​bazel_tools//tools/build_defs/repo:http.bzl", "http_archive") http_archive( name = "build_bazel_rules_swift", sha256 = "32eeb4ef33c708d9c9a4ee0fa8475322ef149dabc81884ddc3b50eb2efff7843", url = "https://github.com/bazelbuild/rules_swift/releases/download/2.0.0/rules_swift.2.0.0.tar.gz", ) load( "@​build_bazel_rules_swift//swift:repositories.bzl", "swift_rules_dependencies", ) swift_rules_dependencies() load( "@​build_bazel_rules_swift//swift:extras.bzl", "swift_rules_extra_dependencies", ) swift_rules_extra_dependencies() ``` </details> --- ### Configuration 📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Enabled. ♻ **Rebasing**: Whenever PR is behind base branch, or you tick the rebase/retry checkbox. 👻 **Immortal**: This PR will be recreated if closed unmerged. Get [config help](https://togithub.com/renovatebot/renovate/discussions) if that's undesired. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box --- This PR has been generated by [Renovate Bot](https://togithub.com/renovatebot/renovate). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNi4xMDkuNCIsInVwZGF0ZWRJblZlciI6IjM2LjEwOS40IiwidGFyZ2V0QnJhbmNoIjoibWFpbiJ9--> Co-authored-by: Self-hosted Renovate Bot <361546+cgrindel-self-hosted-renovate[bot]@users.noreply.github.enterprise.com>
renovate bot
referenced
this pull request
in bazel-contrib/rules_bazel_integration_test
Jul 10, 2024
[](https://renovatebot.com) This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [build_bazel_rules_swift](https://togithub.com/bazelbuild/rules_swift) | http_archive | major | `1.18.0` -> `2.1.0` | --- ### Release Notes <details> <summary>bazelbuild/rules_swift (build_bazel_rules_swift)</summary> ### [`v2.1.0`](https://togithub.com/bazelbuild/rules_swift/releases/tag/2.1.0) [Compare Source](https://togithub.com/bazelbuild/rules_swift/compare/2.0.0-rc1...2.1.0) #### What's Changed - Update extract symbol graphs rule to include swiftdoc by [@​luispadron](https://togithub.com/luispadron) in [https://github.com/bazelbuild/rules_swift/pull/1286](https://togithub.com/bazelbuild/rules_swift/pull/1286) This release is compatible with Bazel 6.x LTS, 7.x LTS, and 8.x rolling releases. #### MODULE.bazel Snippet ```bzl bazel_dep(name = "rules_swift", version = "2.1.0", repo_name = "build_bazel_rules_swift") ``` #### Workspace Snippet ```bzl load("@​bazel_tools//tools/build_defs/repo:http.bzl", "http_archive") http_archive( name = "build_bazel_rules_swift", sha256 = "8e0c72aa2be5ae44da44521c46e0700df184953e8dbc5d5423222b8cb141c64f", url = "https://github.com/bazelbuild/rules_swift/releases/download/2.1.0/rules_swift.2.1.0.tar.gz", ) load( "@​build_bazel_rules_swift//swift:repositories.bzl", "swift_rules_dependencies", ) swift_rules_dependencies() load( "@​build_bazel_rules_swift//swift:extras.bzl", "swift_rules_extra_dependencies", ) swift_rules_extra_dependencies() ``` ### [`v2.0.0`](https://togithub.com/bazelbuild/rules_swift/releases/tag/2.0.0) [Compare Source](https://togithub.com/bazelbuild/rules_swift/compare/1.18.0...2.0.0-rc1) #### What's Changed ##### Breaking Changes - The `swift_module=` tag on `cc_library` targets no longer does anything, and the `swift_c_module` rule was removed: [#​1191](https://togithub.com/bazelbuild/rules_swift/issues/1191) and [#​1224](https://togithub.com/bazelbuild/rules_swift/issues/1224) - Use the new `swift_interop_hint` aspect hint instead - There were also some changes to how the `apple_common.Objc` provider is handled (e.g. bazelbuild/rules_swift@d68b214) - The deprecated swift proto library rules were removed: [#​1193](https://togithub.com/bazelbuild/rules_swift/issues/1193) - The Bzlmod `module.compatibility_level` was increased: [#​1214](https://togithub.com/bazelbuild/rules_swift/issues/1214) - If you ruleset can support both pre-2.0 and post-2.0 **rules_swift**, please set `bazel_dep.max_compatibility_level = 2` instead of bumping your minimum supported version of **rules_swift** - The `swift.disable_system_index` feature is now enabled by default: [#​1252](https://togithub.com/bazelbuild/rules_swift/issues/1252) - Removed `swift.emit_symbol_graph` feature: [#​1229](https://togithub.com/bazelbuild/rules_swift/issues/1229) - Use the new `swift_symbol_graph_extract` rule - Removed the `swift.use_response_files` feature: [#​1275](https://togithub.com/bazelbuild/rules_swift/issues/1275) - Removed the `swift.bundled_xctests` feature: [#​1272](https://togithub.com/bazelbuild/rules_swift/issues/1272) - Removed the implicit output from swift_library: [#​1260](https://togithub.com/bazelbuild/rules_swift/issues/1260) - Moved `swift_usage_aspect` and `SwiftUsageInfo` from **rules_swift** into **rules_apple**: [#​1223](https://togithub.com/bazelbuild/rules_swift/issues/1223) - Manually specifying the `-index-store-path` flag while also using the `swift.index_while_building` is no longer supported: [#​1248](https://togithub.com/bazelbuild/rules_swift/issues/1248) - It is now an error to specify both `swiftinterface` and `swiftmodule` in `swift_import`: [#​1253](https://togithub.com/bazelbuild/rules_swift/issues/1253) ##### Deprecations - Moved rules and other build definitions into their own public files and deprecated the umbrella `swift.bzl` and `proto.bzl` files: [#​1231](https://togithub.com/bazelbuild/rules_swift/issues/1231), [#​1236](https://togithub.com/bazelbuild/rules_swift/issues/1236), and [#​1255](https://togithub.com/bazelbuild/rules_swift/issues/1255) - Please update your `load` statements as the `swift.bzl` file will be removed in the next major release ##### Other changes - Added support for symbol graph extraction with the `swift_symbol_graph_extract` rule: [#​772](https://togithub.com/bazelbuild/rules_swift/issues/772), [#​1195](https://togithub.com/bazelbuild/rules_swift/issues/1195), [#​1246](https://togithub.com/bazelbuild/rules_swift/issues/1246), [#​1270](https://togithub.com/bazelbuild/rules_swift/issues/1270), and [#​1271](https://togithub.com/bazelbuild/rules_swift/issues/1271) - Added support for the `fdo_instrument_order_file` feature: [#​1251](https://togithub.com/bazelbuild/rules_swift/issues/1251) - Added the `swift.add_target_name_to_output` feature, which allows multiple targets in a package to produce the same module name in the same build: [#​1098](https://togithub.com/bazelbuild/rules_swift/issues/1098) and [#​1217](https://togithub.com/bazelbuild/rules_swift/issues/1217) - Added the `swift.thin_lto` and `swift.full_lto` features to enable LTO: [#​1208](https://togithub.com/bazelbuild/rules_swift/issues/1208) - Added the `swift.propagate_generated_module_map` feature to propagate the generated module map: [#​1212](https://togithub.com/bazelbuild/rules_swift/issues/1212) - Added the `swift.headers_always_action_inputs` feature which causes all headers to always be included as inputs to `SwiftCompile` actions, even when using explicit modules: [#​1249](https://togithub.com/bazelbuild/rules_swift/issues/1249) - Added an API to compile a `.swiftinterface` file into a `.swiftmodule`: [#​1250](https://togithub.com/bazelbuild/rules_swift/issues/1250) - Added an XCTest observer to `swift_test` targets that generates a JUnit-style XML log at the path in the `XML_OUTPUT_PATH` environment variable defined by Bazel: [#​1222](https://togithub.com/bazelbuild/rules_swift/issues/1222), [#​1242](https://togithub.com/bazelbuild/rules_swift/issues/1242), [#​1263](https://togithub.com/bazelbuild/rules_swift/issues/1263), and [#​1273](https://togithub.com/bazelbuild/rules_swift/issues/1273) - Added a `discover_tests` attribute to `swift_test`: [#​1259](https://togithub.com/bazelbuild/rules_swift/issues/1259), [#​1266](https://togithub.com/bazelbuild/rules_swift/issues/1266), [#​1273](https://togithub.com/bazelbuild/rules_swift/issues/1273), and [#​1274](https://togithub.com/bazelbuild/rules_swift/issues/1274) - Added a mechanism to provide a list of protocol names for constant value extraction: [#​1170](https://togithub.com/bazelbuild/rules_swift/issues/1170) - Added a `swift_common.get_toolchain` helper function: [#​1226](https://togithub.com/bazelbuild/rules_swift/issues/1226), [#​1257](https://togithub.com/bazelbuild/rules_swift/issues/1257), and [#​1258](https://togithub.com/bazelbuild/rules_swift/issues/1258) - `resource_set` is now defined for `SwiftCompile` actions: [#​1241](https://togithub.com/bazelbuild/rules_swift/issues/1241) - Swift compiler sandboxing is now disabled when using Xcode 15.3+, which fixes nested sandboxing errors: [#​1206](https://togithub.com/bazelbuild/rules_swift/issues/1206) - We now correctly add `.swiftmodule` directories to the search path: [#​1245](https://togithub.com/bazelbuild/rules_swift/issues/1245) - We now correctly calculate the minimum supported OS when calculating the target triple for 'arm64-apple-ios<version>-simulator' targets: [#​1247](https://togithub.com/bazelbuild/rules_swift/issues/1247) - The new driver is now used on Xcode 14+ since it contains the fixes in [https://github.com/apple/swift-driver/pull/1036](https://togithub.com/apple/swift-driver/pull/1036): [#​1268](https://togithub.com/bazelbuild/rules_swift/issues/1268) - Removed some no-longer-relevant "supports X" features: [#​1267](https://togithub.com/bazelbuild/rules_swift/issues/1267) - Fixed LLDB expr evaluation for `swift_{binary,test}` targets only containing Swift in their `srcs`: [#​1269](https://togithub.com/bazelbuild/rules_swift/issues/1269) - Fixed usage of params files in `_swift_proto_compile`: [#​1283](https://togithub.com/bazelbuild/rules_swift/issues/1283) This release is compatible with Bazel 6.x LTS, 7.x LTS, and 8.x rolling releases. #### MODULE.bazel Snippet ```bzl bazel_dep(name = "rules_swift", version = "2.0.0", repo_name = "build_bazel_rules_swift") ``` #### Workspace Snippet ```bzl load("@​bazel_tools//tools/build_defs/repo:http.bzl", "http_archive") http_archive( name = "build_bazel_rules_swift", sha256 = "32eeb4ef33c708d9c9a4ee0fa8475322ef149dabc81884ddc3b50eb2efff7843", url = "https://github.com/bazelbuild/rules_swift/releases/download/2.0.0/rules_swift.2.0.0.tar.gz", ) load( "@​build_bazel_rules_swift//swift:repositories.bzl", "swift_rules_dependencies", ) swift_rules_dependencies() load( "@​build_bazel_rules_swift//swift:extras.bzl", "swift_rules_extra_dependencies", ) swift_rules_extra_dependencies() ``` </details> --- ### Configuration 📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Enabled. ♻ **Rebasing**: Whenever PR is behind base branch, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box --- This PR has been generated by [Mend Renovate](https://www.mend.io/free-developer-tools/renovate/). View repository job log [here](https://developer.mend.io/github/bazel-contrib/rules_bazel_integration_test). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNy40MjUuMSIsInVwZGF0ZWRJblZlciI6IjM3LjQyNS4xIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6W119--> Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
](https://renovatebot.com){kind=link}
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The new "emit module job" in Swift 5.6 was not marked as supporting response
files (even though it's a
swift-frontendinvocation, all of which shouldsupport response files). This requires certain long
swiftcinvocations topass
-no-emit-module-separatelyin order to succeed.There are some other inconsistencies as well; for example, "emit PCM job"
as implemented today does not support response files, when it should.
This change refactors the interaction between
Tools andJobs. Whetheror not response files are accepted is a property of the tool (and the
toolchain), not of individual jobs. So, this adds a
supportsResponseFilesmethod to
Toolthat returns that value (with the toolchain as an argumentso that it can be conditional based on that, as it is for linking).
Then, instead of asking the toolchain for the path to a tool when creating
a job, you ask it for a
ResolvedTool, which encapsulates the path and theknowledge about response files. The path can still be overridden if needed
(as it is for linking in non-Darwin toolchains).
This change aims to prevent future regressions for response file handling
in a couple ways:
parameter indiciating whether it supports response files. (Worse,
that parameter was optional, so auto-complete could easily leave
it out!)
Tool.supportsResponseFiles(in:)requires the author of the changeto acknowledge how it handles response files.
large command lines (compiling Swift and generating PCMs).