Some diagnostics got worse, but I think the reduction in compiler complexity
is worth it, and copy-and-pasting Swift 2 code is not likely to produce great
results anyway.
Also, this corrects an oversight where we did not reject @pseudogeneric on
function types in AST parsing.
Ensure the class is fully defined before performing the `is_convertible`
check which may trigger a compiler builtin. Before the class is
complete, the compiler can not technically perform the check on it.
This fixes the build with `cl`.
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.
Based on the existing access checker for types used in decls. There's
a common skeleton here but we can't seem to get it out, so for now
add a third DeclVisitor to this file. On the plus side, checking this
alongside access is an easy way to make sure everything gets checked.
Part of rdar://problem/48991061
I wish there was more we could share with the upcoming
implementation-only checker, but I don't see an obvious way to do it.
All the call sites want to know what kind of declaration they're
visiting in order to customize the diagnostic, or downgrade something
to a warning, or something else.
No functionality change.
Expression patterns (and cast patterns) don't actually contribute to
the exhaustivity of a switch statement---if you're matching against a
String, matching "abc" doesn't meaningfully reduce the full space of
the values you have to match. This was already handled, but didn't do
the right thing in a particular case involving a tuple payload in an
enum after the Space Engine (exhaustivity checker) optimizations that
went out in Swift 5.
https://bugs.swift.org/browse/SR-10301
Specifically the bad pattern was:
```
for (auto *vd : *caseStmt->getCaseBodyVariables()) { ... }
```
The problem is that the optional is not lifetime extended over the for loop. To
work around this, I changed the API of CaseStmt's getCaseBodyVariable methods to
never return the inner Optional<MutableArrayRef<T>>. Now we have the following 3
methods (ignoring const differences):
1. CaseStmt::hasCaseBodyVariables().
2. CaseStmt::getCaseBodyVariables(). Asserts if the case body variable array was
never specified.
3. CaseStmt::getCaseBodyVariablesOrEmptyArray(). Returns either the case body
variables array or an empty array if we were never given any case body
variable array.
This should prevent anyone else in the future from hitting this type of bug.
radar://49609717
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
```
Since filtering currently runs as part of the `applicable function`
constraint processing, "keypath dynamic member lookup" choice can't
be attempted in-place because that would also try to operate on that
constraint, so instead let's keep the disjunction, but disable all
unviable choices.
Resolves: rdar://problem/49533404
We set the type of ParamDecls when applying solutions in the normal path, but
sometimes code completion will type check an expression inside a closure without
checking the outer expression. In this case, we may have inferred a type for
the ParamDecl, but we don't write it back.
Instead, just look at the DeclRefExpr's type.
Fixes <rdar://problem/42098113>.
This is a defensive move to avoid duplicated work and guard against crashes
when a multi-expression closure body or TapExpr has not been type checked yet.
Fixes <rdar://problem/48852402>.
