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!
Don't build the swiftCore module files in the bootstrapping phases. Instead use the module files in the SDK.
This reduces the build time overhead from 3min -> 30seconds.
* Implement GraphemeWalker that does native grapheme breaking
* Bridged strings use native grapheme breaking for forward strides
* Implement bidirectional native grapheme breaking for native and foreign strings
* Remove ICU's grapheme breaking support
* Use UnicodeScalarView to implement GraphemeWalker
use an Iterator approach
remove Iterator conformance
* Incorporate Michael's feedback
more comments addressed
fix crlf bug
* Try bringing back some old fast paths
* Parameterize nextBoundary and previousBoundary
Parameterize nextBoundary and previousBoundary
* Implement Michael's suggestions
Adds two new IRGen-level builtins (one for allocating, the other for deallocating), a stdlib shim function for enhanced stack-promotion heuristics, and the proposed public stdlib functions.
This is for the 'freestanding' build to stop assuming the platform has argc/argv.
- Introduce a new sub-library, libswiftCommandLineSupport.a
- Move stubs/CommandLine.cpp into this library
- Conditionally embed it into libswiftCore
- Conditionally embed it into libswiftPrivateLibcExtras if not in libswiftCore to support testing
- Add SWIFT_STDLIB_HAS_COMMANDLINE CMake (and build-script) flag
Fixes a couple of compiler warnings that occur frequently when building the compiler:
- Copy the nullability annotation definitions from `Visibility.h` to `BridgedSwiftObject.h` and wrap all code that contains nullability annotations in `SWIFT_BEGIN_NULLABILITY_ANNOTATIONS` and `SWIFT_END_NULLABILITY_ANNOTATIONS` (supressing the warning `type nullability specifier '_Nullable' is a Clang extension [-Wnullability-extension]`)
- Suppress warnings about using `$` (mangling prefix) as an identifier using pragmas (supressing the warning `'$' in identifier [-Wdollar-in-identifier-extension]`)
- Change the macro condition of `SWIFT_NODISCARD` from `__cplusplus >= 201402l` (which checked for >= C++14) to `__cplusplus > 201402l`. This appears to have been a copy-paste error from `LLVM_NODISCARD` (supressing the warning `use of the 'nodiscard' attribute is a C++17 extension [-Wc++17-extensions]`)
