You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Refactor job response file handling to (hopefully) prevent regressions.
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).
0 commit comments