This updates the error message so that in the case where we can find a
Decl, it gives the error "cannot assign through subscript: 'name' is a
read-only key path", and in the case where there's no associated Decl, gives the
error message "cannot assign through subscript: key path is read-only".
Additionally updates tests with the new error messages and formats all changes.
KeyPath dynamic member lookup is limited to what key path itself
could do, so let's detect and diagnose invalid references just
like we do for regular key path expressions.
Resolves: rdar://problem/50376224
Detect difference in escapiness while matching function types
in the solver and record a fix that suggests to add @escaping
attribute where appropriate.
Also emit a tailored diagnostic when non-escaping parameter
type is used as a type of a generic parameter.
If the source of the assignment is a function type which has
a result that could be converted to expected destination type,
let's diagnose that as missing call if such function doesn't
have any parameters.
New diagnostic framework can already identify contextual failures
related to opaque return types, `RequirementFailure` just needs
to get adjusted to identify correct affected declaration and provide
tailored diagnostic.
Resolves: rdar://problem/49582531
Detect situations where key path doesn't have capability required
by the context e.g. read-only vs. writable, or either root or value
types are incorrect e.g.
```swift
struct S { let foo: Int }
let _: WritableKeyPath<S, Int> = \.foo
```
Here context requires a writable key path but `foo` property is
read-only.
Referencing (instance or static) methods in the key path is not
currently allowed, solver should be responsible for early detection
and diagnosis of both standalone e.g. `\.foo` and chained
e.g. `\.foo.bar` (where foo is a method) references in key path
components.
```swift
struct S {
func foo() -> Int { return 42 }
}
let _: KeyPath<S, Int> = \.foo
```
Resolves: rdar://problem/49413561
We have a systemic class of issues where noescape types end up bound to
type variables in places that should not. The existing diagnostic for
this is ad-hoc and duplicated in several places but it doesn't actually
address the root cause of the problem.
For now, I've changed all call sites of createTypeVariable() to set the
new flag. I plan on removing enough occurrences of the flag to replicate
the old diagnostics. Then we can continue to refine this over time.
Since there is a way to mutate through use of writable keypath
diagnostics have to be adjusted to point to the members found
via keypath member lookup instead to using catch-all
"immutable base" diagnostic.
Instead of passing all of the information available in the diagnostic
to static functions, let's bring "default value" and "force unwrap"
fix-it logic under "missing optional unwrap diagnostic" umbrella.
This PR migrates instance member on type and type member on instance diagnostics handling to use the new diagnostics framework (fixes) and create more reliable and accurate diagnostics in such scenarios.
Previously the logic to determine path to the selected overload
in such case was simplistic and only checked the name to be
of constructor, but `ConstructorMember` path is formed only if
member reference is a constructor delegation e.g. `self.init` or
`super.init` in an initializer context.
Detect that failed requirement comes from contextual type and use
that information to determine affected declaration.
Resolves: rdar://problem/47980354
