For Swift 3 / 4:
Deprecate the spelling "ImplicitlyUnwrappedOptional", emitting a warning
and suggesting "!" in places where they are allowed according to
SE-0054.
In places where SE-0054 disallowed IUOs but we continued to accept them
in previous compilers, emit a warning suggesting "Optional" or "?" as
an alternative depending on context and treat the IUO as an Optional,
noting this in the diagnostic.
For Swift 5:
Treat "ImplicitlyUnwrappedOptional" as an error, suggesting
"!" in places where they are allowed by SE-0054.
In places where SE-0054 disallowed IUOs, emit an error suggestion
"Optional" or "?" as an alternative depending on context.
Per SE-0054, implicitly unwrapped optional is not a distinct type in the
type system, but rather just the notion that certain Optionals (denoted
by the sigil "!" rather than "?") can be implicitly unwrapped.
This is a first step in the direction of implementing this notion by
emitting a warning if the type is spelled out.
We were checking the accessibility of the setter incorrectly.
As a result, a 'public internal(set)' property could not override
another 'public internal(set)' property; the setter had to be
public in the override, which is unnecessarily visible.
Fixes <rdar://problem/34085586>.
In today's Swift, only non-optional function parameters can be
non-escaping (and are by default). An optional function parameter uses
a function type as a generic argument to Optional, and like any other
generics that's considered an opaque and therefore possibly escaping
use of the type. This is certainly unfortunate since it means a
function parameter cannot be both Optional and non-escaping.
However, this "unfortunate" becomes a concrete problem when dealing
with Objective-C, which /does/ allow applying its 'noescape' attribute
to a callback block marked 'nullable'. This is fine for /uses/ of
methods with such parameters, but prevents anyone from /overriding/
these methods.
This patch pokes a very narrow hole into the override checking to
accomodate this: if a declaration comes from Objective-C, and it has
an optional, non-escaping closure parameter, it's okay to override it
in Swift with an optional, escaping closure parameter. This isn't
strictly safe because a caller could be relying on the
non-escaping-ness, but we don't have anything better for now. (This
behavior will probably be deprecated in the future.)
(Some people have noted that the old 'noescape' type attribute in
Swift still works, albeit with a warning. That's not something people
should have to type, though---we want to remove it from the language,
as described in SE-0103.)
rdar://problem/32903155
Using the attribute in this position is a relic from the Swift 2
days, and fixing it required letting invalid code fall through to
Sema instead of being diagnosed in Parse proper. Treat 'var'
in this position like 'let' by simply offering to remove it
instead of extracting it into a separate variable.
This at least emits notes when someone overrides something but
gets the types a little wrong (more than just mismatched optionals,
as handled in d669d152).
Part of rdar://problem/26183575
In many places, we're interested in whether a type with archetypes *might be* a superclass of another type with the right bindings, particularly in the optimizer. Provide a separate Type::isBindableToSuperclassOf method that performs this check. Use it in the devirtualizer to fix rdar://problem/24993618. Using it might unblock other places where the optimizer is conservative, but we can fix those separately.
<rdar://problem/15975935> warning that you can use 'let' not 'var'
<rdar://problem/18876585> Compiler should warn me if I set a parameter as 'var' but never modify it
<rdar://problem/17224539> QoI: warn about unused variables
This uses a simple pass in MiscDiagnostics that walks the body of an
AbstractFunctionDecl. This means that it doesn't warn about unused properties (etc),
but it captures a vast majority of the cases.
It also does not warn about unused parameters (as a policy decision) because it is too noisy,
there are a variety of other refinements that could be done as well, thoughts welcome.
Swift SVN r28412
If you want to make the parameter and argument label the same in
places where you don't get the argument label for free (i.e., the
first parameter of a function or a parameter of a subscript),
double-up the identifier:
func translate(dx dx: Int, dy: Int) { }
Make this a warning with Fix-Its to ease migration. Part of
rdar://problem/17218256.
Swift SVN r27715
Most tests were using %swift or similar substitutions, which did not
include the target triple and SDK. The driver was defaulting to the
host OS. Thus, we could not run the tests when the standard library was
not built for OS X.
Swift SVN r24504
Also warn when the subclass returns 'T!' where the superclass returns 'T?'.
In both cases, allow silencing by wrapping the 'T!' in parentheses.
This is intended to provide migration help as Objective-C classes get
annotated for nullability. Because of that, the check is only run on @objc
classes, though it's not limited to classes that actually come from Objective-C
because of (a) deep subclass chains that may all need updating, and (b) ease
of testing.
<rdar://problem/17892184>
Swift SVN r21001
