When loading a module supporting multiple targets, the module loader now looks for a file named with a normalized version of the target triple first, and only falls back to the architecture name if the normalized triple is not found.
This changes the Swift resource directory from looking like
lib/
swift/
macosx/
libswiftCore.dylib
libswiftDarwin.dylib
x86_64/
Swift.swiftmodule
Swift.swiftdoc
Darwin.swiftmodule
Darwin.swiftdoc
to
lib/
swift/
macosx/
libswiftCore.dylib
libswiftDarwin.dylib
Swift.swiftmodule/
x86_64.swiftmodule
x86_64.swiftdoc
Darwin.swiftmodule/
x86_64.swiftmodule
x86_64.swiftdoc
matching the layout we use for multi-architecture swiftmodules
everywhere else (particularly frameworks).
There's no change in this commit to how Linux swiftmodules are
packaged. There's been past interest in going the /opposite/ direction
for Linux, since there's not standard support for fat
(multi-architecture) .so libraries. Moving the .so search path /down/
to an architecture-specific directory on Linux would allow the same
resource directory to be used for both host-compiling and
cross-compiling.
rdar://problem/43545560
We were checking the parent invocation's DiagnosticEnginer rather than the
subinstance's to determine if there were any errors building the module, which
meant we would fail to load the module if there were errors prior to the import
statement in the importing file.
This also meant code completion would fail to load the module, because it always
emits a bogus error in order to mark the AST as erroneous so that different
parts of the compiler (e.g. the verifier) have less strict assumptions.
rdar://problem/43906499
We were checking the parent invocation's DiagnosticEnginer rather than the
subinstance's to determine if there were any errors building the module, which
meant we would fail to load the module if there were errors prior to the import
statement in the importing file.
This also meant code completion would fail to load the module, because it always
emits a bogus error in order to mark the AST as erroneous so that different
parts of the compiler (e.g. the verifier) have less strict assumptions.
rdar://problem/43906499
Adds a test that errors reported in the inlinable function bodies of
.swiftinterface files are propagated correctly when generating the corresponding
.swiftmodule files.
rdar://problem/44400260
Adds a test to make sure that there's only one version of a dependent
module, regardless how many -swift-versions are present in the
dependency hierarchy.
These tests made sure that changing the hash, while keeping mtime constant, causes dependent modules to be rebuilt. Flip this around so changing the mtime, while keeping the hash constant, causes the same rebuilding behavior.
Otherwise, the top-level compilation gets the benefit of the prebuilt
cache path, but the sub-invocations for swiftinterfaces that /do/
need to be compiled do not.
The previous 'openModuleFiles' interface in SerializedModuleLoaderBase
still assumed that swiftmodule files and swiftdoc files would be found
next to each other, but that's not true anymore with
swiftinterfaces-built-to-modules. Give up on this assumption (and on
the minor optimization of passing down a scratch buffer) and split out
the interface into the customization point
'findModuleFilesInDirectory' and the implementation 'openModuleFiles'.
The latter now takes two full paths: one for the swiftmodule, one for
the swiftdoc.
Ensure that we explicitly provide the path to the interpreter when
running the python scripts during the tests. This is needed to have the
tests work on Windows which does not honour the shebang in the file. It
also ensures that we use the correct interpreter for the tests.
Deinitializers are always @objc. (Arguably, this makes it unnecessary
to print, but we don't want to do any @objc inference at all in a
swiftinterface.)
- Use the name for the cached module, so that we don't end up with a
zillion "x86_64-XXXXXXXX.swiftmodule" files in the cache when we're
working with architecture-specific swiftmodules.
- Diagnose if the expected name is different from the name specified
in the swiftinterface.
- Emit all diagnostics at the location of the import, instead of
without any location at all.
This would break resilience, which makes a distinction between "SIL
only inside the module, which is inside the resilience domain" and
"SIL we're going to serialize, which is outside the resilience
domain".
