Add a flag to `ConstraintSystem::preCheckExpression` and subsequently
to `TypeChecker::resolveDeclRefExpr` to indicate whether it's allowed
to replace invalid member refs with `ErrorExpr`.
It is useful for diagnostics and code completion to preserve AST
in it's original state otherwise it's impossible to diagnose errors
post factum or extract `CodeCompletionExpr` when it's a child of an
invalid reference.
Fix is anchored on a `BraceStmt` associated with an invalid closure.
It's diagnosing the problem by calling `ConstraintSystem::preCheckExpression`
for all expressions in the body without suppressing errors.
Diagnosis for invalid uses of trailing closures has been folded in
with argument-matching diagnostics, so remove all of the machinery
around the syntactic "mismatched trailing closure" logic.
* [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
If parameter has a function type and no argument overload choices
match let's diagnose that specifically.
Resolves: [SR-12689](https://bugs.swift.org/browse/SR-12689)
Resolves: rdar://problem/62481592
For cases like this:
```swift
struct X {}
struct Y {}
func overloaded<T>(_ value: T) -> T { value }
func overloaded<T>(_ value: T) -> Int { 0 }
func test(x: inout X, y: Y) {
x = overloaded(y)
}
```
Solver would record a `IgnoreAssignmentDestinationType` fix per overload,
`diagnoseForAmbiguity` could be used to properly diagnose ambiguity cases
like that.
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.
Introduce `repairByUsingRawValueOfRawRepresentableType` which is used for
assignment, argument-to-parameter conversions and contextual mismatches.
It checks whether `from` side is a raw representable type and tries
to match `to` side to its `rawValue`.
Also extract logic common for `repairByUsingRawValueOfRawRepresentableType`
and `repairByExplicitRawRepresentativeUse` into `isValueOfRawRepresentable`.
If either `MarkExplicitlyEscaping` or `TreatRValueAsLValue` fix
points to an argument-to-parameter conversion, let's add more
more clarifying argument to the locator to pinpoint the problem.
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
When simplifying a keypath constraint with a function type binding, single-parameter functions have the parameter type and the return type matched against the keypath root and value; whereas multiple-parameter functions cause an ambiguous failure (in `simplifyKeyPathConstraint`).
Resolves rdar://problem/57930643
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.
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.
Instead of always applying solution back to constraint system
before diagnostics, let's pass solution directly to `ConstaintFix::diagnose`
method to be used by `FailureDiagnostic` which paves a way for
stateless diagnostics.
