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`.
This means that we'll end up going int32 -> int64 -> float/double sometiems, but LLVM knows how to optimize away the intermediate conversion so we end up with just a normal 32b->float conversion as desired, and we get much, much better performance on oddball platforms like arm64_32.
The `_diagnoseUnavailableCodeReached()` function was introduced in the Swift
5.9 standard library and employs `@backDeployed` to support compilation of
binaries that target OS releases aligned with earlier Swift releases.
Unfortunately, though, this backdeployment strategy doesn't work well for some
unusual build environments. Specifically, in some configurations code may be
built with a compiler from a recent Swift toolchain and then linked against the
dylibs in an older toolchain. When linking against the older dylibs, the
`_diagnoseUnavailableCodeReached()` function does not exist but the
`@backDeployed` thunks emitted into the binary reference that function and
therefore linking fails.
The idea of building with one toolchain and then linking to the dylibs in a
different, older toolchain is extremely dubious. However, it exists and for now
we need to support it. This PR introduces an alternative
`_diagnoseUnavailableCodeReached()` function that is annotated with
`@_alwaysEmitIntoClient`. Calls to the AEIC variant are now emitted by the
compiler when the deployment target is before Swift 5.9.
Once these unusual build environments upgrade and start linking against a Swift
5.9 toolchain or later we can revert all of this.
Resolves rdar://119046537
The SIL printer is printing opaque parameters as <anonymous>, which
breaks the SIL parser. Stop using opaque parameters in the standard
library for the moment to unbreak SIL parsing of the standard library.
While `add_swift_target_library` has code to add a dependency from the
install component to the target, similar code was missing from
`add_swift_target_library_single`, probably because
`add_swift_target_library` calls `add_swift_target_library_single`, so
the extra dependency is not necessary.
However, there's usages of `add_swift_target_library_single` outside
`add_swift_target_library` which were creating targets that were not
dependencies of their install components. Some of those cases are the
embedded stdlib targets, which are installed as part of the `stdlib`
component.
It normally does not matter when using `build-script`, because those
targets are build as part of `all`, but it does matter if one is using
CMake/Ninja directly or in cases where `build-script` is not used.
Trying to use targets like `install-stdlib` will had missed building the
embedded stdlib, and failed the installation.
NFC.
We know maxLength must be positive and non-zero, and therefore, i += 1 will be the next index until we reach maxLength, in which case the result is 0. Rather than perform a modulo, which requires division, every time, we can just reset i when it reaches the end of the buffer.
which executor for which type of setting, is consolidated and we have a
single knob we use to determine when to use dispatch as our global
executor.
Radar-Id: rdar://problem/119416196
Static read-only arrays didn't work when passed to ObjectiveC as NSArray.
The storage class of static read-only arrays doesn't carry information about the Element type.
The new `__SwiftDeferredStaticNSArray` is generic over the element type and doesn't have to rely on the element type information of the array storage.
rdar://94185998
We can't use `malloc_type_aligned_alloc()` because `aligned_alloc()` requires
that `size` be a multiple of `alignment`, which isn't something we expect here.
rdar://119137861
So far the semantic annotation was just added to the internal `_getCount` function.
But for FixedArray it is also required to add the `@_semantics("array.get_count")` to the public API.
Swift has some module maps it overlays on Linux and Windows that groups all of the C standard library headers into a single module. This doesn’t allow clang and C++ headers to layer properly with the OS/SDK modules. clang will set -fbuiltin-headers-in-system-modules as necessary for Apple SDKs, but Swift will need to pass that flag itself when required by its module maps.
