Migrate the check for whether a given type is representable in
Objective-C, which is currently used to verify when @objc can be
inferred or verify that an explicitly-written @objc is well-formed,
from Sema into a set of queries on the Type within the AST library, so
it can be used in other parts of the compiler.
As part of this refactoring, clean up and improve a number of aspects
of this code:
* Unify the "trivially representable" and "representable" code paths
into a single code path that covers these cases. Clarify the
different levels of "representable" we have in both the code and
in comments.
* Distinguish between representation in C vs. representation in
Objective-C. While we aren't using this now, I'm anticipating it
being useful to allow exporting C interfaces via @_cdecl (or
similar).
* Eliminate the special cases for bridging String/Array/Dictionary/Set
with their Foundation counterparts; we now consult
_ObjectiveCBridgeable conformances exclusively to get this
information.
* Cache foreign-representation information on the ASTContext in a
manner that will let us more easily get the right answer across
different contexts while providing more sharing than the TypeChecker
version.
Annoyingly, this only seemed to fix a small class of error where we
were permitting Unsafe(Mutable)Pointer<T> to be representable in
Objective-C when T was representable but not trivially representable,
e.g., T=String or T=AnyObject.Type.
of providing contextual diagnostics (e.g. producing the warning in
Constraints/dynamic_lookup.swift). This drops a specific diagnostic about
force casting the result of as! which was added in the Swift 1.2 timeframe
to explain the change in cast semantics. Now that as! has been around for
a long time, it is more confusing than helpful.
Swift SVN r31887
Adjust our placement of RebindSelfInConstructorExpr to fall outside of
a force-value expression (!), allowing, e.g.,
self.init(somethingThatCanFail: x)!
and
super.init(somehtingThatCanFail: x)!
Start suggesting '!' when chaining/delegating to a failable
initializer from a non-failable one, in addition to suggesting that
the enclosing initializer become failable.
Note that DI cannot handle this yet, so this is only the Sema part of
rdar://problem/18497407.
Swift SVN r30219
var/let bindings to _ when they are never used, and use some values that
are only written. This is a testsuite cleanup, NFC. More to come.
Swift SVN r28406
Previously, we attempted to infer @objc-ness based on conformance, but
doing so is fraught with ordering dependencies, and just doesn't work
in the general case. Among other crimes, this allowed us to
retroactively mark a non-@objc method from an imported module as
@objc... even though nobody would ever then emit the @objc entry
points for it.
Fixes the rest of rdar://problem/18383574.
Swift SVN r24831
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
This makes sure we get the same checking for initializer delegation in
structs/enums as we do for classes, fixing rdar://problem/18458622.
Swift SVN r23128
This is useful when making an Objective-C class conform to a Swift
protocol. Note that we can only implement this safely for non-@objc
protocols, where we have a witnes function that can perform the
checked unwrapping.
Swift SVN r21782
