When an archetype conforms to a protocol abstractly (ie, it is
not class-constrained and we don't have any further information
other than that it conforms), we can recover nested types,
but we cannot recover the conformance of those nested types
to protocols if those conformances are concrete (the nested
type might be concrete, or it might be a class-constrained
archetype).
To work around this, we added a hack where if the conformance
lookup in the SubstitutionMap fails, we fall back to the module.
This is horrible and unprincipled, but has to remain in place
until more infrastructure is plumbed through.
Commit 620db5f74c made this
workaround apply in fewer cases, so that we could still catch
cases where the SubstitutionMap was constructed with missing
conformances.
Unfortunately this workaround didn't handle the case where the
nested type was an archetype with a superclass constraint.
This will all go away soon, but for now tweak the logic a bit,
since I really want to keep the "narrow" workaround in place
and not the general fallback, otherwise we run the risk of
SubstitutionMap conformance lookup bitrotting completely.
Fixes <https://bugs.swift.org/browse/SR-4088> and
<rdar://problem/32773028>.
Rather than performing typo correction at the very end of finalize(),
do it as part of delayed requirement handling when we cannot otherwise
make progress. This is a cleaner way to cope with typo correction that
gives us a better chance of getting to a sane result.
Fixes rdar://problem/31048352 by eliminating the need for tracking the
number of unresolved potential archetypes altogether. Fixes
rdar://problem/32077627.
Validation for typealiases in protocols is... odd. It needs to avoid
depending on the whole protocol being validated, so it does an initial
validation that can leave nested types of Self (and other associated
types) somewhat unresolved. In these cases, do something icky but
partially effective: when we resolve the protocol, go back and clean
up the types of these typealiases.
A better solution would allow us to use the types of these typealiases
within the Generic Signature Builder without recording them in the AST
as "the interface type", so there's no way unresolved nested types
could be found (and, therefore, nothing to "fix up" later). Howwever,
that's a more significant undertaking.
Fixes rdar://problem/32287795.
ConstraintSolver::coerceToRValue() missed a bunch of cases where we
should be dealing with lvalues, e.g., tuples, "try" expressions, and
so on. Extend TypeChecker::coerceToRValue() to deal with the
expression type side-tables and ConstraintSolver::coerceToRValue() to
it.
Fixes rdar://problem/32700180, a crash-on-valid.
When re-typechecking an expression during diagnostics, we begin by
erasing all the types in the expression. However, any expressions
created as part of applying the solution will remain.
CSGen was doing the wrong thing when it encountered EnumIsCaseExpr,
which can only appear in already-type checked ASTs.
Returning expr->getType() is not correct, because the type is not
yet set; returning a null type is intended to signal that a
diagnostic was already emitted, which causes Sema to stop
type checking.
The end result is that certain combinations of invalid code with
an 'is' cast nested inside would crash either the AST verifier
(with asserts on) or in SILGen (with asserts off), because we
would stop trying to diagnose the issue prematurely, and possibly
not emit a diagnostic at all.
Fixes <https://bugs.swift.org/browse/SR-5050> and
<rdar://problem/32487948>.
Once we're finalizing same-type-to-concrete and superclass
constraints, replace any unresolved DependentMemberTypes with their
resolved counterpairs. This allows us to simplify
DependentGenericTypeResolver, which only builds unresolved
DependentMemberTypes now, and eliminates the penultimate use of
ArchetypeResolutionKind::AlwaysPartial.
ValueDecl::getInterfaceType() asserts if the decl has no interface
type; to check if the declaration has been type checked yet, use
hasInterfaceType().
Fixes <https://bugs.swift.org/browse/SR-4743>.
Instead, introduce a new hasDependentMember() recursive property.
The only place that cares about this is associated type inference,
where I changed all existing hasTypeParameter() checks to instead
check (hasTypeParameter() || hasDependentMember()). We could
probably refine this over time and remove some of the
hasTypeParameter() checks, but I'm being conservative for now.
Fixes <https://bugs.swift.org/browse/SR-4575> and
<rdar://problem/31603113>.
* Give Sequence a top-level Element, constrain Iterator to match
* Remove many instances of Iterator.
* Fixed various hard-coded tests
* XFAIL a few tests that need further investigation
* Change assoc type for arrayLiteralConvertible
* Mop up remaining "better expressed as a where clause" warnings
* Fix UnicodeDecoders prototype test
* Fix UIntBuffer
* Fix hard-coded Element identifier in CSDiag
* Fix up more tests
* Account for flatMap changes
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>.
