This helps to avoid allocating new type variables (which shouldn't be done regardless)
to store parameter indices when `missing arguments` diagnostic is used by other diagnostics.
Make diagnostics stateless by providing them with a solution
instead of applying a solution back to constraint system and
using constraint system. Latter doesn't work well when there
is an ambiguity and multiple solutions are available instead
of one.
If mismatch detected by `repairFailures` is related to a complex
wrapped value of optional type formed from optional-to-optional
or value-to-optional conversion let's not try to fix it directly
but let `simplifyRestrictedConstraintImpl` record a top-level fix
for more context.
Resolves: rdar://problem/59703585
It detends on a situation whether try? would get a type inferred
so the mismatch is against a contextual type, or contextual type
would be used as a type of `try?` and fail comparsion with inner
expression type. In either case the mismatch is contextual.
This is something I noticed by inspection while working on
<https://bugs.swift.org/browse/SR-75>.
Inside a static method, 'self' is a metatype value, so
'self.instanceMethod' produces an unbound reference of type
(Self) -> (Args...) -> Results.
You might guess that 'super.instanceMethod' can similarly
be used to produce an unbound method reference that calls
the superclass method given any 'self' value, but unfortunately
it doesn't work.
Instead, 'super.instanceMethod' would produce the same
result as 'self.instanceMethod'. Maybe we can implement this
later, but for now, let's just diagnose the problem.
Note that partially-applied method references with 'super.'
-- namely, 'self.staticMethod' inside a static context, or
'self.instanceMethod' inside an instance context, continue
to work as before.
They have the type (Args...) -> Result; since the self value
has already been applied we don't hit the representational
issue.
Extend the constraint system’s diagnostics with specific handling for
matching an enum element pattern that has a subpattern (i.e., to capture
associated values) against an enum case that does not have any associated
value. This brings diagnostics for the new code path on par with the existing
diagnostics of coercePatternToType.
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.
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.
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)
}
```
* [CSDiagnostics] Offer a fix-it to insert a return type when returning from a void function
* [CSDiagnostics] Make sure the function name is not empty
The function name will be empty in some cases, for example for property setters. In cases where the function name is empty, skip the note and fix-it.
* [Test] Update existing diagnostics
If parameter type is optional let's ignore that since argument could
be either optional itself or be injected into optional implicitly.
```swift
func foo(_: ((Int, Int) -> Void)!) {}
foo { _ in } // Missing second closure parameter
```
This helps to diagnose contextual mismatches like `Int? vs. Bool`
instead of suggesting to unwrap the optional which would still
produce an incorrect type.
Diagnose an attempt to reference a top-level name shadowed by
a local member e.g.
```swift
extension Sequence {
func test() -> Int {
return max(1, 2)
}
}
```
Here `min` refers to a global function `min<T>(_: T, _: T)` in `Swift`
module and can only be accessed by adding `Swift.` to it, because `Sequence`
has a member named `min` which accepts a single argument.
Expressions like `Void(...)` have a special locator which ends at
`FunctionArgument` instead of `ApplyArgument` which makes it possible
to type-check `Void()` call successfully. "extraneous arguments" diagnostic
needs to handle such situations specifically e.g. `Void(0)`.
When requesting information about the contextual type of a constraint
system, do so using a given expression rather than treating it like
the global state that it is.
The right solution is to extend the notion of the "anchor" of a locator
to also cover statements (and TypeReprs, and Patterns, and more), so
this is a stop-gap.
