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>.
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>.
