lit.py currently allows any substring of `target_triple` to be used as a
feature in REQUIRES/UNSUPPORTED/XFAIL. This results in various forms of
the OS spread across the tests and is also somewhat confusing since they
aren't actually listed in the available features.
Modify all OS-related features to use the `OS=` version that Swift adds
instead. We can later remove `config.target_triple` so that these don't
the non-OS versions don't work in the first place.
This will enable users to try out the '-enable-ossa-modules' flag if their
compiler supports it and get OSSA code on all inlinable code that they use. The
idea is that this is a nice way to stage this in and get more testing.
The specific implementation is that the module interface loader:
1. Knows if enable ossa modules is enabled not to search for any compiled
modules. We always rebuild from the interface file on the system.
2. Knows that if enable ossa modules is enabled to mixin a bit into the module
interface loader cache hash to ensure that we consider the specialized ossa
compiled modules to be different than the modules in that cache from the system.
This ensures that when said flag is enabled, the user transparently gets all
their code in OSSA form from transparent libraries.
Including all the system header dependencies and `stat`ing them all the time introduces significant performance overhead for normal compilation, and other features like code-completion, without being worth it in practice.
The `env -u` flag is not portable and not available on all platforms, so
this unit test will fail when the feature is unavailable. Instead of
trying to unset the field, just erase it instead, since trying to copy
the entire invoked environment is difficult.
Swift calls the architecture x86_64, OpenBSD calls it amd64. If we use
run_cpu in lit.cfg as-is, then we may need to duplicate lines in each
test for 'x86_64' and 'amd64', which puts a maintenance burden on unit
test developers to ensure they are duplicating changes to each line.
Instead, alias 'amd64' to 'x86_64' for `run_cpu`, but keep the platform
module path referring to 'amd64', in order to distinguish the target
architecture name and the Swift architecture name. This is particularly
relevant for the %target-.*-name pseudovariables used, which should
reference the Swift architecture names.
However, some unit tests are directly referencing %target-cpu directly,
which would break the aliasing. This is done only for swiftinterface
files, so a new substitution is defined in lit.cfg for these variables,
and the affected unit test cases are migrated.
Manually expand out the few places where we had a `not ...` substitution
where the substituted value was invoking `env` to alter the environment.
This pattern is not portable and causes problems when using the
integrated shell, such as on Windows. This was identified during the
LLVM update.
This additionally corrects the use of `not` to indicate that it is
expecting a crashing failure. This was resulting in the Windows tests
failing as `not` was not expecting a crashing failure.
