Change the fix-it to move the argument to its correct location in one go. This happens by removing it from one location and inserting it in the other (as opposed to the original implementation which swapped one argument with the preceding one). The commas separating the arguments are adjusted to match the moved argument.
Add new tests for reordering regular arguments, variadic arguments, and function arguments.
Resolves: SR-4715 rdar://problem/31849281
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
Currently some contextual errors are discovered too late
which leads to diagnostics of unrelated problems like argument
mismatches, these changes attempt to improve the situation
and try to diagnose contextual errors related to calls
before everything else.
Resolves: SR-5045, rdar://problem/32934129
In some situations e.g. while trying to shrink domains of the type
variables before attempting search, use a flag to tell constraint
system to retain all of the viable solutions otherwise solver could
loose some of the information required to produce complete solution.
Resolves: rdar://problem/32726044
Instead of doing that, suggest removing 'var' altogether because
'let' cannot be used directly in an implicitly immutable context.
Resolves: rdar://problem/32390726
Properly diagnose cases of function/subscript argument tuple
structuring/destructuring related by not limited to SE-0110.
Resolves: rdar://problem/31973368
Add `FailureDiagnostics::visitKeyPathExpr` to try and diagnose contextual
value type problems related to Smart KeyPath feature. If problems with
contextual value type can't be diagnosed let's walk components and see
if there are any structural problems with expression itself e.g. unknown
members and incorrect types in the path.
Resolves: rdar://problem/32101765
```swift
func foo(f: Void) -> ()) {}
```
This compiler currently suggests we change this to:
```swift
func foo(f: (Void) -> ()) {}
```
That's `(()) -> ()`, almost certainly not what someone wants in Swift
4. We should suggest changing that to:
```swift
func foo(f: () -> ()) {}
```
Additionally,
```swift
func foo(f: (Void) -> ()) {}
```
Should trigger a warning that the `(Void)` input type is `(())`, and you
can't supply `()` to it in Swift 4, and suggest a fix-it change it to:
```swift
func foo(f: () -> ()) {}
```
rdar://problem/32143617
`FailureDiagnosis::visitUnresolvedMemberExpr` tries to use the same logic
as `diagnoseSingleCandidateFailures` so instead of doing that let's remove
some of the special handling and use `diagnoseSingleCandidateFailures`
directly instead, which improves label diagnostics and handles more erroneous
cases as well.
Resolves: rdar://problem/31898542
Previously situations like `self.foo(...)` wouldn't be considered as viable
for diagnosing the instance method on type calls, because the base wasn't
TypeExpr, which only accounts for e.g. `X.foo`, instead of validating base
expression itself this patch checks if the _type_ of base expression is
Metatype which is less restrictive.
Resolves: SR-4692.
Any ambiguity inside of a call with a trailing closure
call was going down the code path that would tell you to
add an argument label... but the ambiguity might not be
with the call that has the trailing closure itself, and
instead something inside.
* One-sided ranges and RangeExpression
* Remove redundant ClosedRange methods from String
* Fix up brittle tests
* Account for Substring update
* XFAIL range diagnostics on Linux
Previously we had more ad hoc logic that tried to decide if it was
worth desugaring a type based on its structure. Now we instead look
for a typealias that might actually benefit from desugaring, and if
we don't find one we won't show the 'aka' note.
FailureDiagnosis::visitApplyExpr is going to attempt to type-check
argument expression multiple times - with and without allowing free
type variables, since first type-check might mutate AST if (sub-expression
type-checks correctly) it's required to fix up ternary operations
represented as IfExpr to it's original condition form, because IfExpr
is going to convert Bool into implicit call `(Bool) -> () -> Int1`
upon successful type-check, which is not handled by either
ConstraintGenerator nor ExprRewriter because they don't expect
well-formed type-checked IfExpr is input.
Resolves: <rdar://problem/29850459>.
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>.
When trying to diagnose ambigiuty with constraint system check if any of the
unresolved type variables are related to generic parameters, and if so
try to diagnose a problem based on the number of constraints associated with
each of the unresolved generic parameters.
Number of constraints related to a particular generic parameter
is significant indicator of the problem, because if there are
no constraints associated with it, that means it can't ever be resolved,
such helps to diagnose situations like: struct S<A, B> { init(_ a: A) {}}
because type B would have no constraints associated with it.
Always check arguments of the tuple type against corresponding parameters,
otherwise for a single argument functions e.g. foo(_ a: Any) after SE-0046
type checker is going to produce incorrect solution.
Switch printing off of using Function's ExtInfo for autoclosure and
escaping, and onto the ParameterTypeFlags, which let us do precise and
accurate context-sensitive printing of these parameter type
attributes. This fixes a huge list of issues where we were printing
@escaping for things like optional ObjC completion handlers, among
many others. We now correctly print @escaping in more places, and
don't print it when it's not correct.
Also updates the dumper to be consistent and give a good view of the
AST as represented in memory. Tests updated, more involved testing
coming soon.
The fixits call back into the type checker via typeCheckCheckedCast(),
which sets up a new constraint system. As a result we would hit
assertions by introducing type variables from a previous "generation".
It seems that if we bail out of this code path altogether, we get a
better diagnostic -- in the provided test, it complains about an
ambiguous member to '.value', rather than not being able to convert
_? to V?.
Fixes <https://bugs.swift.org/browse/SR-2592>.
From the Swift documentation:
"If you define an optional variable without providing a default value,
the variable is automatically set to nil for you."
