Require 'as' when converting from Objective-C type to native type (but
continue to allow implicit conversion from native to Objective-C). This
conversion constraint is called ExplicitConversion; all implicit
conversions are covered by the existing Conversion constraint. Update
standard library and tests to match.
Swift SVN r24496
Add the following functionality to the Swift compiler:
* covariant subtyping of Set
* upcasting, downcasting of Set
* automatic bridging between Set and NSSet, including
* NSSet params/return values in ObjC are imported as Set<NSObject>
* Set params/return values in Swift are visible to ObjC as NSSet
<rdar://problem/18853078> Implement Set<T> up and downcasting
Swift SVN r23751
Specifically, it's not when
- the conformance is being used within a function body (test included)
- the conformance is being used for or within a private type (test included)
- the conformance is being used to generate a diagnostic string
We're still a bit imprecise in some places (checking ObjC bridging), but
in general this means less of an issue for checking literals.
Swift SVN r23700
This is the start of distinguishing qualified lookups within function bodies
from qualified lookups in a function signature. Both of these use the
function itself as the decl context, so we need to distinguish them manually.
This particular commit doesn't change much because expressions don't often
use TypeMember constraints. But it does help with for-loops!
Swift SVN r23484
This prevented metatype casts and other kinds of cast that could be allowed from being accepted. Keep the subtype constraint if we're casting between generic class types with open type variables, because it can provide context to deduce type arguments in this case. This causes a regression in test/Constraints/members.swift that uses 'as' as a coercion, but we're planning to disambiguate cast/coercion syntax soon, which should fix that issue.
Swift SVN r23303
There's no reason to constrain casting to or from a generic or existential, since their types may be dynamically equal even if we don't have static knowledge that they are. First step here is to remove the subtype constraint we used to introduce for existential-to-concrete casts.
Swift SVN r23148
We'd like to kill this enum off eventually, since the runtime inevitably needs to be able to handle arbitrary checked casts in opaque contexts, and SILGen and IRGen can deal with picking more optimal runtime entry points for specific casts. Only the container bridging kinds are still depended on anymore, and even those ought to eventually be handlable by the runtime in 'x as T' situations. NFC yet.
Swift SVN r23127
This patch adds diagnostics for initializers that are potentially unavailable.
It does not treat such initializers as optionals, even when
EnableExperimentalUnavailableAsOptional is true -- there is some tricky
interaction with failable initializers that still needs to be worked out.
Swift SVN r22548
This commit modifies Sema to add type checking for potentially unavailable
method references. We now record the reason for method unavailability when
recording a potential overload choice during member constraint simplification
and either diagnose or lift to an optional type during CSApply. This commit also
generalizes UnavailableToOptionalExpr to take an arbitrary subexpression.
This commit does not address potentially unavailable properties, initializers,
or dynamic member references.
Swift SVN r22508
In preparation for the switch to llvm::Optional, which is constructible from
the same dummy llvm::NoneType as llvm::ArrayRef, making the assignment
ambiguous.
Swift SVN r22473
This commit also factors out some common checking and diagnostic code; it
additionally moves diagnostic emission for unavailable references from CSGen to
CSApply.
Swift SVN r22447
properties.
The main design change here is that, rather than having
purportedly orthogonal storage kinds and has-addressor
bits, I've merged them into an exhaustive enum of the
possibilities. I've also split the observing storage kind
into stored-observing and inherited-observing cases, which
is possible to do in the parser because the latter are
always marked 'override' and the former aren't. This
should lead to much better consideration for inheriting
observers, which were otherwise very easy to forget about.
It also gives us much better recovery when override checking
fails before we can identify the overridden declaration;
previously, we would end up spuriously considering the
override to be a stored property despite the user's
clearly expressed intent.
Swift SVN r22381
This commit adds tracking of the reason a declaration reference is potentially
unavailable to the UnavailableToOptionalExpr AST node and to OverloadChoice. We
will use this reason during SILGen to emit the appropriate run-time check and
during typechecking to provide more helpful diagnostics.
To keep OverloadChoice as small as possible, we encode the reason as an index
into a vector of reasons stored in a given instance of ConstraintSystem (this is
the same approach that Fix takes).
This commit adds Sema/OverloadChoice.cpp (for the parts of OverloadChoice that
now rely on ConstraintSystem) and AST/Availability.h (to bring in
availability-related structures without TypeRefinementContext).
Swift SVN r22377
This patch adds the ability (-enable-experimental-unavailable-as-optional) to
treat potentially unavailable declarations as if they had optional types. For
the moment, this is only implemented for global variables.
The high-level approach is to (1) record the potential unavailability of a
declaration reference in the overload choice during constraint generation; (2)
treat the declaration as if it had an optional type during overload resolution
(this is similar to how optional protocol members are treated); and (3) add an
implicit conversion (UnavailableToOptionalExpr) during constraint application
to represent the run-time availability check and optional injection.
This patch does not implement SILGen for UnavailableToOptionalExpr.
Swift SVN r22245
When performing name lookup for a declaration that is being called,
use the argument labels at the call site to filter out those
declarations with incompatible argument labels.
Swift SVN r22176
Calls to fromRaw are replaced with uses of the new failable
initializer init(rawValue:). Similarly, calls to toRaw are replaced
with uses of the rawValue property. Fixes rdar://problem/18357647.
Swift SVN r22164
When simplifying a checked-cast constraint, look through type
variables after unwrapping optionals or looking through
metatypes. Otherwise, we won't find obvious solutions. Fixes
rdar://problem/18330319.
Swift SVN r22086
We don't properly open up the existential to make this work, which
leads to an IRGen crash. Reject the uses of generics that would cause
such a crash rdar://problem/17491663.
Swift SVN r21946
Locators that refer to opened type parameters now carry information
about the source location where we needed to open the type, so that
(for example) we can trace an opened type parameter back to the
location it was opened. As part of this, eliminate the "rootExpr"
fallback, because we're threading constraint locators everywhere.
This is infrastructural, and should be NFC.
Swift SVN r21919
Eliminate the implicit conversion from NSNumber to one of its bridged
value types (Int, Float, Double, Bool, etc.). One can use "as" to
perform the conversion instead. This eliminates a class of
accepts-dubious that involve lossy conversions from NSNumber to Int.
Our eventual arc is to eliminate all of these conversions. This is a
small, high-value step along that path rdar://problem/18269449.
Swift SVN r21879
This is another instance where we choose a favored constraint that
only type checks because we're bridging through NSNumber, causing
awful problems. Fixes rdar://problem/17962491.
Swift SVN r21445
Introduce an attribute that describes when a given CF type is
toll-free-bridged to an Objective-C class, and which class that
is. Use that information in the type checker to provide the CF <->
Objective-C toll-free-bridged conversions directly, rather than using
the user-defined conversion machinery.
Swift SVN r21376
This is the semantic change we need to eliminate ambiguities when
introducing the new ?? overload. There is a minor regression here with
curried method references, which is covered by <rdar://problem/18006008>.
Swift SVN r21173
We now provide fixits for if-expressions, point out the actual conditional expression (as opposed to the surrounding expression),
support unary '!' applications and avoid printing type variables in the diagnostic.
Swift SVN r20992
A checked cast such as "x as String" or "x as? [String]", where x is of
class or Objective-C existential type, is now handled as a normal
checked cast rather than a Sema-generated call to the corresponding
witness. This eliminates a pile of hairy code from constraint
application and takes a step toward <rdar://problem/17408934>.
The part of the switch_objc.swift test I removed wasn't testing
anything useful; that's what <rdar://problem/17408934> is about.
Swift SVN r20970
Modify TypeBase::getRValueType to structurally convert lvalues embedded in tuple and paren types. Inside the constraint solver, coerce types to rvalues based on the structural 'isLValueType' test rather than shallow 'is<LValueType>' checking. Fixes <rdar://problem/17507421>, but exposes an issue with call argument matching and lvalues <rdar://problem/17786730>.
Swift SVN r20442
I'll reuse the EnableOptionalLValues option to stage in work on lvalue support for '?' and AnyObject lookup, but remove the conditionals on '!'.
Swift SVN r20270
