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>.
(by making it a normal argument with a label and not a trailing
closure)
Diagnostic part of rdar://problem/25607552. A later commit will keep
us from getting in this situation quite so much when default arguments
are involved.
In CSDiag.cpp I previously added a helper, isCastToTypedPointer(), to emit an
diagnostics explaining how to migrate UnsafeRawPointer conversion. This commit
broadens that diagnostic to handle Optional<UnsafeRawPointer>.
rdar:27894255 [3.0 migration] Emit an additional note for conversion
* [FixCode] Add diagnosis/fixit to help users deal with BooleanType's removal.
Due to migration reasons, types used to conform to BooleanType, which
must contain a member var 'boolValue', now does not convert to Bool. This patch
adds a specific diagnosis/fixit to explicitly invoke 'boolValue' to please the
context types.
* Address Jordan's code review comments.
We saw manual migration is necessary on these cases to add 'as Type'. This patch starts
to issue compiler fixits on return statement and initialization just like in other type-mismatch
cases.
This commit built upon the work of Pull Request 3895. Apart from the
work to make the following work
```swift
let f: (Int, Int) -> Void = { x in } // this is now an error
```
This patch also implement the part 2 mentioned in the #3895
```swift
let g: ((Int, Int)) -> Void = { y in } // y should have type (Int, Int)
```
...not just those where the functions match otherwise. This allows the
fix-it to be provided in cases where the closure being passed is a
subtype, or when there are generics involved. Yes, the '@escaping'
might not be the only issue, but it will need to get fixed, and
probably independently of anything else that's going on (except
perhaps calling the wrong function).
rdar://problem/27729540
Suppose you have this protocol:
protocol P {
typealias A = Int
typealias B = Self
}
Clearly, 'P.B' does not make sense, because then the type parameter
would "leak out" of the existential container. However, 'P.A' is totally
fine, it just means 'Int'.
Previously, we would allow 'P.A' in type context, and diagnose on 'P.B'.
However, due to an oversight, neither one was allowed in expression
context, so for example you could not write 'P.A.self', even though
that should just mean 'Int.self'.
Fix this by generalizing performMemberLookup(), and fix up some
diagnostics to be more specific when something is wrong -- we want
to avoid talking about typealiases as 'static members', since that
doesn't really make much sense.
Fixes <https://bugs.swift.org/browse/SR-2314>.
* [FixCode] Add a fixit to help users migrate to Swift 3 name convention of enum cases. rdar://26887735
When users' referring to a enum case with a wrong name and we can find a correct enum case whose name
differs from the wrong name only in capitalization, we replace the wrong name with the correct one.
* Addressing Argyrios' code review comments. NFC
* [test] Update existing test.
* Grammatical polish suggested by @CodaFi.
Suggest a fix-it for unqualified references to all static members
from instance context, not just enum elements.
Also, fix a small problem with the fix-it for replacing protocol
names with 'Self' inside extension bodies -- we didn't handle nested
functions properly.
This fixit is migration-critical to help users call functions now take 'Any' or 'NSHashble' while used to take 'AnyObject'. We insert coercion to the original call sites.
Extends the more useful diagnostics for non-escaping function
parameters used in @escaping contexts to apply to all functions that
are equivalent modulo ExtInfo.
Attempting to throw an error code value, e.g.,
throw CocoaError.fileNoSuchFileError
is now ill-formed, although it was well-formed prior to the
introduction of NSError bridging (SE-0112). Provide a specialized
diagnostic with a Fix-It to add the appropriate parentheses:
throw CocoaError(.fileNoSuchFileError)
Fixes rdar://problem/27543121.
Issue better diagnostics, along with notes and fixits, for the common
case of using an implicitly non-escaping parameter of function type in
a context expecting an @escaping closure. Provides even more specific
diagnostics for common scenarios such as passing to another function
or assignment.
Implements part of SE-0110. Single argument in closures will not be accepted if
there exists explicit type with a number of arguments that's not 1.
```swift
let f: (Int, Int) -> Void = { x in } // this is now an error
```
Note there's a second part of SE-0110 which could be considered additive,
which says one must add an extra pair of parens to specify a single arugment
type that is a tuple:
```swift
let g ((Int, Int)) -> Void = { y in } // y should have type (Int, Int)
```
This patch does not implement that part.
We previously said:
x.method = 1 // error: cannot assign to property: 'x' is immutable
we now say:
error: cannot assign to property: 'method' is a method
almost always the case that the user didn't know what the rules are between
single expression and multistatement closures, and they often don't know how to
fix the problem.
Address this by doing some heroics when we detect this situation. We now go dive
into the closure body, type check the explicit returns within it, and can usually
divine the right answer. When we do that, generate a fixit hint that generates a
modification to the existing signature, or synthesizes the entire signature from
scratch. This addresses:
<rdar://problem/22123191> QoI: multi-line closure with failure to infer result type should add a fixit
We previously produced the unhelpful error message:
x.swift:11:7: error: type of expression is ambiguous without more context
we now produce:
error: unable to infer closure return type in current context
which is going in the right direction.
Previously:
error: generic parameter 'T' could not be inferred
now:
error: unable to infer closure return type in current context
There is still more to do, but this fixes:
<rdar://problem/23570873> QoI: Poor error calling map without being able to infer "U" (closure result inference)
We previously produced the error message:
rdar25271859.swift:14:11: error: value of tuple type '(Float, Int)' has no member '0'
a.map { $0.0 }
^~ ~
We now produce:
rdar25271859.swift:15:5: error: generic parameter 'U' could not be inferred
.andThen { dataResult in
^
which is at least is correct, if not yet helpful.
