Currently ambiguity notes attached to a candidate only mention
expected type and its position. To improve clarify of such notes
it's useful to print argument type as well since it's not always
clear what it is at the first glance at the code.
Resolves: SR-14634
Resolves: rdar://78224323
Let's make use of a newly added "disable for performance" flag to
allow solver to consider overload choices where the only issue is
missing one or more labels - this makes it for a much better
diagnostic experience without any performance impact for valid code.
Instead of assuming that there is a mismatch between context and
result of the optional chain, let's actually verify that optional
evaluation expression does have a type before recording a fix.
Resolves: rdar://74696023
If there are multiple overloads and all of them require explicit
base type for a member reference, let's diagnose it as a single
error since the problem is the same across the overload choices:
```swift
func foo<T>(_: T, defaultT: T? = nil) {}
func foo<U>(_: U, defaultU: U? = nil) {}
foo(.bar)
```
In this example there is not enough contextual information to
determine base type of `.bar` reference and hence both `foo`
overloads are a considered valid solutions until explicitly set
base type disambiguates them.
Resolves: rdar://problem/66891544
This approach, suggested by Xiaodi Wu, provides better source
compatibility for existing Swift code, by breaking ties in favor of the
existing Swift semantics. Each time the backward-scan rule is needed
(and differs from the forward-scan result), we will produce a warning
+ Fix-It to prepare for Swift 6 where the backward rule can be
removed.
If it has been detected that there is an attempt to return a value
from a function without result type, let's diagnose that specifically
in cases when ternary operator is involved.
* [CSDiagnostics] Adjusting MemberAccessOnOptionalBaseFailure to be able to handle key path component member base types
* [tests] Adding regression tests for SR-5688
* [CSDiagnostics] Adjusting source range to diagnose/insert the fixes in correct location
* [tests] Adjusting regression tests to handle the fixits
* [AST] Creating an helper getSourceRange function for KeyPathExpr::Component
* [ConstraintSystem] Store member base type when recording UnwrapOptionalBase fix
* [AST] Creating a new diagnostic note for removing optional from written type
* [CSDiagnostics] Adjusting logic around MemberAccessOnOptionalBaseFailure to emit the correct diagnostics and fixes
* [tests] Adjusting regression tests to add subscript and key path root cases with respective diagnostics
* [Diagnostics] Adjusting message to mention base type
* [CSDiagnostics] Better naming for method/variable that represents base source range
* [CSDiagnostics] Adjusting to use the stored base member only when member is a key path component.
* [Diagnostics] Adjusting minor typos and code
* [AST] Adjusting keypath root diagnostic note message for use unwrapped type
* [CSDiagnostics] Adjusments in MemberAccessOnOptionalBaseFailure diagnostics as per suggestion
* [tests] Adding more test cases for SR-5688
* [CSDiagnostics] Adjusting fixits for key path root and range for diagnostics
* [CSSimplify] Attempt to diagnose InsertExplicitCall for optional function return types when possible on simplifyOptionalObjectConstraint
* [tests] Adding TODO to improve the diagnostics refering to key path root infered as optional types
* [CSDiagnostics] Adjusting comments
* [CSSimplify] Adjusting logic on simplifyOptionalObjectConstraint to attempt InsertCall fix before remove unwrap
* [CSDiagnostics] Adjust the logic to use resolveType on MemberAccessOnOptionalBaseFailure construction
Currently it's possible to have a type conflict between different
requirements deduced as the same type which leads to incorrect
diagnostics. To mitigate that let's adjust how "fixed" requirements
are stored - instead of using resolved type for the left-hand side,
let's use originating generic parameter type.
Instead of requiring sub-classes of `ContextualMismatch` to implement
`diagnoseForAmbiguity` let's implement it directly on `ContextualMismatch`
itself and check whether all of the aggregated fixes have same types on
both sides and if so, diagnose as-if it was a single fix.
In situations where left-hand side requires value-to-optional
promotion which ends up in type mismatch let's not mention
optionals in the diagnostic because they are unrelated e.g.
```swift
func test(_: UnsafePointer<Int>??) {}
var value: Float = 0
test(&value)
```
In this example `value` gets implicitly wrapped into a double optional
before `UnsafePointer<Float>` could be matched against `UnsafePointer<Int>`
associated with the parameter.
Diagnostic is about generic argument mismatch `Float` vs. `Int`
and shouldn't mention any optionals.
Detect situation when it's impossible to determine types for
closure parameters used in the body from the context. E.g.
when a call closure is associated with refers to a missing
member.
```swift
struct S {
}
S.foo { a, b in } // `S` doesn't have static member `foo`
let _ = { v in } // not enough context to infer type of `v`
_ = .foo { v in } // base type for `.foo` couldn't be determined
```
Resolves: [SR-12815](https://bugs.swift.org/browse/SR-12815)
Resolves: rdar://problem/63230293
Key path dynamic member lookup should be completely transparent
for simplification purposes, it's just a means to get to the current
overload choice.
Resolves: rdar://problem/62989214
If argument is immutable, with or without explicit `&`, let's
diagnose that as mutability problem because suggesting
to add `&` to immutable declaration is not the best possible fix.
Resolves: rdar://problem/62428353
* [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
- In `simplifyConformsToConstraint`, pass the LHS
type regardless of whether it is a type variable.
- Add the `choiceImpact` onto the impact for
adding a stdlib conformance.
- Treat Any and AnyObject as standard library
types.
* [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
