If SubstitutionMap is asked to form a substitution for a generic
parameter that has been made concrete by the generic signature,
substitute into the concrete type. This allows us to better deal with
non-canonical types.
The core substitution routine for the archetypes-to-interface types
substitution was attempting to provide mappings for nested archetypes,
when in fact these archetypes would (1) always be resolvable via their
parent, and (2) could in fact cause infinite recursion, as with the
new test case. Fixes SR-4617 / rdar://problem/31673819.
Reimplement isSelfDerivedSource() in terms of the new
visitPotentialArchetypesAlongPath(). Aside from being clearer and
shorter, this formulation eliminates some hackery (the direct
"NestedType" lookup) that was mostly masking a bug in
updateNestedTypeForConformance() where we created a
nested-type-name-match source with an incorrect source for the
purposes of concretizing the nested type.
Fixes SR-4458 / rdar://problem/31375569.
When an otherwise abstract conformance constraint is derived from a
concrete conformance, retain the abstract conformance by removing the
requirement source that involves the concrete conformance. This
eliminates our reliance on the concrete conformance, which is not
retained as part of the generic signature.
Fixes rdar://problem/31163470 and rdar://problem/31520386.
We want to validate both type in same-type or conformance constraints,
even when the first type is ill-formed, so we don't leave null types
around for later phases to crash on.
Fixes rdar://problem/31093854.
When substituting a type like T.A.B where A and B are
associated types and the conformance requirement on T.A
is implied by conformance requirements on T, we would
crash.
The problem is that we have no way of representing an
abstract conformance with nested concrete types.
This patch adds a workaround that we can live with until
ConformanceAccessPaths are plumbed through all the way.
Fixes <rdar://problem/30737546> and
<https://bugs.swift.org/browse/SR-3500>.
Possibly fixes <rdar://problem/31334245>.
While in the constraint system, the delegation is modeled as
returning an instance of the derived class, in the AST we type
the reference as returning an instance of the base class, and
insert a downcast, because in SILGen we're calling the base
class initializer which is typed as returning the base class.
This bit of fixup logic wasn't happening if the base class was
generic, and so we were not inserting the cast, which would
crash in SILGen with an assert.
Fixes <rdar://problem/31000248>.
This test was passing for the wrong reasons before. We need to
correctly model cases where a nested type of an abstract conformance is
in fact concrete and, therefore, has concrete conformances. XFAIL for now.
addImplicitConstructors() will crash if validateDecl() does not produce
a valid signature for one of the class's constructors because the
constructor is already being validated.
This was triggered during associated type inference in the test case
in the radar.
Fixes <rdar://problem/30751491>.
Apply the same is-generic check to initializers that we apply to
functions when establishing basic override compatibility. This is a
simple optimization for master, but fixes a crasher for Swift 3.1.
Fixes SR-4059.
If a nested type of a generic parameter was a typealias, and the
generic parameter was not at depth 0, index 0, we would resolve
the type down to the wrong PotentialArchetype, causing bogus
diagnostics and crashes.
Make sure we apply a substitution to the typealias's underlying
type before resolving it, to map it to the correct PotentialArchetype.
Note that the original test case in the radar works now, but the more
comprehensive test I added exposes an existing problem where generic
signature canonicalization is not idempotent. When this is fixed,
the RUN: line in the test can be changed from -typecheck to -emit-ir.
Fixes <rdar://problem/30248571>.
This addresses a crash where the compiler asks if an imported class
inherits initializers from its superclass /during the SIL passes/. In
this particular arrangement of subclasses and initializers (see test
case), this leads to us importing members of an Objective-C class for
the first time well after we've destroyed the type checker, and then
checking to see if an initializer added in a Swift extension can
prevent initializer inheritance. That initializer hasn't been
type-checked (because it's in another file and isn't supposed to
affect anything), and so the compiler chokes. A spot fix would merely
check for 'resolver' here and skip over the initializer if it doesn't
have a type, but it's not clear what the right semantics are in that
case.
The real issue here is that we don't support importing new declarations
after the type checker has been torn down, and that keeps causing us
problems, but that's a much bigger thing to fix.
https://bugs.swift.org/browse/SR-3853
We must order protocol typealiases *after* other types, so that
if a protocol typealias is equal to an associated type, the
representative is chosen to be the associated type and not the
typealias.
Fixes <https://bugs.swift.org/browse/SR-3687> and
<rdar://problem/30118513>.
Now that optional payloads can be re-abstracted, there's a case
where we need to do a tuple-to-tuple conversion on a direct result;
if the result is wrapped in an Optional. So I believe this assert
is not right.
Fixes <https://bugs.swift.org/browse/SR-3706>.
The PR added a Sema test with a minimal test case; add a bigger test
more closely resembling the original snippet and make sure it gets
all the way through IRGen.
Fixes assertion failures in SILGen and the optimizer with this
exotic setup:
protocol P {
associatedtype T : Q
}
protocol Q {
func requirement<U : P>(u: U) where U.T == Self
}
Here, we only have a U : P conformance, and not Self : Q,
because Self : Q is available as U.T : Q.
There were three problems here:
- The SIL verifier was too strict in verifying the generic signature.
All that matters is we can get the Self parameter conformance, not
that it's the first requirement, etc.
- GenericSignature::getSubstitutionMap() had a TODO concerning handling
of same-type constraints -- this is the first test-case I've found
that triggered the problem.
- GenericEnvironment::getSubstitutionMap() incorrectly ignored
same-type constraints where one of the two types was a generic
parameter.
Fixes <https://bugs.swift.org/browse/SR-3321>.
