This makes sure that the compiler does not emit `-enable-experimental-cxx-interop`/`-cxx-interoperability-mode` flags in `.swiftinterface` files. Those flags were breaking explicit module builds. The module can still be rebuilt from its textual interface if C++ interop was enabled in the current compilation.
rdar://140203932
This assert was correctly catching the fact that `-target-variant` is not being
normalized at the same time as `-target` when building arm64e modules from
swiftinterface. That should be fixed, but at the moment it isn't causing any
concrete harm and the assertion fails when building against the SDKs included
with the latest Xcode 16 betas.
Resolves rdar://133020098.
Some editors use diagnostics from SourceKit to replace build issues. This causes issues if the diagnostics from SourceKit are formatted differently than the build issues. Make sure they are rendered the same way, removing most uses of `DiagnosticsEditorMode`.
To do so, always emit the `add stubs for conformance` note (which previously was only emitted in editor mode) and remove all `; add <something>` suffixes from notes that state which requirements are missing.
rdar://129283608
Checking for the presence of a feature flag in order to allow syntax tends to
result in condfails when applied to `.swiftinterfaces`, since older compilers
that have this restriction may be used to compile newer interfaces where the
restriction has been lifted. Remove this restriction for non-escapable types
when typechecking an interface.
Resolves rdar://128577611
These tests are using FileCheck to check the result of diagnostic
formatting in ways that don't match the new formatter. Force the old
formatter or, where possible, generalize so that they match both
formatters.
This was originally attempted with https://github.com/apple/swift/pull/58810
but `_RegexParser` still ended up being built with library evolution enabled
because the `-enable-library-evolution` flag is added to the command line after
calling `add_swift_target_library` and therefore stripping the flag out of
`SWIFT_COMPILE_FLAGS` does nothing.
The `IS_FRAGILE` flag was introduced to support building C++ interop overlay
modules without library evolution and it can now be used to prevent
`_RegexParser` from being built with library evolution.
Resolves rdar://93067204
This commit changes fixit messages from a question/suggestion to an
imperative message for protocol conformances and switch-case. Addresses
https://github.com/apple/swift/issues/67510.
We can't assume that we will always find a viable witness for a protocol
requirement when typechecking a `.swiftinterface` file. The assert that assumed
there would be a match could fail when building a broken interface or building
a valid interface with a broken SDK, causing crashes instead of emitting
diagnostics.
Resolves rdar://108688535
The `@MainActor` global actor constraint on a declaration does not carry an
inherent ABI impact and therefore use of this constraint should not be limited
to OS versions where Swift concurrency is available.
Resolves rdar://105610970
This change adds basic helper protocols and structs that are going to be used for making C++ sequences and collection safe and Swifty by adding conformances to `Swift.Sequence`, `Swift.Collection`, etc.
This is not meant to be a final design.
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.
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".
