Correct the maximal floating point width. Although technically, Android
could support FP128 on AArch64, Swift does not currently support FP128.
For now, ensure that we use FP64 on Android.
Add `Differentiable.withDerivative(_:)`, a "derivative surgery" API.
`Differentiable.withDerivative(_:)` is an identity function returning `self`.
It takes a closure and applies it to the derivative of the return value, in
contexts where the return value is differentiated with respect to.
The non-C/C++ standard defined math constants require
`-Xcc -D_USE_MATH_DEFINES` when using the `ucrt` module. Instead,
provide them through the wrapper `MSVCRT` module as aliases so that the
user does not need to be aware of this in practice.
Repairs the Windows build of `_Differentiation`.
Outline the cold, non-contiguous UTF-8 path from String(decoding:as:),
saving ~40 bytes (33%) of code size (x86_64 and arm64) from every call
site where the contiguity check cannot be constant folded away.
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
JVP functions are forward-mode derivative functions. They take original
arguments and return original results and a differential function. Differential
functions take derivatives wrt arguments and return derivatives wrt results.
`JVPEmitter` is a cloner that emits JVP and differential functions at the same
time. In JVP functions, function applications are replaced with JVP function
applications. In differential functions, function applications are replaced
with differential function applications.
In JVP functions, each basic block takes a differential struct containing callee
differentials. These structs are consumed by differential functions.
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.
Commit for CMake and build scripts to recognize OpenBSD. To keep this
commit relatively short, this just deals with the rather simple and
uncontroversial changes to the build system.
Note that OpenBSD calls "x86_64" as "amd64", Since the Swift stdlib will
be put in a subdirectory named after ARCH, to ensure the standard
library is properly found later, we use the native architecture name for
OpenBSD in the build system rather than trying to deal with the
difference the other way around.
