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.
