* Lift NormalProtocolConformance::hasTypeWitness() to
ProtocolConformance. This method can be used to determine whether a
potentially invalid conformance has a particular type witness.
* ProtocolConformance::getWitness() may return nullptr if the witness
does not exist.
* In TypeChecker::getWitnessType(), don't complain that a builtin
protocol is broken if it's the conformance that's broken.
* ConformanceChecker should only emit diagnostics from within calls to
checkConformance().
* TypeChecker::conformsToProtocol() now returns true if the type
has a declared conformance to the protocol, regardless of whether the
conformance is valid. Clients must check the validity of the
ProtocolConformance themselves if necessary.
<rdar://problem/19495341> Can't upcast to parent types of type constraints without forcing
Swift SVN r25326
The presence of stub initializers can effect the Objective-C
initializer overriding diagnostics. In multi-file situations, we were
getting spurious diagnostics because stub initializers were not
present outside of the file in which a particular class was
defined. Fixes rdar://problem/19794036.
Swift SVN r25323
Since a function pointer doesn't carry any context, we can only form a C function pointer from a static reference to a global function or a context-free local function or closure. (Or maybe a static function applied to its metatype, but that's not handled here yet.) As a placeholder for a to-be-bikeshedded surface syntax, let the existing @cc(cdecl) attribute appear in source text when the -enable-c-function-pointers frontend flag is passed.
Swift SVN r25308
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
