Emit a warning when the developer uses an API that has been marked deprecated with an
availability attribute. Following the Clang behavior, we will only warn if the API is
deprecated on all deployment targets. For example, if an API is deprecated as of
OS X 10.11 but the minimum deployment target is 10.10 then no warning will be emitted.
rdar://problem/17406050
Swift SVN r25288
For @objc enums, raw values determine the representation values, so we have
to compute them eagerly in order for switch statements to work. Similarly,
if the enum is broken, we have to /fail/ eagerly so that we don't fall down
later on in IRGen.
rdar://problem/19775284
Swift SVN r25282
This seems to already be working for variables in trunk, so it's just
functions that need the fix. (I'm not sure why the variables are emitting
the error twice, but I'm not going to spend time on that right now.)
rdar://problem/19715729
Swift SVN r25276
Previously, we were using the Objective-C names to help determine
whether a declaration is an override or not. This is broken, because
we should determine overrides based on the Swift rules for
overriding, then (later) check that the Objective-C runtime will see
the same override behavior that the Swift runtime does. Address this
problem, both by taking the Objective-C selector out of the equation
when matching overrides (except for diagnostic purposes) and by
performing better validation of the Objective-C names for the
overriding vs. overridden methods/properties.
The motivating case here (from rdar://problem/18998564) is an
Objective-C initializer:
-(instancetype)initString:(NSString *)string;
When trying to override this in a Swift subclass, one naturally
writes:
override init(string: String)
which implicitly has the selector initWithString:. We ended up in an
unfortunate place where we rejected the override (because the
selectors didn't match) with a crummy diagnostic, but omitting the
"override" would result in a different conflict with the superclass.
Now, we'll treat this as an override and complain that one needs to
rename the method by adding "@objc(initString:)" (with a Fix-It, of
course). This fixes rdar://problem/18998564, but it is not ideal: the
complete solution (covered by rdar://problem/19812955) involves
reworking the dance between override and @objc so that we compute
'override' first (ignoring @objc-ness entirely), and let the
@objc'ness of the overridden declaration both imply @objc for the
overriding declaration and implicitly fix the selector. However, such
a change is too risky right now, hence the radar clone.
Swift SVN r25243
This is a "noescape leak" caused by implicit constructor synthesis, and not rejecting the
invalid code that is synthesized. There isn't a good way to synthesize an implicit memberwise
constructor for a structure with an @autoclosure property, we just surpress it.
It would be great to just disallow autoclosure on properties entirely. The only really popular
usecase I know of is for breaking cycles in enums, maybe we should just limit the autoclosure attribute
to enums specifically.
Swift SVN r25231
Remove the logic that allowed an extension to provide an Objective-C
method that was already declared in the class itself, relying on the
existing Objective-C method redeclaration logic to detect such
conflicts. Fixes rdar://problem/17687082.
Swift SVN r25175
"self." is required whenever it causes a potentially escaping closure to
capture 'self'. This happens not just in plain ClosureExprs, but in local
functions as well. In addition, even no-escape ClosureExprs can require
self to be captured in a /parent/ closure, which may be potentially-escaping.
Swift SVN r25173
If appending 'as T' to an expression in a fixit, also suggest
parentheses around the resulting expression if it would otherwise be
parsed incorrectly.
Swift SVN r25168
Only create trivial accessors if the actual VarDecl is @objc,
explicitly or implicitly, not the class.
Also, replicate the PrintAsObjC test into classes_objc_generics since
"classes" isn't run on compilers that support Objective-C generics, and
fix the expectations.
Swift SVN r25162
Expose static stored properties in @objc classes as trivial class
methods.
static let i: T => +(T)i
static var i: T => +(T)i and +(void)setI:
static var k T { get set } => No change.
Fixes rdar://problem/19784053
Swift SVN r25152
This post-hoc diagnostic replaces r24915, r25045, and r25054 by doing a
very basic check for representation incompatibility between two types.
More cases can be added as necessary.
rdar://problem/19600325, again.
Swift SVN r25117
John pointed out that messing with the type checker's notion of "subtype"
is a bad idea. Instead, we should just have a separate check for ABI
compatibility...and eventually (rdar://problem/19517003) just insert the
appropriate thunks rather than forcing the user to perform the conversion.
I'm leaving all the tests as they are because I'm adding a post-type-checking
diagnostic in the next commit, and that should pass all the same tests.
Part of rdar://problem/19600325
Swift SVN r25116
Penalize solutions that involve 'as' -> 'as!' changes by recording a Fix
when simplifying the corresponding checked-cast constraint.
<rdar://problem/19724719> Type checker thinks "(optionalNSString ?? nonoptionalNSString) as String" is a forced cast
Swift SVN r25061
This re-applies r24987, reverted in r24990, with a fix for a spuriously-
introduced error: don't use a favored constraint in a disjunction to avoid
applying a fix. (Why not? Because favoring bubbles up, i.e. the
/disjunction/ becomes favored even if the particular branch is eventually
rejected.) This doesn't seem to affect the outcome, though: the other
branch of the disjunction doesn't seem to be tried anyway.
Finishes rdar://problem/19600325
Swift SVN r25054
let x: Int? = 4 as Int // okay
let f: (Int) -> Void = { (x: Int?) -> Void in println(x) } // error!
As part of this, remove an invalid "protection" of value-to-optional
conversions that involve T? -> T??. Unfortunately, this results in an
ambiguity in the following code:
var z: Int?
z = z ?? 42
Both of our overloads for ?? here require one value-to-optional conversion,
and the overload preference isn't conclusive. (Turns out (T?, T) and
(U?, U?) can be unified as T=U or as T=U?.) The best thing to do would be
to take our solved T=Int binding into account, but the type checker isn't
set up to do that at the moment.
After talking to JoeP, I ended up just hardcoding a preference against
the (T?, T?) -> T? overload of ??. This is only acceptable because both
overloads have the same result, and I'll be filing another Radar to
remove this hack in the future.
Part of rdar://problem/19600325
Swift SVN r25045
I wasn't able to tickle this bug with an actual test case, perhaps due
to lack of imagination, but I'd rather fix it in bugsentia than debug
it later.
Swift SVN r24999
Don't emit multiple diagnostics for the same destination type -
this makes diagnostics less noisy where there are multiple overloads
with the same type.
Also, move the check for multiple overloads into
diagnoseFailureForCallExpr.
Swift SVN r24993
And even if we don't suggest wrapping in a closure (say, because there's
already a closure involved), emit a more relevant diagnostic anyway.
(Wordsmithing welcome.)
Wrapping a function value in a closure essentially explicitly inserts a
conversion thunk that we should eventually be able to implicitly insert;
that's rdar://problem/19517003.
Part of rdar://problem/19600325
Swift SVN r24987
When threading a @noescape, @noreturn, or @autoclosure parameter through
to a function that doesn't expect one of those attributes, multiple
overload matches may cause the diagnostic to be dropped on the floor,
causing a crash in AST verification. If there is more than one failure
recorded for these attribute mismatches, don't fall back to the
contextual type diagnostics.
Fixes crash: rdar://problem/19704523
Swift SVN r24974
For example, we used to have an implicit conversion from NSString to
String, but it was removed. Provide a Fix-It that suggests "as!
String". Fixes <rdar://problem/19551164>.
Swift SVN r24948
When comparing a requirement to a witness for @objc protocols, strip
optionality out of the types and keep track of the optionality
differences separately. When we have actually matched a witness,
diagnose any unsafe (via an error) or ill-advised (via a warning)
differences, providing Fix-Its to update the optionality.
This change addresses a usable problem introduced by the fix to
rdar://problem/18383574: witnesses for optional requirements of @objc
protocols could previously have completely wrong optionality, and we
would "allow" it by not actually matching the witness to the
requirement. Then it would happen to work at runtime because it's
@objc. Now, we match those witnesses and diagnose issues, with Fix-Its
to clean up the user's code.
Addresses rdar://problem/19656106.
Swift SVN r24939
The materializeForSet accessor for a `dynamic` property needs to dynamically invoke the getter and setter of the property in order to allow for runtime modification, so it doesn't need to be dynamically dispatched itself. If the property came from an imported ObjC class, then we can't dynamically dispatch it without polluting the selector namespace. Introduce a new 'ForcedStaticDispatch' bit and set it in order to force `dynamic` materializeForSet accessors to be statically dispatched. (They can't be `final` because it's legal to override a dynamic property.) If the property came from ObjC, register materializeForSet as an external declaration so it gets generated by SIL. Fixes rdar://problem/18706056.
Swift SVN r24930
These haven't ever been safe in Swift's development because they require
generating thunks, and we currently don't do that. However, we were letting
existential conversions slip through the cracks because we consider them
subtypes, so that /metatype/ conversions work correctly. To be concrete:
"let _: Any.Type = Int.self" is okay.
"let _: (Int) -> Void = { (_: Any) -> Void in return }" is not.
We should implement this some day; that's rdar://problem/19517003.
This produces some lousy error messages, which I intend to fix soon.
Part of rdar://problem/19600325
Swift SVN r24915
Previously, trailing closures would try to match the first parameter
of (possibly optional) function type that didn't seem to have an
argument already, but in practice this broke when there were
parameters with default arguments before the function parameter.
The new rule is far simpler: a trailing closure matches the last
parameter. Fixes rdar://problem/17965209.
Swift SVN r24898
Semantically, a dynamic property must always be dispatched in case it gets replaced at runtime, and an @NSManaged property may not have static accessors at all. Use ordinary access to the computed property accessors in materializeForSet when a property is dynamic or ObjC-originated. More rdar://problem/18706056.
There's still a problem--we try to vtable-dispatch materializeForSet, which is redundant for native classes, but impossible for imported ObjC classes. We should suppress this, but trying to make materializeForSet "final" breaks subclassing if the property is overridden.
This time, update test/SILGen/objc_properties.swift to avoid a false negative test failure.
Swift SVN r24888
