In LLVM unified builds `%swift_obj_root` points to `<LLVM build dir>/tools/swift`,
and folders like `bin`, `lib` and `share` are not under `swift_obj_root`, which
makes some tests fail.
For the cases in which `%swift_obj_root/lib` was used, replace it by
using `%swift-lib-dir` instead. Replicate `%swift-lib-dir` to create
`%swift-bin-dir` and `%swift-share-dir`, and use those instead of
`%swift_obj_root/bin` and `%swift_obj_root/share`.
This alternates work both in Swift build-script builds and also in LLVM
unified builds.
This will mean that '-disable-implicit-swift-modules' also automatically implies two things:
1. Clang modules must also be explicit, and the importer's clang instance will get '-fno-implicit-modules' and '-fno-implicit-module-maps'
2. The importer's clang instance will no longer get a '-fmodules-cache-path=', since it is not needed in explicit builds
These two tests were changing directories into the temporary, never
changing out of there, and then recreating the temporary, which left the
rest of the test executing in a non-existing directory.
Modify those tests to change out to the previous directory and avoid
executing any command in a non-existing directory.
Using a virutal output backend to capture all the outputs from
swift-frontend invocation. This allows redirecting and/or mirroring
compiler outputs to multiple location using different OutputBackend.
As an example usage for the virtual outputs, teach swift compiler to
check its output determinism by running the compiler invocation
twice and compare the hash of all its outputs.
Virtual output will be used to enable caching in the future.
This test was disabled on Windows through the `MSC_VER` condition. The
failure was due to the redirection of the output which does not behave
entirely the expected way with the lit shell. Use a temporary file
instead and enable the test on Windows.
Instead, stimulate users to follow the referenced bug reporting guidelines,
which contain all the necessary information. We’d rather encourage attempts
at reducing issues before attaching Xcode projects. This is an accompaniment
to https://github.com/apple/swift-org-website/pull/158.
Introduce the `-enable-upcoming-feature X` command-line argument to
allow one to opt into features that will be enabled in an upcoming language
mode. Stage in several features this way (`ConciseMagicFile`,
`ForwardTrailingClosures`, `BareSlashRegexLiterals`).
When we encounter an input or output with an unknown extension 'TY_INVALID', still produce valid JSON specifying the type as "unknown" instead of either crashing or producing malformed JSON.
Resolves rdar://94348593
Experimental features can only be enabled in non-production (+Asserts)
builds. They can be detected with `hasFeature` in the same manner as
"future" features.
The `-enable-experimental-feature X` flag will also look for future
features by that name, so that when an experimental feature becomes an
accepted future feature, it will still be enabled in the same manner.
Switch variadic generics over to this approach, eliminating the
specific LangOption for it.
FrontendTool sets up diagnostic infrastructure early and suppresses stdout diagnostics if frontend-parseable-output is enabled. It then calls `CompilerInstance.setup` which may fail - if it fails, we exit early. But that means we have not gotten a chance to emit parseable-output.
This change moves emission of the `began` parseable message to before `CompilerInstance.setup`, and ensures that a corresponding `finished` message is emitted if the setup fails.
Resolves rdar://93187783
Generation of valid JSON output for parseable output depends on being able to determine file types of inputs and outputs of compilation tasks. FileTypes.def defines multiple file kinds with multiple '.' extensions, such as '.abi.json' or '.features.json', but existing code attempted to compute file outputs only using the trailing suffix of the path after the last '.'. This led to some files not being recognized, which led to us not being able to generate valid JSON.
Resolves rdar://92961252
Don't run the objc-arc-contract pass when disable-llvm-optzns is passed.
In pipeline setups where the swift-frontend is called twice;
- the first time to create bitcode
- the second time to generate object code from the bitcode (using
disable-llvm-optzns)
we don't want to run the objc-arc-contract pass twice.
rdar://91908312
