This dynamic library contains a copy of the standard library's
exported entry points for the Span and RawSpan types. This will
allow backward deployment of code that uses those new types.
We need to make sure that we add the compatibility libraries as
dependencies for target executables, otherwise we can end up with
a race condition in the build where the build will fail if the
compatibility libraries haven't been built by the time e.g.
`swift-backtrace` is linked.
rdar://128197532
check_cxx_compiler_flag caches its results for the same variable, since
all the flags were using the same variable, only the first check was
done, and the rest of the flags were just using the result of the first
flag.
Make each of the check_cxx_compiler_flag use a different variable (by
interpolating the flag name) and reorder the list of compiler flags to
check. -Wall was added twice, and in the case of MSVC, the equivalent
was added last.
It doesn't really seem to affect a lot of things.
This is set to hidden in `stdlib/CMakeLists.txt`, but in some Apple
internal configurations we build the compatibility archives by directly
importing `stdlib/toolchain`, thus skipping these directives and
causing some symbols to become unexpected visible.
Addresses rdar://73709695
This directory is directly added from the top-level CMake which bypasses
the compiler swapping dance. When cross-compiling or building the
toolchain with a non-clang compiler, the forced flags for the standard
library directory will result in build failures. Avoid building the
library unless the standard library is being built (which will require
that the compiler-swap occurs).
* Introduce TypeLayout Strings
Layout strings encode the structure of a type into a byte string that can be
interpreted by a runtime function to achieve a destroy or copy. Rather than
generating ir for a destroy/assignWithCopy/etc, we instead generate a layout
string which encodes enough information for a called runtime function to
perform the operation for us. Value witness functions tend to be quite large,
so this allows us to replace them with a single call instead. This gives us the
option of making a codesize/runtime cost trade off.
* Added Attribute @_GenerateLayoutBytecode
This marks a type definition that should use generic bytecode based
value witnesses rather than generating the standard suite of
value witness functions. This should reduce the codesize of the binary
for a runtime interpretation of the bytecode cost.
* Statically link in implementation
Summary:
This creates a library to store the runtime functions in to deploy to
runtimes that do not implement bytecode layouts. Right now, that is
everything. Once these are added to the runtime itself, it can be used
to deploy to old runtimes.
* Implement Destroy at Runtime Using LayoutStrings
If GenerateLayoutBytecode is enabled, Create a layout string and use it
to call swift_generic_destroy
* Add Resilient type and Archetype Support for BytecodeLayouts
Add Resilient type and Archetype Support to Bytecode Layouts
* Implement Bytecode assign/init with copy/take
Implements swift_generic_initialize and swift_generic_assign to allow copying
types using bytecode based witnesses.
* Add EnumTag Support
* Add IRGen Bytecode Layouts Test
Added a test to ensure layouts are correct and getting generated
* Implement BytecodeLayouts ObjC retain/release
* Fix for Non static alignments in aligned groups
* Disable MultiEnums
MultiEnums currently have some correctness issues with non fixed multienum
types. Disabling them for now then going to attempt a correct implementation in
a follow up patch
* Fixes after merge
* More fixes
* Possible fix for native unowned
* Use TypeInfoeBasedTypeLayoutEntry for all scalars when ForceStructTypeLayouts is disabled
* Remove @_GenerateBytecodeLayout attribute
* Fix typelayout_based_value_witness.swift
Co-authored-by: Gwen Mittertreiner <gwenm@fb.com>
Co-authored-by: Gwen Mittertreiner <gwen.mittertreiner@gmail.com>
Refactor the logic so to have a single target to reference the
compatibility libraries for the host, and use that when needed.
The main driver for this change is supporting the cross-compilation of
x86-64 on Apple Silicon.
Supports rdar://90307965
This patch gets everything to the point of building the library, but it
doesn't run yet since I have missing symbols.
Unlike previous compatibility libraries and the concurrency
compatibility library, I'm organizing the headers a bit more. This is
because we're merging the two libraries into one. They share some common
header names, and while I could rename them for namespacing purposes,
it's easier to just use a directory structure for this.
The `include/Runtime` and corresponding `Runtime/` directories are for
backdeployed changes to the stdlib itself.
The `include/Concurrency` and corresponding `Concurrency/` directories
are for backdeployed changes to the concurrency runtimes.
Moved the compatibility deployment targets to the top level CMakeLists.
Without this, if we build without SWIFT_BUILD_STDLIB set, the threading
library doesn't see the correct values. This didn't affect local builds
when testing the original fix, but it does affect B&I.
rdar://96690200
In #40610 some options were moved into `StdlibOptions.cmake`, but that
file is only included from `stdlib/CMakeLists.txt` and
`cmake/modules/StandaloneOverlay.cmake`. However, if one does not build
neither the dynamic nor the static standard library, but enables
building the "toolchain extras" with
`SWIFT_BUILD_STDLIB_EXTRA_TOOLCHAIN_CONTENT` `stdlib/CMakeLists.txt`
will not be included, but `stdlib/toolchain/CMakeLists.txt` will, which
uses a value from `StandardOverlay.cmake` that will not be provided the
correct default value and will skip building most of what
`SWIFT_BUILD_STDLIB_EXTRA_TOOLCHAIN_CONTENT` used to do.
In a back deployment scenario, this will provide a place where one could provide
function implementations that are not available in the relevant stdlib.
This is just setting up for future work and isn't doing anything interesting
beyond wiring it up/making sure that it is wired up correctly with tests.
In a back deployment scenario, this will provide a place where one could provide
function implementations that are not available in the relevant stdlib.
This is just setting up for future work and isn't doing anything interesting
beyond wiring it up/making sure that it is wired up correctly with tests.
Remove the flag being specified in multiple locations unnecessarily.
The flags flow downwards to all the subdirectories. Use that to apply
the C/C++ flags from the root of the runtime repository.
This is needed in situations where the minimum deployment target is
specified in build-script -- these libraries do not to obey to that
since we need to ensure we are able to back deploy those correctly.
Addresses rdar://59249988
The runtime that shipped with Swift 5.1 and earlier had a bug that interfered with backward
deployment of binaries that dynamically check for protocol conformances on conditionally-available
tests. This was fixed in the top-of-tree Swift runtime by https://github.com/apple/swift/pull/29887;
however, that doesn't do much good for running binaries on older OSes that don't have that fix.
In order for binaries built with a newer Swift compiler to run successfully on older OSes,
introduce a compatibility hook that replaces the conformance cache implementation in the original
OS runtime with a version based on the current implementation that has the fix for the protocol
conformance bug. Fixes rdar://problem/59460603
When building on macOS without the standard library but building the
extra toolchain content, we would fail to configure due to the missing
include of the `AddSwiftStdlib`.
