Most of the changes fall into a few categories:
* Replace explicit "x86_64" with %target-cpu in lit tests
* Cope with architecture differences in IR/asm/etc. macOS-specific tests
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.
Before this change, we would emit the warning only for swiftmodules; however,
it may be the case that only a swiftinterface (of a different arch) is present
but no swiftmodule is present.
Fixes rdar://problem/50905075.
The standard library (and other Swift modules built by our CMake build system)
has been building module files with an architecture only (e.g., x86_64.swiftmodule)
rather than a proper module triple (x86_86-apple-macosx10.15,
x86_64-apple-ios13.0-simulator, etc.), unlike every other build
system. There are hacks in the compiler and other tools to cope with
this unnecessary build difference. Fix the module file names so we'll
be able to remove the hacks later.
Fixes rdar://problem/49071536.
Currently, when a swiftinterface file fails to load, we emit the specific diagnostics for the failures, followed by a generic “failed to load module ‘Foo’” message. This PR improves that final diagnostic, particularly when the cause may be that the interface was emitted by a newer compiler using backwards-incompatible syntax.
This test fails sometimes with something like:
SOURCE_DIR/test/ModuleInterface/ModuleCache/prebuilt-module-cache-forwarding.swift:47:8: error: malformed compiled module: BUILD_DIR/test-macosx-x86_64/ModuleInterface/ModuleCache/Output/prebuilt-module-cache-forwarding.swift.tmp/MCP/Lib-2XZQCTV44N470.swiftmodule
rdar://58578342
Windows paths attack again. Some paths from the dependency tracker have
mixed folder separators, so comparing textually fail. Additionally some
paths seems to be extended paths (\\?\) which seems not to be liked by
LLVM path utilities.
✔ More informative error messages in case of crashes.
✔ Handling and documenting different cases.
✔ Test cases for different cases.
✔ Make SDKDependencies.swift pass again.
