Fix problem related to Swift 3 mode (with assertions),
since Swift 3 mode allows passing arguments with extra parens
to parameters which don't expect them, it should be supported
by "deep equality" types e.g. Optional<T>:
```swift
func foo(_: (() -> Void)?) {}
func bar() -> ((()) -> Void)? { return nil }
foo(bar) // This expression should compile in Swift 3 mode
```
Resolves: rdar://problem/35198459
When trying to diagnose problems related to calls where
function is represented by a member of nominal type let's
attempt to be more cautious while type-checking function
expression without it's arguments, because it could produce
unrelated diagnostics.
Resolves: rdar://problem/32551313, rdar://problem/28456467, rdar://problem/31671195
This makes it a lot easier to diagnose contextual mismatch related
to arguments used by the call without relying on the type of the
function expression which is not always available.
If there are parameters missing in the closure declaration and
all of the present ones are anonymous let's emit a fix it suggesting
missing parameters.
Resolves: rdar://problem/32301091
Properly diagnose cases of function/subscript argument tuple
structuring/destructuring related by not limited to SE-0110.
Resolves: rdar://problem/31973368
While diagnosing index expression associated with subscript call
`validateContextualType` didn't look through TupleType to identify
potential nullability of the contextual type related to generic
parameters.
Resolves: rdar://problem/31724211
This snippet type checks in Swift 4 mode, but not in Swift 3.
It used to work in Swift 3.0, so something broke when we
implemented SE-0110 and redid the Swift 3 mode emulation.
The prohibition in Swift 3.0 missed the case where the single-element tuple was wrapped in extra parens as the only argument of a function. We've ripped out parts of the type checker that try to cope with single-element tuples, and it would be risky and bug-prone to try to admit this code, so it's better to fix the ban than to try to accept the code, alas. Fixes SR-3788.
Swift 3.0 allowed constructing an enum or calling a function-typed
property with multiple arguments even when a single argument of tuple
type was expected. Emulate that in Swift 3 mode by wrapping in an
extra level of parentheses when the situation comes up.
Last vestiges of fallout from SE-0110. Hopefully last, anyway. A nice
follow-up to this commit might be to /warn/ in Swift 3 mode when this
happens.
rdar://problem/30171399
In Swift 3, we had a bug where you could provide argument labels
to a function call taking a single Any parameter, even if the
parameter did not have a label.
This mostly worked (with asserts off!) but in fact it would crash
in SILGen if you were calling an enum case constructor.
Since this 'feature' has been promoted from 'works on accident' to
'still a hack but guarded by Swift 3 mode and exists on purpose',
fix the crash, even though Swift 3 could not compile the code in
question.
Also add a Swift 3 mode check to the earlier SILGen hack, so that
when/if we remove Swift 3 mode it will be obvious that this code is
now dead too.
In Swift 3.0.1, argument labels are ignored when calling a function
having a single parameter of 'Any' type. That is, if we have:
func foo(_: Any) {}
Both of the following were accepted in a no-assert build (an assert
build would crash, but the GM builds of Xcode ship with asserts off):
foo(123)
foo(data: 123)
This behavior was fixed by 578e36a7e1,
but unfortunately we have to revert to the old behavior *and* defeat
the assertion when in Swift 3 mode.
Swift 4 mode still has the correct behavior, where the second call
'foo(data: 123)' produces a diagnostic.
Now, I have to pour myself a strong drink to forget this ever happened.
Fixes <rdar://problem/28952837>.
There's a general problem where a SubscriptExpr has an argument
that's a LoadExpr loading a tuple from an lvalue. For some reason
we don't construct the ParenExpr in this case, which confused
CSDiag.
Also, in Swift 3 mode, add a total hack to fudge things in
matchCallArguments() in the case where we erroneously lost
ParenType sugar.
Fix matchTypes() to be more careful about stripping off ParenType
sugar, in order to match the behavior outlined in SE-0110.
Note that the new logic only executes in Swift 4 mode; there's
no functional change here in Swift 3 mode.
This makes a second copy of the tuple_arguments test:
- Compatibility/tuple_arguments is a test for Swift 3, updated to
note differences with Swift 3.
- Constraints/tuple_arguments has been updated for the new Swift 4
mode behavior.
Fixes <rdar://problem/27383557>.
