If a base class initializer was not generic but had a contextual 'where'
clause, we would unconditionally inherit the 'where' clause in the override as
part of the fix for another issue (https://bugs.swift.org/browse/SR-14118).
However, it is possible that some of those requirements are satisfied by
the derived class itself. For example:
class Base<T> {
init() where T : AnyObject {}
}
class Derived : Base<AnyObject> {}
In this case, the implicit override Derived.init() has no generic requirements
at all. We used to assert because we would create a GSB with no generic
parameters.
It was also possible for a base class initializer to have generic
requirements that are not satisfied by the derived class. In this case,
we need to drop the initializer from consideration altogether.
While I'm here, I improved the comments in computeDesignatedInitOverrideSignature(),
which is the new name for configureGenericDesignatedInitOverride().
Fixes rdar://problem/77285618.
This check made this request depend on evaluation order, sometimes
synthesizing a second memberwise initializer if the previous one's
interface type had not been computed yet.
I found this by inspection. We did not mark the override as 'rethrows'
when the base designated initializer was 'rethrows'.
The FIXMEs in the test case are a separate issue, tracked by
https://bugs.swift.org/browse/SR-680.
The parser attempts to recover here by producing a broken VarDecl with
no parent pattern. The DeclChecker sees this when trying to install
a default initializer in the linked regression test and crashes because
it tries to look into a null parent pattern.
rdar://74154023
SE-0267 allows where clauses on declarations without their own generic
parameters, which means we can longer assume that if getGenericParams()
returns nullptr on a constructor, then the constructor has the same
generic signature as its parent class.
Instead, explicitly compare the superclass constructor's generic
signature with that of the superclass, and if they don't match,
compute a new generic signature for the override.
Fixes https://bugs.swift.org/browse/SR-14118 / rdar://73764827.
It is possible for ClassDecl::getSuperclassDecl() to succeed but for
ClassDecl::getSuperclass() to fail. This happens if the superclass is
a generic type and one of the generic arguments could not be resolved,
or does not satisfy the generic requirements, for example; in that
case, a BoundGenericType cannot be formed.
In a couple of places we were not prepared for this possibility.
Let's recover by making judicious use of ErrorType.
Fixes <rdar://problem/73169149>.
Rather than relying on clients to cope with the potential for circular
inheritance of superclass declarations, teach SuperclassDeclRequest to
establish whether circular inheritance has occurred and produce "null"
in such cases. This allows other clients to avoid having to think about
To benefit from this, have SuperclassTypeRequest evaluate
SuperclassDeclRequest first and, if null, produce a Type(). This
ensures that we don't get into an inconsistent situation where there
is a superclass type but no superclass declaration.
Allow the declaration of @objc async methods, mapping them to a
completion-handler API in Objective-C. This covers most of the
checking and semantics within the type checker:
* Declaring @objc async methods and checking their parameter/result types
* Determining the default Objective-C selector by adding
completionHandler/WithCompletionHandler as appropriate
* Determining the type of the completion handler parameter
* Inferring @objc from protocol requirements
* Inferring @objc from an overridden method
`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.
All callers can trivially be refactored to use ModuleDecl::lookupConformance()
instead. Since this was the last flag in ConformanceCheckOptions, we can remove
that, too.
Before attempting to get the superclass of a
self parameter type, check to see if we have a
metatype, and perform the necessary unwrapping and
re-wrapping if needed.
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.
A request is intended to be a pure function of its inputs. That function could, in theory, fail. In practice, there were basically no requests taking advantage of this ability - the few that were using it to explicitly detect cycles can just return reasonable defaults instead of forwarding the error on up the stack.
This is because cycles are checked by *the Evaluator*, and are unwound by the Evaluator.
Therefore, restore the idea that the evaluate functions are themselves pure, but keep the idea that *evaluation* of those requests may fail. This model enables the best of both worlds: we not only keep the evaluator flexible enough to handle future use cases like cancellation and diagnostic invalidation, but also request-based dependencies using the values computed at the evaluation points. These aforementioned use cases would use the llvm::Expected interface and the regular evaluation-point interface respectively.
Introduce evaluator::SideEffect, the type of a request that performs
some operation solely to execute its side effects. Thankfully, there are
precious few requests that need to use this type in practice, but it's
good to call them out explicitly so we can get around to making them
behave much more functionally in the future.
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.
If the 'wrappedValue:' parameter is an escaping autoclosure, and a
struct property is marked with that property wrapper, the memberwise
initializer of the struct is now synthesized with an escaping
autoclosure for that property.
Do a bit of cleanup here. Also expand the storage check to query the
backing variable for any attached property wrappers. If these are not
default-initialized or default initializable then the generated
initializer will contain unfixable DI errors.
Resolves rdar://58495602
We’re going to start serializing this for public types that have non-public-or-@usableFromInline initializers, so turn it into a request that we can query and cache it in the existing bit.
This commit adds a request that computes
the initializer context for a parameter with a
default expr or stored property default.
This avoids having to compute them for synthesized
decls and is a step towards requestifying default
argument parsing.
Codable's deep magic currently forces conformance checks in the middle
of name lookup in order to inject CodingKeys into lookup results. This
is compounded by the fact that this lookup fixup is occuring
incrementally, meaning depending on order of requirements being looked
up, Decl::getMembers() will give you a different answer.
Compounding this, NameLookup relied on the LazyResolver to formalize
this layering violation, and relied on implicit laziness to guard
against re-entrancy.
The approach is multi-pronged:
1) Shift the layering violation into the request evaluator
2) Spell out the kinds of resolution we support explicitly (make them
easier to find and kill)
3) Remove the LazyResolver entrypoint this was relying on
4) Split off the property wrappers part into its own utility
These include memberwise initializers for pointer properties and enum
case constructors for pointer payloads. In both cases, the pointer is
being immediately escaped, so don't allow the user to pass a temporary
pointer value.
