This is useful for `CSDiag` when it detects that all
overload choices have the same problem. Since there
are going to be no solutions, choice declaration could
be supplied to `invalid ref` diagnostic directly.
Resolves: rdar://problem/50467583
Resolves: rdar://problem/50682022
Resolves: rdar://problem/50909555
Originally `filterContextualMemberList` would only return a limited
set of closeness kinds `CC_GeneralMismatch`, `CC_Argument{Label, Count}Mismatch`,
and unavailable/inaccessible. At some point later it also started
matching almost everything besides `CC_SelfMismatch` and logic in
`visitUnresolvedMemberExpr` needs to get adjusted to account for that.
Resolves: rdar://problem/50668864
This commit adds `ConstraintSystem::getCalleeLocator`, which forms a
locator that describes the callee of a given expression. This function
is then used to replace various places where this logic is duplicated.
This commit also changes the conditions under which a ConstructorMember
callee locator is formed. Previously it was formed for a CallExpr with a
TypeExpr function expr. However, now such a locator is formed if the
function expr is of AnyMetatypeType. This allows it to be more lenient
with invalid code, as well as work with DotSelfExpr.
Resolves SR-10694.
Introduce an attribute @_disfavoredOverload that can be used to state
that a particular declaration should be avoided if there is a
successful type-check for a non-@_disfavoredOverload. It's a way to
nudge overload resolution away from particular solutions.
Detect and diagnose a contextual mismatch between expected
collection element type and the one provided (e.g. source
of the assignment or argument to a call) e.g.:
```swift
let _: [Int] = ["hello"]
func foo(_: [Int]) {}
foo(["hello"])
```
Now covers following new areas (alongside simple assignments):
- Contextual type coercions:
- In assignment e.g. `let _: X = foo`
- In return type positions e.g. `func foo() -> A { return bar }`
- Argument-to-parameter applications (including @autoclosure)
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.
If "convertTo" type is an optional let's look through it to see
whether it contains another function type which, if so, would
rule out possibility of missing explicit call.
Resolves: rdar://problem/50438071
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.
Enhance call-argument matching to reject trailing closures that match up
with parameters that cannot accept closures at all.
Fixes rdar://problem/50362170.
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.
Escapingness is a property of the type of a value, not a property of a function
parameter. Having it as a separate parameter flag just meant one more piece of
state that could get out of sync and cause weird problems.
Instead, always look at the noescape bit in a function type as the canonical
source of truth.
This does mean that '@escaping' is now printed in a few diagnostics where it was
not printed before; we can investigate these as separate issues, but it is
correct to print it there because the function types in question are, in fact,
escaping.
Fixes <https://bugs.swift.org/browse/SR-10256>, <rdar://problem/49522774>.
In a few corner cases we built DeclRefExpr and MemberRefExpr
for references to types. These should just be TypeExpr so that
SILGen doesn't have to deal with it.
This also fixes a bug where a protocol typealias with an
unbound generic type could not be accessed properly from
expression context, but that is just so incredibly obscure.
The main fixes here are:
- we weren't looking through open-existentials in the l-value
- we weren't handling mutating gets correctly unless CSApply wrapped
the base in an InOutExpr, which seems to be multifile-sensitive
- we were missing diagnostics in some cases involving subscripts
A better fix would be to re-introduce LValueAccessKind, but I wanted
a workable short-term fix that I could try to get into 5.1.
Fixes rdar://49482742, which is specific to the lazy-getter problem.
For example if there a structure which requires multiple implicit
dynamic member calls to get the members:
```swift
struct Point { var x, y: Int }
@dynamicMemberLookup
struct Lens<T> {
var obj: T
subscript<U>(dynamicMember member: KeyPath<T, U>) -> U {
get { return obj[keyPath: member] }
}
}
func foo(_ lens: Lens<Lens<Point>>) {
_ = lens.x
_ = lens.obj.x
_ = lens.obj.obj.x
}
_ = \Lens<Lens<Point>>.x
```
