This one `DEPCHANGE-DAG: SDKDependencies.swift` used to match because
the expansion of the `%t` temp dir contained the substring
"SDKDependencies.swift", but this is now sanitized to `TMP_DIR`.
It is expected to rebuild modules from swiftinterface when the C++
interop is enabled in clients. The swiftmodule produced is different.
Make sure the rebuilt module is kept under a distinct cache key to avoid
reusing previously compiled modules in an incompatible mode.
When setting up the ModuleInterfaceChecker, prefer using the module
cache path from command-line invocation `-module-cache-path` before
falling back to clang options.
Usually those two yield the same result, except for LLDB under direct
cc1 argument mode and explicit module build. Under such mode, the cc1
option for module cache path will be stripped since the output PCMs are
explicit passed as output. When LLDB attempted to do an implicit module
compilation for the swift interface, it will not be able to locate the
module cache path from cc1 arguments. On the other hand, the module
cache option has already be inherited by the sub-instance so it can just
directly be located there.
rdar://137610484
The SDK build version is a decent heuristic for expected changes in the
SDK. Any change in SDK, to clang headers in particular, can break
references from cached swiftmodules.
Track the SDK build version as part of the swiftmodule cache hash. This
will ensure we rebuild from swiftinterfaces on SDK updates.
rdar://122655978
Inject the necessary module maps and apinotes via the VFS. This cleans
up the developer build in preparation for a secondary change to remove
this need for deployed scenarios as well. Injecting the content via the
VFS will enable us restore the ability to work with a pristine
installation of Visual Studio, dropping the custom action for the Swift
installer, and open the pathway to per-user installation of Swift.
Thanks to @bnbarham for the help and discussion in resolving the test
issues.
The `__future__` we relied on is now, where the 3 specific things are
all included [since Python 3.0](https://docs.python.org/3/library/__future__.html):
* absolute_import
* print_function
* unicode_literals
* division
These import statements are no-ops and are no longer necessary.
This normalizes the path so that we always have the mapping in normal
form. This fixes a bug in the cross-module import tracing, allowing us
to finally enable the test on Windows.
The error shown when the compiler fails to build a module from its
textual interface has been creating some confusion. This is a proposal
to make it more useful to the programmer not working in the SDK, insist
on looking at the previous errors first, put less emphasis on possible
compiler bugs, and always show alternatives to the incompatible
compilers issue as this is the most common case now.
Prebuilt-module directory now contains a SystemVersion.plist file copied from the SDK
it's built from. This patch teaches the compiler to remark this version and the SDK version
when -Rmodule-interface-rebuild is specified. The difference between these versions could
help us debug unusable prebuilt modules.
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
Previously we were linking in all SIL entities
if the input was a serialized non-SIB AST, and
`-disable-sil-linking` wasn't specified. However
none of the tests appear to want this behaviour.
Stop calling `SerializedSILLoader::getAll`, and
remove the `-disable-sil-linking` option, as this
is now the default behaviour.
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.
