Within unqualified name lookup, replace uses of Type-based lookup
(formed from calls to getSelfTypeInContext()) with declaration-based
name lookup, so that name lookup doesn't depend directly on the type
checker.
The main oddity here is that we need to consider "Self: Foo"
requirements within a protocol extension during name lookup, so that
we will also look into "Foo". This is handled via the basic
name-lookup facilities that allow us to resolve TypeReprs to
declarations without going through the type checker.
TypeResolutionFlags is overly complicated at the moment because the vast
majority of flag combinations are impossible and nonsensical. With this
patch, we create a new TypeResolverContext type that is a classic enum
and far easier to reason about. It also enables "exhaustive enum"
checking, unlike the "flags" based approach.
Existence of semantic expr (`getSemanticExpr()`) prevents ASTWalker
walking into the *original* sub expressions which may cause
re-typechecking failure. For example,
`ConstraintGenerator::visitArrayExpr()` assumes we already visited its
elements, but that's not the case if the semantic expr exists.
rdar://problem/42639255
Since constraint fix life span is tightly coupled with particular
constraint system, it makes sense to allocate fixes using the same
allocator as used for constraints.
Make is so `FixKind` lives in the new `CSFix` header and
all new `ConstraintFix` classes get a kind. That's useful
when trying to identify if locator has multiple fixes of
the same kind attached to it.
A fix is related to one of the constraints through its locator,
and contains information required to "fix" a failure associated with
given constraint, each of the fixes also includes diagnostic.
Pass constraint system down into offering force unwrap fixits so that we can identify the type of the last member chosen for an optional chain. If there's a chain and the last member's return type isn't optional, then it's cleaner to offer to change that last '?' into a '!' to perform the force, rather than parenthesize the whole expression and force the result.
This is a legacy holdover from when tuple types had default
arguments, and also the constraint solver's matching of function
types pre-SE-0110.
Well, move the last live usage to CSDiag, where it can die a slow
painful death over time. The other usages were not doing anything.
In Swift, wrapping the type of a function parameter in parentheses
never changes its meaning. By this logic,
func foo(x: (inout Int))
should be equivalent to
func foo(x: inout Int)
This worked in Swift 4.1 but regressed when the new function type
representation was introduced.
The main purpose of doing this is to eliminate the need for some special
cases for materializeForSet (and read and modify) in the requirements-
gathering code, but it should also be a small performance improvement
for code that's heavy in generic subscripts.
Unresolved member calls e.g. `.foo(1, 2)` are unique in a way that
they don't form regular application expressions. So let's teach
`simplifyLocator` how to extract arguments from such calls
based on locators like:
`[UnresolvedMemberExpr -> apply argument -> comparing call argument # to parameter #]`.
This helps to diagnose more failures via diagnostics attached to
constraint system fixes.
