Swift 5.7 added stronger index validation for `String`, so some illegal cases that previously triggered inconsistently diagnosed out of bounds accesses now result in reliable runtime errors. Similarly, attempts at applying an index originally vended by a UTF-8 string on a UTF-16 string now result in a reliable runtime error.
As is usually the case, new traps to the stdlib exposes code that contains previously undiagnosed / unreliably diagnosed coding issues.
Allow invalid code in binaries built with earlier versions of the stdlib to continue running with the 5.7 library by disabling some of the new traps based on the version of Swift the binary was built with.
In the case of an index encoding mismatch, allow transcoding of string storage regardless of the direction of the mismatch. (Previously we only allowed transcoding a UTF-8 string to UTF-16.)
rdar://93379333
Not all targets have a 16-byte type alignment guarantee. For the types
which are not naturally aligned, provide a type specific `operator new`
overload to ensure that we are properly aligning the type on allocation
as we run the risk of under-aligned allocations otherwise.
This should no longer be needed with C++17 and newer which do a two
phase `operator new` lookup preferring
`operator new(std::size, std::align_val_t)` if needed. The base type
would be fully pre-processed away. The empty base class optimization
should help ensure that we do not pay any extra size costs for the
alignment fixes.
As we are a C++14 codebase, we must locally implement some of the
standard type_traits utilities, namely `void_t`. We take the minimal
definition here, assuming that the compiler is up-to-date with C++14 DR
reports which fixed an issue in SFINAE. We use the SFINAE for detecting
the presence of the `operator new` overload to guide the over-alignment,
which is inherited through the new `swift::overaligned_type<>` base
type.
Annotate the known classes which request explicit alignment which is
non-pointer alignment. This list was identified by
`git grep ' alignas(.*) '`.
WebAssembly doesn't reserve low addresses but without "extra inhabitants" of
the pointer representation, runtime performance and memory footprint are
worse. So assume that compiler driver uses wasm-ld and --global-base=1024 to
reserve low 1KB.
Emit and resolve idValue of KeyPath as an absolute pointer if relative
function pointer is turned-off on Wasm target.
The existing ABI can't distinguish an idValue between function pointer
or data pointer in use-site at compile-time and also at runtime. So this
patch adds a new id resolution scheme `ResolvedAbsolute` to distinguish
them at runtime properly.
Starting with Android 11, AArch64 placed a tag in the top byte of pointers to
allocations, which has been slowly rolling out to more devices and collides
with Swift's tags. Moving these tags to the second byte works around this
problem.
Clean up the submodules in visualc to not export all imported modules.
The one special case is `vcruntime` which re-exports `SAL` due to a
dependency in the headers. The import of `visualc` however will
re-export all submodules to keep the current behaviour. This is
required to get the ARM64 SDK building on newer MSVC toolsets.
This adds a new reflection record type carrying spare bit information for multi-payload enums.
The compiler includes this for any type that might need it in order to accurately reflect the contents of the enum. The RemoteMirror library will use this if present to determine how to project the contents of the enum. If not present (for example, in older binaries), the RemoteMirror library falls back on an internal calculation of the spare bitmask.
A few notes:
* The internal calculation is not perfect. In particular, it does not support MPEs that contain other enums (e.g., optionals). It should accurately refuse to project any MPE that it does not correctly support.
* The new reflection field is designed to be expandable; this might someday avoid the need for a new section.
Resolves rdar://61158214
This migrates OpenBSD to use the single-header Glibc modulemap proposed
and implemented in #32404, and necessitates introducing some missing
headers for building Foundation added in #38341.
Additionally, incorporate nullability annotations in SwiftShims per
When building with a prebuilt Clang, the changes introduced in #40707
supposed that the toolchain was in its final path.
When building in stages (first the toolchain, then the standard
library), the toolchain might not be in the final path, and the created
symlink will point to a machine-local path that does not make sense.
The changes introduced should not modify the existing behaviour
introduced by #40707, but should allow customizing the final
installation target using the CMake cached variable for those setups
that need the flexibility.
This module used to be a private implementation detail of the Distpatch overlay on Apple platforms, and swift-corelibs-libdispatch elsewhere.
Darwin hasn't been using this module for a couple years now, and swift-corelibs-dispatch stopped using it with https://github.com/apple/swift-corelibs-libdispatch/pull/592. We are now free to remove it from the Swift toolchain -- which is good, as it contains declarations that are specific to Dispatch, and the compiler/stdlib is not the right place to maintain them.
This used to be a private implementation detail of the XCTest overlay.
This module has been unused since the Xcode 12.5 release, but we temporarily kept it in the toolchain in case a downloadable toolchain gets used with an older Xcode. (The module used to be imported by the XCTest overlay interface, so its removal would have made it tricky to import XCTest in that scenario.)
Including the 13.3 beta, there have now been seven Xcode releases since the last one that imported this module, and the compiler/stdlib repository no longer supports building with Xcode 12.4 or below. It seems reasonable to stop installing this module on the toolchain now.
rdar://80552912
Unfortunately using the convenient "bootstrapping0-all", etc. custom targets does not work.
For some reason it does not cause a dependent file (like libswift's SIL.o) being rebuilt when a depenency (like swift-frontend from the previous bootstrapping stage) changes.
Instead we have to list al library- and executable-targets explicitly.
* Generate Unicode data for Scalar Binary Properties
* Use native scalar binary property lookup
* Add _BinaryProperties to Scalar Properties
narrow access control
* Upgrade the notice to a warning in UnicodeScalarProperties
Windows objects to the multiple different aliases for
`swift_isStackAllocationSafe`. Use strong linkage on all non-ABI stable
targets. This should repair the Windows build and matches the
conditional emission in the stdlib.
Thanks to @lorentey for the discussion around how to handle this and the
pointer to where this was getting introduced!
