When enabling the early swift driver on Windows, these tests need to be
adjusted for the new driver name that is reported. Add an additional
spelling for the driver to accommodate that for the testsuite.
Hardlinking to a symlink is not permitted, so use "swift-frontend"
instead of "swift" as the hard-link target.
Also, update one Linux-specific test to check for swift-frontend.
Build swift-frontend as the primary Swift binary, and have
swift/swiftc/etc. symlink over to it. This is a step toward allowing
swift-driver to replace the swift and swiftc binaries.
The `-force-single-frontend-invocation` flag predates WMO and is now an
alias for `-whole-module-optimization`. We should use the latter and let
the former fade into history.
Clang 8 or 9 seems to have changed from EXE to exe. Allow both
capitalizations (which is not important in Windows) as a workaround.
Maybe in the future we can remove the uppercase option.
Use `clang` rather than `clang++` as the linker driver. This ensures
that we do not force a C++ runtime on the general code. This is fine
for now as C++ interop is not yet available for Swift. This prevents
the accidental mix-and-match of various C++ runtimes. This can cause
problems on platforms like android where `libstdc++` is an unsupported
runtime but is generally the default for Linux platforms.
Previously if you passed `-embed-bitcode-marker` to a command that
wasn't producing an object file, it would silently be ignored. This
change puts it inline with `-embed-bitcode` in this same case, which
generates a warning.
Otherwise, we leave optimization opportunities on the table, and in
some cases even fail to remove marker intrinsics inserted by earlier
optimization.
Background: under -embed-bitcode, compilation happens in two stages: a
"frontend" job that compiles Swift code, generates LLVM IR, optimizes
it, and then emits a .bc file; and a "backend" job that takes that
.bc, converts it to assembly, and emits an object file with the
original bitcode embedded. However, there are actually optimization
passes that run before and during that "convert to assembly" step that
were getting completely skipped.
rdar://problem/34864094
Commands like -emit-sil and -emit-module (on its own) do not produce object files.
When -embed-bitcode is also set, the driver runs a backend job to generate a module that fails.
This commit emits a warning instead and ignores the -embed-bitcode option.
https://bugs.swift.org/browse/SR-3352
The "Tool" abstraction wasn't buying us enough to deserve the added
complexity. Now a ToolChain turns Actions into Jobs, and every helper
tool is searched for relative to Swift first. Much simpler.
Swift SVN r31563
Previously we treated this the same as the inputs to the linker, but this
was problematic for a few reasons:
- Backend jobs don't produce
- .o inputs never produce .swiftmodule files (obviously).
So now we:
- explicitly track what can produce a swiftmodule
- don't run module merging if there's nothing to merge
- allow linking without a swiftmodule even under -g
Which gets us closer to being able to run the entire test suite with -g.
rdar://problem/22332569
Swift SVN r31376
This is consistent with Clang, which rejects -mllvm options. All options
Clang /does/ accept should be covered by normal Swift flags.
rdar://problem/21245117
Swift SVN r29386
This already works (and isn't testing much beyond CHECK-MODULE, above),
but it's probably good to have a multi-file non-single-frontend test.
Swift SVN r29078
With both force-single-frontend-invocation and embed-bitcode, we create
CompileJobAction and BackendJobAction, similar to how we handle embed-bitcode
with StandarCompile.
This commit should only affect Bitcode mode.
rdar://20796819
Swift SVN r28129
With both emit-module and embed-bitcode, MergeModule will get the swiftmodule
inputs from CompileJobAction instead of BackendJobAction.
This commit should only affect Bitcode mode since it only touches how we handle
BackendJobAction which is used for Bitcode mode.
rdar://20678489
Swift SVN r27878
With -embed-bitcode, we will invoke swift twice, once to generate the bitcode
file, the second time to perform code generation on the bitcode file.
For now, -embed-bitcode causes -incremental builds to not be incremental,
because of potential issues of mixing the two.
rdar://19048891
Swift SVN r25559
