This cleans up some more `llvm::` leakage in the runtime when built into
a static library. With this change we are down to 3 leaking symbols in
the static library related to a missed ADT (`StringSwitch`).
Rather than build multiple copies of LLVMSupport (4x!) build it one and
merge it into the various targets. This would ideally not be needed to
be named explicitly everywhere, but that requires using `add_library`
rather than `add_swift_target_library`.
This removes the last reference to the `llvm::` namespace in the
standard library. All uses of the LLVMSupport library now are
namespaced into the `__swift::__runtime` namespace. This allows us to
incrementally vend the LLVMSupport library and make the separation
explicit.
Rather than invoke a bash script to generate the file, write the file
statically from CMake. This allows us to cross-compile for platforms
which require the static library arguments on platforms which do not
have bash.
Reduce LLVMSupport to the subset required for the runtime. This reduces
the TCB and the overheads of the runtime. The inline namespace's
preservation ensures that ODR violations do not occur.
This adds a new copy of LLVMSupport into the runtime. This is the final
step before changing the inline namespace for the runtime support. This
will allow us to avoid the ODR violations from the header definitions of
LLVMSupport.
LLVMSupport forked at: 22492eead218ec91d349c8c50439880fbeacf2b7
Changes made to LLVMSupport from that revision:
process.inc forward declares `_beginthreadex` due to compilation issues due to custom flag handling
API changes required that we alter the `Deallocate` routine to account
for the alignment.
This is a temporary state, meant to simplify the process. We do not use
the entire LLVMSupport library and there is no value in keeping the
entire library. Subsequent commits will prune the library to the needs
for the runtime.
There are a set of headers shared between the Swift compiler and the
runtime. Ensure that we explicitly use `llvm::ArrayRef` rather than
`ArrayRef` which is aliased to `::llvm::ArrayRef`. Doing so enables us
to replace the `ArrayRef` with an inline namespaced version fixing ODR
violations when the swift runtime is loaded into an address space with
LLVM.
Rather than using the forward declaration for the LLVMSupport types,
expect to be able to use the full declaration. Because these are
references in the implementation, there is no reason to use a forward
declaration as the full types need to be declared for use. The LLVM
headers will provide the declaration and definition for the types. This
is motivated by the desire to ensure that the LLVMSupport symbols are
properly namespaced to avoid ODR violations in the runtime.
This reduces the dependency on `LLVMSupport`. This is the first step
towards helping move towards a local fork of the LLVM ADT to ensure that
static linking of the Swift runtime and core library does not result in
ODR violations.
This removes the LLVMSupport usage for thread local. This effectively
is a no-op as the runtime requires that it is built with clang, which
provides the C++11 `thread_local` support on all the targets. In the
case that the target does not support `thread_local`, clang would
fallback to `__declspec(thread)` on MSVC and `__thread` on other modes.
However, because the runtime is always built in C++14 mode, the
`thread_local` support should be assumed to be present. Remove the
unnecessary condition and inline the single use of the macro for
`thread_local`.
This replaces `LLVM_LIBRARY_VISIBILITY` with `SWIFT_LIBRARY_VISIBILTIY`
througout the runtime. The purpose of this attribution is unclear -
building with `-fvisibility=hidden` would accomplish this. This is an
entirely mechanical change replacing the macro with the Swift namespaced
variant instead.
This replaces the `LLVM_ATTRIBUTE_ALWAYS_INLINE` with `SWIFT_INLINE`
which is equivalent but namespaced to Swift instead. This reduces the
unnecessary reliance on LLVMSupport.
This moves the standard library response file into the standard library
generation rather than in the driver. Although the driver consumes this
file, it is part of the standard library as it knows its dependencies.
This removes the last of the ICU references in the toolchain.
To facilitate debugging metadata records which are not properly
initialized, upon allocation fill them with a regular byte pattern
(0xAA) so that on subsequent inspection it is obvious if part of the
record is not initialized.
This was identified by UBSAN: signed-integer-overflow. Explicitly mark
the value as unsigned to ensure that the value does not overflow. There
is a second instance of a raw literal, however, because it is a `*=` the
value is implicitly understood to be unsigned.
Extend SwiftDtoa to provide optimal formatting for Float16 and use that for `Float16.description` and `Float16.debugDescription`.
Notes on signaling NaNs: LLVM's Float16 support passes Float16s on x86
by legalizing to Float32. This works well for most purposes but incidentally
loses the signaling marker from any NaN (because it's a conversion as far
as the hardware is concerned), with a side effect that the print code never
actually sees a true sNaN. This is similar to what happens with Float and
Double on i386 backends. The earlier code here tried to detect sNaN in a
different way, but that approach isn't guaranteed to work so we decided to
make this code use the correct detection logic -- sNaN printing will just be
broken until we can get a better argument passing convention.
Resolves rdar://61414101
Android NDK <r21 does not provide the AEABI mandated `__aeabi_d2h`
functions in the compiler runtime. Add shims to ensure that the
functions are available for building the standard library.
When constructing the metadata for a type Gen<T : Super>
where Super is a superclass constraint, the generic argument K at which
the metadata for Gen is being instantiated is verified to be a subclass
of Super via _checkGenericRequirements.
Previously, that check was done using swift_dynamicCastMetatype. That
worked for the most part but provided an incorrect answer if the
metadata for K was not yet complete. These classes are incomplete more
often thanks to __swift_instantiateConcreteTypeFromMangledNameAbstract.
That issue occurred concretely in the following case:
Framework with Library Evolution enabled:
open class Super { ... }
public struct Gen<T : Super> {
}
Target in a different resilience domain from that framework:
class Sub : Super {
var gen: Gen<Sub>?
}
Here, the mechanism for checking whether the generic argument K at which
the metadata for Gen is being instantiated handles the case where K's
metadata is incomplete. At worst, every superclass name from super(K)
up to Super are demangled to instantiate metadata. A number of faster
paths are included as well.
rdar://problem/60790020
In preparation for the prespecialization of metadata for generic
classes, make checkMetadataState always return that the state of
prespecialized class metadata is complete, as is done for generic
structs and enums already.
It's possible to get multiple threads reading from the same enum at the same time, and the result can be bad data extracted or even permanent corruption of the value in memory. Instead, copy the enum value, then project the data from the copy.
rdar://problem/59493486
