when building for Apple platforms.
In this scenario we are not building our own Foundation,
but we are importing the one from the underlying SDK -- this in turns
requires Observation, which is something we typically build.
Addresses rdar://162286123
OpenBSD 7.8 snapshots hide the type information for FILE. Therefore, the
types for the standard stdio streams should (regrettably) be
OpaquePointer, due to the well-discussed issue of losing type
information for forward-declared C types.
We explicitly drop to void * in the LibcOverlayShims for backwards
compatibility, since OpenBSD 7.8 is not yet released.
This reverts commit 4a95275bde.
I remove the dependency looking at the modules that StdlibUnittest
directly imports -- but it turns out we import StringProcessing
indirectly as a result of importing Foundation from e.g. the underlying
Apple SDKs.
Addresses rdar://158797152
Since #64187 we are not importing automatically StringProcessing when
building the stdlib -- this is especially important for StdlibUnittest,
since it needs to run on older OSes.
Addresses rdar://157622116
The SDK overlays have been provided in the Apple SDKs for many years, and the interface and implementation has diverged in more recent years such that trying to build the Swift version no longer works. Remove all of the dead code.
rdar://151889154
... that would import that as a result of importing Darwin from the SDK.
Amend my previous change to Differentiation and Distributed in this
sense.
Addresses rdar://150400049
Iterating child tasks depends on knowing the size of AsyncTask, and changing the size of the task broke it. Instead of relying on mirroring the full structure in our out-of-process definitions, add a debug variable to libswift_Concurrency that contains the size of AsyncTask.
While we're there, add some more validation to child task enumeration. Check each child task's metadata pointer to make sure that it actually points to the AsyncTask metadata, and have the inner loop also increment and check ChildTaskLoopCount to stop runaway iteration in that loop.
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
