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.
The differentiation transform does the following:
- Canonicalizes differentiability witnesses by filling in missing derivative
function entries.
- Canonicalizes `differentiable_function` instructions by filling in missing
derivative function operands.
- If necessary, performs automatic differentiation: generating derivative
functions for original functions.
- When encountering non-differentiability code, produces a diagnostic and
errors out.
Partially resolves TF-1211: add the main canonicalization loop.
To incrementally stage changes, derivative functions are currently created
with empty bodies that fatal error with a nice message.
Derivative emitters will be upstreamed separately.
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
Add concrete overloads for ~= for String/Substring
combinations. SR-12457 tracks making this generic after we understand
the expression type checker impact.
Previously, two conditions were necessary to enable differentiable programming:
- Using the `-enable-experimental-differentiable-programming` frontend flag.
- Importing the `_Differentiation` module.
Importing the `_Differentiation` module is the true condition because it
contains the required compiler-known `Differentiable` protocol. The frontend
flag is redundant and cumbersome.
Now, the frontend flag is removed.
Importing `_Differentiation` is the only condition.
This code rearchitects and simplifies the projectEnumValue support by
introducing a new `TypeInfo` subclass for each kind of enum, including trivial,
no-payload, single-payload, and three different classes for multi-payload enums:
* "UnsupportedEnum" that we don't understand. This returns "don't know" answers for all requests in cases where the runtime lacks enough information to accurately handle a particular enum.
* MP Enums that only use a separate tag value. This includes generic enums and other dynamic layouts, as well as enums whose payloads have no spare bits.
* MP Enums that use spare bits, possibly in addition to a separate tag. This logic can only be used, of course, if we can in fact compute a spare bit mask that agrees with the compiler.
The final challenge is to choose one of the above three handlings for every MPE. Currently, we do not have an accurate source of information for the spare bit mask, so we never choose the third option above. We use the second option for dynamic MPE layouts (including generics) and the first for everything else.
TODO: Once we can arrange for the compiler to expose spare bit mask data, we'll be able to use that to drive more MPE cases.
* Add all [differential operators](https://github.com/apple/swift/blob/master/docs/DifferentiableProgramming.md#list-of-differential-operators).
* Add `withoutDerivative(at:)`, used for efficiently stopping the derivative propagation at a value and causing the derivative at the value to be zero.
* Add utility `differentiableFunction(from:)`, used for creating a `@differentiable` function from an original function and a derivative function.
Mostly work done by @marcrasi and @dan-zheng.
Partially resolves TF-843.
TODO:
* Add `AnyDerivative`.
* Add `Array.differentiableMap(_:)` and `differentiableReduce(_:_:)`.
module to contain only code necessary for testing the compiler
optimizations and diagnostics. This commit comprises the following changes:
1. Rename the OSLogPrototype module to OSLogTestHelper and rename the files.
2. Make the private module: OSLogTestHelper independent of os overlay.
3. Simplify the os log test suites and make them not perform logging.
4. Enable the os log test suites on all platforms.
<rdar://problem/60542172>
I've verified that all of the header files in this module already
contain their own `extern "C"` blocks that are activated if compiling as
C++.
The additional [extern_c] attribute causes problems for some headers,
like PathCch.h, that define additional overloads of functions when
compiled as C++. The "global" [extern_c] essentially switches off name
mangling with these overloads, which causes them to conflict with the
functions they are overloading.
See here for more context:
https://github.com/apple/swift/pull/30233#issuecomment-601594221
See here for an example of failures caused by the [extern_c]:
https://ci-external.swift.org/job/swift-PR-windows/869/console
(Search for "PathCch.h".)
Round up our malloc requests and assert that breadcrumbs are aligned
and where we think they should be. This is necessary because ASAN
doesn't give us pointer-rounded sizes.
* First part of multi-payload enum support
This handles multi-payload enums with fixed
layouts that don't use spare payload bits.
It includes XI calculations that allow us to
handle single-payload enums where the payload
ultimately includes a multi-payload enum
(For example, on 32-bit platforms, String uses
a multi-payload enum, so this now supports single-payload
enums carrying Strings.)
