In Xcode 16 SDKs there seem to be two `errno` visible for some files,
one in the `Darwin` module, and one in the `_errno` module (which seems
new for this Xcode version).
Disambiguate the references by prepending `Darwin`, which should be the
one that was being used before Xcode 16 SDKs.
Everywhere there's a `SWIFT_MODULE_DEPENDS_LINUX Glibc`, there should be
a corresponding `SWIFT_MODULE_DEPENDS_LINUX_STATIC Musl`.
This usually won't bite us, depending on build order and parallelism, but
I hit one of these yesterday so went looking to see if there were any
others.
rdar://136208589
The Apple SDKs have been providing the Darwin overlay since macOS 10.14.4, iOS 12.2, et al. More recently the SDK version has diverged from the Swift version making them incompatible. Stop building the overlay from Swift. Once the SDK overlays aren't being built, the clang overlays need to be built in testing.
rdar://115192929
The Apple SDKs have been providing the Darwin overlay since macOS 10.14.4, iOS 12.2, et al. More recently the SDK version has diverged from the Swift version making them incompatible. Stop building the overlay from Swift. Once the SDK overlays aren't being built, the clang overlays need to be built in testing.
%target-swift-emit-pcm doesn't use the sdk, but %target-swift-frontend does, which will cause them to have a mismatch with "builtin headers belong to system modules, and _Builtin_ modules are ignored for cstdlib headers" aka LANGOPT(BuiltinHeadersInSystemModules) aka -fbuiltin-headers-in-system-modules.
rdar://115192929
Mostly this just means adding `Musl` as a module dependency of various
things and making sure that we build things for `swift_static` even
if `SWIFT_BUILD_STATIC_STDLIB` isn't enabled.
There's also a slight difference in the declaration of `memcmp()`;
musl's declaration is more like the one we have on Darwin.
rdar://123508245
This change introduces a new compilation target platform to the Swift compiler - visionOS.
- Changes to the compiler build infrastrucuture to support building compiler-adjacent artifacts and test suites for the new target.
- Addition of the new platform kind definition.
- Support for the new platform in language constructs such as compile-time availability annotations or runtime OS version queries.
- Utilities to read out Darwin platform SDK info containing platform mapping data.
- Utilities to support re-mapping availability annotations from iOS to visionOS (e.g. 'updateIntroducedPlatformForFallback', 'updateDeprecatedPlatformForFallback', 'updateObsoletedPlatformForFallback').
- Additional tests exercising platform-specific availability handling and availability re-mapping fallback code-path.
- Changes to existing test suite to accomodate the new platform.
NDK 26 renamed the directory in which it places the Android compiler-rt from
`lib64/`, and added a bunch of nullability annotations to the Bionic libc.
For some reason, 4 years ago, in ea90256 I added this target to `dev`,
which does not make sense because these stubs are only intended for
testing. Make them `never_install` to avoid distributing them when doing
`install-dev`.
Build SwiftReflectionTest only if swift-reflection-test is available
because it depends on the tool and the tool is not available when no
dynamic stdlib is built
This patch goes through and adds zippering and the swift module
dependencies to a bunch of pieces of the swift runtimes. Here's to
hoping I hit everything that needed to be hit. :D
With this patch, I'm seeing the appropriate modules under
lib/swift/maccatalyst, so things seem to be working right.
These two modules themselves depend on modules that implicitly import the _StringProcessing library. Take OSLog as an example, which imports ObjectiveC, which implicitly imports _StringProcessing. Thus, we can get into the following bad scenario:
- A compiler at module format X builds _StringProcessing
- A rebase is performed and the compiler is rebuilt at module format Y > X
- OSLog builds before _StringProcessing (since it has no dependency)
- But _StringProcessing is at module format X < Y, so we have to rebuild it
This normally manifests as an error at the desks of compiler engineers about a mismatch in the module format for _StringProcessing. Let's fix that by making CMake schedule _StringProcessing before them.
