Avoid walking TapExprs, SingleValueStmtExprs, and key paths. The latter
is important since they can contain invalid VarDecls that will no
longer be visited by the ASTWalker after key path resolution, so we
don't want to create case body vars for them.
Eagerly bind invalid type references to holes and propagate contextual
type holes in `repairFailures`. This avoids some unnecessary diagnostics
in cases where we have an invalid contextual type.
Pattern resolution currently invokes type resolution with this flag
since it's trying to see if it can treat a given expression as a
TypeRepr for e.g an enum pattern. Make sure we don't `setInvalid` on
such TypeRepr nodes since that will avoid diagnosing in cases where
the node also then gets treated as a TypeRepr for an ExprPattern,
where we actually want the diagnostic emitted.
Resolving only a structural type meant we weren't checking generic
constraints, allowing invalid extensions to get past the type-checker.
Change to resolve an interface type.
Lift the limitation of a single active diagnostic, which was a pretty
easy-to-hit footgun. We now maintain an array of active in-flight
diagnostics, which gets flushed once all them have ended.
For a method key path use the locator for the apply itself rather
than the member, ensuring we handle invalid cases where the apply is
the first component, and providing more accurate location info.
The invalid bit on PatternBindingDecl is very coarse grained, it
means any of the possible binding entries could be invalid.
Contextualization can handle invalid code anyway (e.g this is what we
do for `typeCheckBody`), so let's just avoid checking.
Correct several behaviors of availability checking in unavailable contexts that
were inconsistent with the checking model:
- Avoid diagnosing unintroduced and obsolted declarations in contexts that are
unavailable in the same domain.
- Diagnose unavailability normally in type signature contexts.
`return` statement withot an expression automatically gets an
implicit `()` which is allowed to be converted to types like
`()?` and `Any` or `Any?`. Let's remove a too strict assertion
that expected a contextual type to always be `()?` even
through in reality any type that `()` is convertible to is valid.
Resolves: rdar://152553143
Set an upper bound on the number of chained lookups we attempt to
avoid spinning while trying to recursively apply the same dynamic
member lookup to itself.
rdar://157288911
While the intent behind this functor was noble, it has grown in complexity
considerably over the years, and it seems to be nothing but a source of
crashes in practice. I don't want to deal with it anymore, so I've decided
to just subsume all usages with LookUpConformanceInModule instead.
