Introduce a new Actor protocol, which is a class-bound protocol with only
one requirement:
func enqueue(partialTask: PartialAsyncTask)
All actor classes implicitly conform to this protocol, and will synthesize
a (currently empty) definition of `enqueue(partialTask:)` unless a suitable
one is provided explicitly.
Sema can infer type witnesses for a small set of known conformances, to
RawRepresentable, CaseIterable, and Differentiable.
Previously, we would try to compute the type witness in this order:
1) First, via name lookup, to find an explicit nested type with the
same name as an associated type.
2) Second, we would attempt inference.
3) Third, we would attempt derivation.
Instead, let's do 3) before 2). This avoids circularity errors in
situations where the witness can be derived, but inference fails.
This breaks source compatibility with enum declarations where the raw
type in the inheritance clause is a lie, and the user defines their
own witnesses with mismatched types. However, I suspect this does not
come up in practice, because if you don't synthesize witnesses, there
is no way to access the actual raw literal values of the enum cases.
`Differentiable` conformance derivation now supports
`Differentiable.zeroTangentVectorInitializer`.
There are two potential cases:
1. Memberwise derivation: done when `TangentVector` can be initialized memberwise.
2. `{ TangentVector.zero }` derivation: done as a fallback.
`zeroTangentVectorInitializer` is a closure that produces a zero tangent vector,
capturing minimal necessary information from `self`.
It is an instance property, unlike the static property `AdditiveArithmetic.zero`,
and should be used by the differentiation transform for correctness.
Remove `Differentiable.zeroTangentVectorInitializer` dummy default implementation.
Update stdlib `Differentiable` conformances and tests.
Clean up DerivedConformanceDifferentiable.cpp cruft.
Resolves TF-1007.
Progress towards TF-1008: differentiation correctness for projection operations.
Add `AdditiveArithmetic` derived conformances for structs and classes, gated by
the `-enable-experimental-differentiable-programming` flag.
Structs and classes whose stored properties all conform to `Differentiable` can
derive `Differentiable`:
- `associatedtype TangentVector: Differentiable & AdditiveArithmetic`
- Member `TangentVector` structs are synthesized whose stored properties are
all `var` stored properties that conform to `Differentiable` and that are
not `@noDerivative`.
- `mutating func move(along: TangentVector)`
The `@noDerivative` attribute may be declared on stored properties to opt out of
inclusion in synthesized `TangentVector` structs.
Some stored properties cannot be used in `TangentVector` struct synthesis and
are implicitly marked as `@noDerivative`, with a warning:
- `let` stored properties.
- These cannot be updated by `mutating func move(along: TangentVector)`.
- Non-`Differentiable`-conforming stored properties.
`@noDerivative` also implies `@_semantics("autodiff.nonvarying")`, which is
relevant for differentiable activity analysis.
Add type-checking and SILGen tests.
Resolves TF-845.
Add `AdditiveArithmetic` derived conformances for structs, gated by the
`-enable-experimential-additive-arithmetic-derivation` flag.
Structs whose stored properties all conform to `AdditiveArithmetic` can derive
`AdditiveArithmetic`:
- `static var zero: Self`
- `static func +(lhs: Self, rhs: Self) -> Self`
- `static func -(lhs: Self, rhs: Self) -> Self`
- An "effective memberwise initializer":
- Either a synthesized memberwise initializer or a user-defined initializer
with the same type.
Effective memberwise initializers are used only by derived conformances for
`Self`-returning protocol requirements like `AdditiveArithmetic.+`, which
require memberwise initialization.
Resolves TF-844.
Unblocks TF-845: upstream `Differentiable` derived conformances.
The error recovery logic around derived conformances is a little bit
tricky. Make sure we don't crash if a type explicitly provides a
RawValue type witness that is not equatable, but omits the witnesses
for init(rawValue:) and the rawValue property.
Fixes <rdar://problem/58127114>.
Hashable doesn't quite have the know-how to reject invalid derivation contexts before hand. Give it a little help by adding a way to retrieve if a decl added to the conformance context was invalid after type checking completes. Otherwise we'll emit "Hashable is broken".
If a struct/enum cannot have Equatable/Hashable conformance automatically synthesized because a member's type is not Equatable/Hashable, add a note to the existing 'does not conform' diagnostic pointing out the type that blocked synthesis.
Use the usual bag of tricks to eliminating dependence on the
TypeChecker instance: static functions, LazyResolver callbacks, and
emitting diagnostics on decls/ASTContext.
This works for all protocols except for Decodable on non-final classes, because
the init requirement has to be 'required' and thus in the type's declaration.
Fixes most of https://bugs.swift.org/browse/SR-6803.
Instead of passing around a TypeChecker and three Decls (the nominal type, the
protocol, and the decl declaring the conformance) everywhere, we can just pass
one object.
This should be [NFC].
Implements the minimum specified by the SE-proposal.
* Add the CaseIterable protocol with AllCases associatedtype and
allCases requirement
* Automatic synthesis occurs for "simple" enums
- Caveat: Availability attributes suppress synthesis. This can be
lifted in the future
- Caveat: Conformance must be stated on the original type
declaration (just like synthesizing Equatable/Hashable)
- Caveat: Synthesis generates an [T]. A more efficient collection
- possibly even a lazy one - should be put here.
This has three principal advantages:
- It gives some additional type-safety when working
with known accessors.
- It makes it significantly easier to test whether a declaration
is an accessor and encourages the use of a common idiom.
- It saves a small amount of memory in both FuncDecl and its
serialized form.
The synthesized declarations should inherit the @_versioned attribute
from the type, just like they inherit access control.
Fixes <rdar://problem/34342955>.
* Allow CodingKey conformance to be automatically derived for enums
which have no raw type (with no associated values) and which have
a raw type of String or Int.
* Allow Encodable and Decodable conformance to be automatically derived
for classes and structs with Encodable/Decodable properties
* Add initial unit tests for verifying derived conformance
Rather than having Sema provide a default implementation of
Error._code when needed, introduce a runtime function to extract the
default code, so that we can provide a default implementation via a
protocol extension in the standard library.
When synthesizing the witness for Error._code, synthesize it as
final. This isn't meant to be user-visible (and, therefore, isn't
meant to be user-overridable), so it's a minor efficiency
win. Moreover, we weren't making sure this member got synthesized in
in cross-module situations, leading to runtime crashes. Fixes
rdar://problem/27335637.
