This fixes a recent source break. We need to perform the normal
unqualified lookup before we handle the special case of 'Self',
because there might be a type named Self defined in an outer
context.
Fixes <https://bugs.swift.org/browse/SR-12133> / <rdar://problem/59216636>
Tests seem to pass without these.
Two calls still remain, in ModuleDecl::addFiles() and removeFiles().
It will take a bit more refactoring to eliminate those.
Problem(s) which caused `ErrorExpr` to be added to AST should be
diagnosed already and solver wouldn't be able to produce a viable
solution in such case anyway.
Identify problems like:
```swift
func foo(_ x: Int, _ y: String) {}
func bar(a: Int, b: String) {
foo(b, a) // Instead of `foo(a, b)`
}
```
Where arguments are out-of-order and repair it by using OoO fix on the
parent locator.
If one of the parameters represents a destructured tuple
e.g. `{ (x: Int, (y: Int, z: Int)) in ... }` let's fail
inference and not attempt to solve the constraint system because:
a. Destructuring has already been diagnosed by the parser;
b. Body of the closure would have error expressions for
each incorrect parameter reference and solver wouldn't
be able to produce any viable solutions.
Just like in cases where both sides are dependent member types
with resolved base that can't be simplified to a concrete type
let's ignore this mismatch and mark affected type variable as a hole
because something else has to be fixed already for this to happen.
When there is a conversion from e.g. `(A) -> Void` to `(B) -> Void`
matching between `A` and `B` is going to have a special locator which
doesn't end in `TupleElement`, so `repairFailures` has to account
for that and fix it just like regular argument mismatch.
Resolves: rdar://problem/59066040
Diagnose ambiguity related to overloaded declarations where only
*some* of the overload choices have ephemeral pointer warnings/errors
associated with them. Such situations have be handled specifically
because ephemeral fixes do not affect the score.
If all of the overloads have ephemeral fixes associated with them
it's much easier to diagnose through notes associated with each fix.
Prioritize type mismatches over conformance failures when stdlib
types are involved because it wouldn't be appropriate to suggest
to add such a conformance, so the problem is most likely related
to something else e.g. other overload choice has a better fix.
Consider following example:
```swift
struct S {
init(_: Double) {}
init<T: BinaryInteger>(_: T) {}
}
_ = S(Double("0"))
```
In cases like that it's better to prefer failable initializer
which takes a `String` and returns `Double?` and diagnose a
problem related to missing optional unwrap instead of missing
conformances related to a `String` argument of other `Double`
initializer just because it returns a concrete type.
Since `simplifyRestrictedConstraintImpl` has both parent types and
does nested type matching it's a good place to diagnose top-level
contextual problems like mismatches in underlying types of optionals.
If it's possible to build an Objective-C key path for key path
expression make sure that its implicitly generated string literal
expression has a `String` type.
Resolves: rdar://problem/57356196
There were changes due to the StringRef to std::string conversion, changes
in the Debug Info DIBuilder::createModule API, and a drop in the using for
PointerUnion4 since PointerUnion is now a variadic template and will do in its
place.
This general notion of wiring up the types of variables that occur
within a pattern to the types in the produced pattern type is useful
outside of function builders, too.
It's done by first retrieving all generic parameters from each solution,
filtering boundings into distrinct set and diagnosing any differences.
For example:
```swift
func foo<T>(_: T, _: T) {}
func bar(x: Int, y: Float) {
foo(x, y)
}
```
Introduce support for initialized let/var declarations within function
builder closures, e.g.,
let (a, b) = c()
We generate constraints for the declarations as elsewhere, but the types of
the declared variables (a and b in this case) are bound to the type of the
pattern by one-way constraints, to describe the flow of type information
through the closure.
Implements rdar://problem/57330696.
When applying a function builder to a closure to produce the final,
type-checked closure, use the new rewriteTarget() so it’s performed on
a per-target basis. Use this to eliminate some duplicating in the handling
of return types.
