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"])
```
Diagnostics could introduce type-checked expressions into AST during
it's bottom up re-typechecking in attempt to find a problem.
To minimize number of AST permutations solver has to handle
let's just strip away implicit `InOutExpr` introduced by previous
successful type-checks, which is not really important anyway.
Resolves: rdar://problem/46459603
With all else equal prioritize bindings with fewer defaultable types,
which always gets us closer to solution since defaultable bindings
mostly come from the collections and could be checked at the end.
This also makes sure that solver not as aggresive at assigning bindings
to trailing closures and allows solver to consider types which come
from inside the closure.
Resolves: rdar://problem/37290898
Let's not attempt to link arithmetic operators together in
presence of concrete and literal (int, float, string) types.
Resolves: rdar://problem/35740653
Shrinking such expressions will immediately restrict the solution set
to the default literal types (Int or Double), causing later solutions
to fail. Fixes rdar://problem/30220565.
The default behavior was looking *through* the ForceValueExpr, so in this test case the LinkedExprAnalyzer thought it was dealing with Optional<Double> rather than Double. Resolves SR-1122.
What I've implemented here deviates from the current proposal text
in the following ways:
- I had to introduce a FunctionArrowPrecedence to capture the parsing
of -> in expression contexts.
- I found it convenient to continue to model the assignment property
explicitly.
- The comparison and casting operators have historically been
non-associative; I have chosen to preserve that, since I don't
think this proposal intended to change it.
- This uses the precedence group names and higherThan/lowerThan
as agreed in discussion.
Allow 'static' (or, in classes, final 'class') operators to be
declared within types and extensions thereof. Within protocols,
require operators to be marked 'static'. Use a warning with a Fix-It
to stage this in, so we don't break the world's code.
Protocol conformance checking already seems to work, so add some tests
for that. Update a pile of tests and the standard library to include
the required 'static' keywords.
There is an amusing name-mangling change here. Global operators were
getting marked as 'static' (for silly reasons), so their mangled names
had the 'Z' modifier for static methods, even though this doesn't make
sense. Now, operators within types and extensions need to be 'static'
as written.
