The call to enumerateRequirements() here actually makes debugging
more difficult, since it has a lot of side effects, for example
calling maybeResolveEquivalenceClass() and removeSelfDerived().
Also, this is the only usage of enumerateRequirements() other than
collectRequirements(), which allows the two to be merged together
and simplified.
Consider the following program:
protocol P1 {
associatedtype A : P2
}
protocol P2 {
associatedtype A
}
func f<T>(_: T) where T : P2, T.A : P1, T.A.A == T {}
There are two proofs of T : P2:
- The explicit requirement in f()'s generic signature.
- Since T.A.A == T, we can also prove T : P2 via T.A.A : P2:
- First, we prove that T.A : P1 via the explicit requirement
in f()'s generic signature.
- Second, we prove that T.A.A : P1 via Self.A : P2 in P1's
requirement signature.
However, the second proof does not render the explicit requirement
T : P2 redundant, because it relies on the existence of the
nested type T.A, which only exists if T : P2.
This is captured in getMinimalConformanceSource(), which returns
nullptr for the requirement source corresponding to the second proof
above. It does this by looking at the root type of the requirement
source, T.A.
Now consider the analogous situation but with protocols -- let's
replace f() with a protocol P3:
protocol P3 : P2 where Self.A : P1, Self.A.A == Self {}
Here, we also have two proofs of Self : P2:
- The explicit requirement in P3's requirement signature.
- First, we prove that Self.A : P1 via the explicit requirement
in P3's requirement siganture.
- Second, we prove that Self.A.A : P1 via Self.A : P2 in P1's
requirement signature.
Once again, the second proof implicitly depends on the explicit
requirement, so we cannot use it to mark the explicit requirement
as redundant. However, since the requirement source root type here
is just 'Self', we were unable to recognize this, and we would
diagnose the requirement as redundant and drop it, resulting in
computing an invalid requirement signature for protocol P3.
To fix this, handle requirements at the top level of a protocol
requirement signature just like they are explicit requirements.
Fixes https://bugs.swift.org/browse/SR-13850 / rdar://problem/71377571.
A DependentMemberType can either have a bound AssociatedTypeDecl,
or it might be 'unresolved' and only store an identifier.
In maybeResolveEquivalenceClass(), we did not handle the unresolved
case when the base type of the DependentMemberType had itself been
resolved to a concrete type.
Fixes <rdar://problem/71162777>.
Compiler:
- Add `Forward` and `Reverse` to `DifferentiabilityKind`.
- Expand `DifferentiabilityMask` in `ExtInfo` to 3 bits so that it now holds all 4 cases of `DifferentiabilityKind`.
- Parse `@differentiable(reverse)` and `@differentiable(_forward)` declaration attributes and type attributes.
- Emit a warning for `@differentiable` without `reverse`.
- Emit an error for `@differentiable(_forward)`.
- Rename `@differentiable(linear)` to `@differentiable(_linear)`.
- Make `@differentiable(reverse)` type lowering go through today's `@differentiable` code path. We will specialize it to reverse-mode in a follow-up patch.
ABI:
- Add `Forward` and `Reverse` to `FunctionMetadataDifferentiabilityKind`.
- Extend `TargetFunctionTypeFlags` by 1 bit to store the highest bit of differentiability kind (linear). Note that there is a 2-bit gap in `DifferentiabilityMask` which is reserved for `AsyncMask` and `ConcurrentMask`; `AsyncMask` is ABI-stable so we cannot change that.
_Differentiation module:
- Replace all occurrences of `@differentiable` with `@differentiable(reverse)`.
- Delete `_transpose(of:)`.
Resolves rdar://69980056.
Instead of recomputing it on every call to getDependentType(),
we can just store it in there instead of the GenericParamKey
or AssociatedTypeDecl.
We still need to 're-sugar' user-visible dependent types to
get the right generic parameter name; a new getSugaredDependentType()
utility method is called in the right places for that.
A nested type of an archetype type might be concrete, for example, via a
same-type constraint:
extension SomeProtocol where SomeAssoc == Int {
... Self.SomeAssoc ...
}
This can happen in one of two ways; either the EquivalenceClass of the
nested type has a concrete type, or it is "fully concrete" because
there is no equivalence class and maybeResolveEquivalenceClass() returns
a ResolvedType storing the concrete type.
For some reason we didn't handle the second case here.
Fixes https://bugs.swift.org/browse/SR-13519 / rdar://problem/68531679
AbstractGenericSignatureRequest tries to minimize the number of GSBs that we
spin up by only creating a GSB if the generic parameter and requirement types
are canonical. If they're not canonical, it first canonicalizes them, then
kicks off a request to compute the canonical signature, and finally, re-applies
type sugar.
We would do this by building a mapping for re-sugaring generic parameters,
however this mapping was only populated for the newly-added generic parameters.
If some of the newly-added generic requirements mention the base signature's
generic parameters, they would remain canonicalized.
Fixes <rdar://problem/67579220>.
Previously we had two representations for the 'where' clause of a
parsed declaration; if the declaration had generic parameters of
its own, we would store them in the GenericParamList, otherwise
we would store them separately in a TrailingWhereClause instance.
Since the latter is more general and also used for protocols and
extensions, let's just use it for everything and simplify
GenericParamList in the process.
EquivalenceClass::getAnchor() always returns a canonical type and
the parent of a canonical type is itself be canonical.
This means that EquivalenceClass::getTypeInContext() can safely
assume that the parent type of a DependentMemberType maps to an
ArchetypeType in the GenericEnvironment.
Instead of trying to handle the case where the parent is concrete,
let's just crash by changing the conditional cast to an
unconditional one.
When passing in wantExactPotentialArchetype=false, we don't actually ever
call getDependentType() on the result. So the Type + EquivalenceClass form
of ResolvedType can be removed.
Under certain circumstances, introducing a concrete same-type or
superclass constraint can re-introduce conformance constraints
which were previously redundant.
For example, consider this code, which we correctly support today:
protocol P {
associatedtype T : Q
}
protocol Q {}
class SomeClass<U : Q> {}
struct Outer<T> where T : P {
func inner<U>(_: U) where T == SomeClass<U>, U : Q {}
}
The constraint 'T == SomeClass<U>' makes the outer constraint
`T : P' redundant, because SomeClass already conforms to P.
It also introduces an implied same-type constraint 'U == T.T'.
However, whereas 'T : P' together with 'U == T.T' make 'U : Q'
redundant, the introduction of the constraint 'T == SomeClass<U>'
removes 'T : P', so we re-introduce an explicit constraint 'U : Q'
in order to get a valid generic signature.
This code path did the right thing for constraints derived via
concrete same-type constraints, but it did not handle superclass
constraints.
As a result, this case was broken:
struct Outer<T> where T : P {
func inner<U>(_: U) where T : SomeClass<U>, U : Q {}
}
This is the same example as above, except T is related via a
superclass constraint to SomeClass<U>, instead of via a concrete
same-type constraint.
The subtlety here is that we must check if the superclass type
actually conforms to the requirement source's protocol, because it
is possible to have a superclass-constrained generic parameter
where some conformances are abstract. Eg, if SomeClass did not
conform to another protocol P2, we could write
func foo<T, U>(_: T, _: U) where T : SomeClass<U>, T : P2 {}
In this case, 'T : P2' is an abstract conformance on the type 'T'.
The common case where this would come up in real code is when you
have a class that conforms to a protocol with an associated type,
and one of the protocol requirements was fulfilled by a default in
a protocol extension, eg:
protocol P {
associatedtype T : Q
func foo()
}
extension P {
func foo() {}
}
class ConformsWithDefault<T : Q> : P {}
The above used to crash; now it will type-check correctly.
Fixes <rdar://problem/44736411>, <https://bugs.swift.org/browse/SR-8814>..
Name lookup might find an associated type whose protocol is not in our
conforms-to list, if we have a superclass constraint and the superclass
conforms to the associated type's protocol.
We used to return an unresolved type in this case, which would result in
the constraint getting delayed forever and dropped.
While playing wack-a-mole with regressing crashers, I had to do some
refactoring to get all the tests to pass. Unfortuanately these refactorings
don't lend themselves well to being peeled off into their own commits:
- maybeAddSameTypeRequirementForNestedType() was almost identical to
concretizeNestedTypeFromConcreteParent(), except for superclasses
instead of concrete same-type constraints. I merged them together.
- We used to drop same-type constraints where the subject type was an
ErrorType, because maybeResolveEquivalenceClass() would return an
unresolved type in this case.
This violated some invariants around nested types of ArchetypeTypes,
because now it was possible for a nested type of a concrete type to
be non-concrete, if the type witness in the conformance was missing
due to an error.
Fix this by removing the ErrorType hack, and adjusting a couple of
other places to handle ErrorTypes in order to avoid regressing with
invalid code.
Fixes <rdar://problem/45216921>, <https://bugs.swift.org/browse/SR-8945>,
<https://bugs.swift.org/browse/SR-12744>.
When adding a superclass constraint, we need to find any nested
types belonging to protocols that the superclass conforms to,
and introduce implicit same-type constraints between each nested
type and the corresponding type witness in the superclass's
conformance to that protocol.
Fixes <rdar://problem/39481178>, <https://bugs.swift.org/browse/SR-11232>.
This simplifies fixing the master-next build. Upstream LLVM already
has a copy of this function, so on master-next we only need to delete
the Swift copy, reducing the potential for merge conflicts.
Add type checking for `@differentiable` function types:
- Check that parameters and results conform to `Differentiable`.
- Implicitly conform parameters and results whose types are generic parameters
to `Differentiable`.
- Upstream most of the differentiable_func_type_type_checking.swift test from
`tensorflow` branch. A few function conversion tests have not been added
because they depend on the `@differentiable` function conversion pipeline.
Diagnose gracefully when the `Differentiable` protocol is unavailable because
`_Differentiation` has not been imported.
Resolves TF-823 and TF-1219.
