Now that we remember the DeclContext of lookup results when
doing unqualified lookup, we don't have to walk parent contexts
again to find this DeclContext.
This means that unqualified lookup is now the "single source of
truth" for what names are visible and why.
There are two "RAII cleaners" here:
- CleanupIllFormedExpressionRAII cleans up the Expr in its final state
- ExprCleanser walks the Expr before it is mutated and collects
sub-expressions, then cleans those up after
The subtle difference comes into play if we started to apply the
solution (which can fail, leaving the AST in an inconsistent state)
or if preCheckExpression() modified the AST.
The latter case was causing an ASan failure because we were not
cleaning up type variables in new nodes introduced by
preCheckExpression().
Fix this by moving the preCheckExpression() call out of
solveForExpression(), so that if solveForExpression() is called
with TypeCheckExprFlags::SkipApplyingSolution, we don't mutate the
AST at all.
Sigh...
Fixes <rdar://problem/33277279>.
When a type variable binds to an (unresolved) dependent member type,
it prevents us from inferring the type variable and adds no useful
information to the system. Refuse to bind type variables to dependent
member types.
Fixes rdar://problem/32697033.
If we encounter an associated type reference within a concrete type, but
haven't seen a specific protocol requirement, add the protocol
conformance.
Fixes rdar://problem/33139928 and another crasher.
We don't need to force the creation of potential archetypes when
finding anchors, because new potential archetypes will only be created
by this process in ill-formed generic signatures. Tolerate failure
whenever this happens (for now) and the failure paths will become dead
once AlwaysPartial is eliminated fully.
In some circumstances, we could end up growing increasingly-nested
potential archetypes due to a poor choice of representatives and
anchors. Address this in two places:
* Always prefer to use the potential archetype with a lower nesting
depth (== number of nested types) to one with a greater nesting
depth, so we don't accumulate more nested types onto the
already-longer potential archetypes, and
* Prefer archetype anchors with a lower nesting depth *except* that we
always prefer archetype anchors comprised of a sequence of
associated types (i.e., no concrete type declarations), which is
important for canonicalization.
Fixes SR-4757 / rdar://problem/31912838, as well as a regression
involving infinitely-recursive potential archetypes caused by the
previous commit.
Centralize and simplify the handling of conformance requirements
resolved by same-type-to-concrete requirements in a few ways:
* Always store a ProtocolConformanceRef in via-superclass and
via-concrete requirement sources, so we never lose this information.
* When concretizing a nested type based on its parent, use the
via-concrete conformance information rather than performing lookup
again, simplifying this operation considerably and avoiding
redundant lookups.
* When adding a conformance requirement to a potential archetype that
is equivalent to a concrete type, attempt to find and record the
conformance.
Fixes SR-4295 / rdar://problem/31372308.
resolveGenericTypeParamType(), resolveTypeOfDecl() and
resolveTypeOfContext() would all take the type of a
declaration, and optionally map it into context.
Replace them with a mapTypeIntoContext() that takes a
type and either returns it verbatim or maps it into
context.
There was undefined behavior here; we were calling
members.append(members.begin(), members.begin() + index),
which is invalid because 'members' is the new array of
members being built, which is empty at this point!
(...is constrained to be a subtype of another)
Previously the compiler would just mark the entry in the inheritance
clause invalid and move on without emitting any errors; in certain
circumstances in no-asserts builds this could actually lead to
everything working "correctly" if all conforming types happened to
pick the same concrete type for both associated types. In Swift 4 this
can actually be enforced with a same-type requirement, which will
guarantee that the two associated types are the same even in generic
contexts.
This fix avoids assertions and crashes, but the diagnostic is still
incorrect, and in the simple case of the inheritance clause it's
redundant. Doing something better and possibly even downgrading it to
a warning in Swift 3 mode is tracked by rdar://problem/32409449.
Initial patch by Slava, fixed up by me.
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.
Instead of validating sub-expressions included in the closure's result
`diagnoseAmbiguousMultiStatementClosure` was only checking parent expression
by mistake.
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>.
If a lazy var has no declared type, we have to type check the
initializer to get a type before we can build the getter.
Then, the initializer is type checked as part of the getter
again.
Use the new SkipApplyingSolution flag when type checking for
the first time. We still end up doing redundant work, but by
not applying the solution we avoid feeding invalid AST nodes
back into the constraint solver.
This fixes some bad diagnostics and crashes.
Fixes <https://bugs.swift.org/browse/SR-2616> and
<rdar://problem/28313602>.
Record the initializer type as soon as we have a solution, before
it is applied, and get the type from the constriant system instead
of from the final type checked expression.
Note that the coerceToMaterializable() was unnecessary, since we
always coerce the value to an rvalue type with coerceToType().
Eventually coerceToMaterializable() should go away.
This is mostly NFC, except using the result of simplifyType() rather
than the type of the final expression changes some diagnostics where it
appears we were previously losing sugar.
Also this accidentally fixes a crasher. Unfortunately the underlying
issue is still there (applying a solution has bugs with opened
existentials "leaking" out) -- this merely masks the problem by
getting the initializer type directly from the constriant system.
This speeds up construction of a String from large Character representations,
and various other operations that would otherwise require additional grapheme
breaking just to interpret the Character.
