The actual XCTest overlay has not been maintained in this repository for years. (It is distributed in Xcode (libXCTestSwiftSupport.dylib), along with XCTest.framework itself.)
The code we have here is badly out of date, and the fact that we have it on the module path in CI makes it interfere with the contents of recent SDKs.
Remove the XCTest overlay from this repository; pick it up from the SDK instead.
rdar://76915582
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.
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.
When a swiftinterface fails to build for any of various reasons, we try to diagnose the failure at the site of the `import` declaration. But if the import is implicitly added—which happens for many SDK modules, like the standard library and ClangImporter overlays—there is no source location for the import, so the error ends up being diagnosed at <unknown>:0. This causes a number of issues; most notably, Xcode doesn’t display the diagnostic as prominently as others.
This change falls back to diagnosing the error at line 1, column 1 of the swiftinterface file itself. This is perhaps not an ideal location, and it won’t help with I/O errors where we can’t open the swiftinterface file (and therefore can’t diagnose an error in it), but it should improve the way we display most module interface building errors.
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.
...specifically, diagnosed in the parent DiagnosticEngine. This not
only provides a better user experience, but makes sure that the
compiler exits with a nonzero exit code even if the module goes
unused.
rdar://problem/50789839
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
Previously we used a manual -emit-module command with a hardcoded set
of arguments, but that didn't work properly for all overlays. This is
much better.
A bunch of .swiftinterface files fail to build into their respective .swiftmodules
if you pass -module-name <foo> for some foo that is not the correct module name.
The two tests in this change were using a shell expansion that incorrectly picked
the first path component with a period in the name as the module name; this caused
the failures.
Rather than using a shell expansion, this change uses the 2-argument form of
basename(1) (which is POSIX) that also removes a suffix from the basename.
We already have something called "module interfaces" -- it's the
generated interface view that you can see in Xcode, the interface
that's meant for developers using a library. Of course, that's also a
textual format. To reduce confusion, rename the new module stability
feature to "parseable [module] interfaces".
