...to be compatible with Swift 3. Fortunately these cases are all safe;
they're the cases that would all be 'fileprivate' in Swift 2.
Finishes https://bugs.swift.org/browse/SR-2579, although we'll need a
follow-up bug to turn this /back/ into an error in Swift 4.
Emit a warning for optionals that are implicitly converted to Any, and
add fixits giving options to:
- Add '??' with a default value after
- Force-unwrap the optional with '!'
- Explicitly cast to 'as Any' to silence the warning
This covers diagnostics aspect of SE-0140.
rdar://problem/28196843
A variadic parameter of function type must be @escaping -- we cannot
reason about an array of non-escaping closures, so this was a safety
hole.
Also, attempting to define an @autoclosure variadic did not produce a
diagnostic, but would fail later on if you actually tried to do
anything with it. Let's ban this completely.
Both changes are source breaking, but impact is limited to code that
was already only marginally valid.
(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.
Adds in helpful notes when a closure type argument is already
escaping, and thus doesn't need annotation. The common case targeted
now is Optional and IUO, which is the biggest bang for our buck
without needlessly complicating the type options.
Test cases included for the new note, and potential interactions.
In the future we'd like some kind of parent pointer, or context stack
to give better diagnostics universally. For now, we hack it by having
ImmediateOptionalTypeArgument as a special flag.
In situations where @escaping is used in non-function-parameter
positions, we give an incorrect diagnostic message pertaining to
function types. Instead, we should just state that this is not allowed
in non-function-parameter positions.
This includes the general message fix. Unfortunately, this does not
include more friendly messages for special cases, e.g. closure members
of aggregate and optional closures. That may be possible with more
nested type context information in TypeCheckType.
When checking a conformance of a concrete type to a protocol, we
effectively checked the associated types twice -- once when
deriving them, and another time at the end, where we performed
a substitution of the protocol 'Self' type to the concrete type.
The latter checked superclass constraints, while the former did not.
However, this trick no longer works with minimized generic
signatures, because <P : Self> no longer has redundant requirements
for the associated types of 'P'.
Instead, check superclass constraints at the same time as checking
conformances.
* If current context is extension of non-final class, don't suggest stub
* If current context is extension of final class, insert 'convenience'
* If current context is direct definition of non-final class, insert 'required'
Swift does not currently support user-defined factory inits. With
import as member, we're seeing many C functions now imported as
initializers, which gives users the false hope that they can define
their own factory inits as conveinence inits in extensions of CF
types. We issue an explicit error now, rather than crashing later.
I'm slightly sad about losing the lovely code to detect
redundantly-specified defaulted arguments, but we could bring it back
later as a separate warning.
* [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.
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)
```
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>.
Member operators should be placed within a nominal type (or extension
thereof) that they operate on. Aside from being good style, enforcing
this in the type checker can help with dependency tracking. Addresses
rdar://problem/27536066.
* [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.
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.
Don't allow types conforming to 'Error' or protocol compositions
involving 'Error' to be reflected in Objective-C. We still allow
bridging conversions, but they are not statically bridged. Fixes
SR-2249/rdar://problem/27658940.
