Previously we could allow some invalid coercions to
sneak past Sema. In most cases these would either
cause crashes later down the pipeline or
miscompiles. However, for coercions between
collections, we emitted somewhat reasonable code
that performed a force cast.
This commit aims to preserve compatibility with
those collection coercions that previously
compiled, and emits a warning telling the user to
use either 'as?' or 'as!' instead.
New name is more consistent with existing `getOverloadChoiceIfAvailable`
and allows us to clean up a couple of places where `getCalleeLocator` was
used directly before.
* [CSDiagnostics] Handle arg to param generic when locator points to ConstraintLocator::GenericArgument
* [test] Add SR-12242 test case
* [CSDiagnostics] Handle arg to param on Generic mismatch as a fallback diagnostic
* [CSDiagnostics] Make assign diagnostics in GenericMismatchFailure handle more cases
* [test] Adding test cases for assign expr in GenericMismatch diagnostics
* [CSDiagnostics] Improving inout to pointer argument conversions with optionals diagnostics
Type on the right-hand side of the element conversion/pattern match
should be allowed to have holes to be able to diagnose failures with
structurally incompatible types.
Resolves: rdar://problem/60832876
It's allowed to convert a single statement closure from `(...) -> T` to `(...) -> Void`
_only_ if there is no explicit `return` in the body.
Resolves: [SR-12277](https://bugs.swift.org/browse/SR-12277)
Resolves: rdar://problem/52204414
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.
