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
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
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
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
When generating constraints for an 'as' expression, consider the
possibility that the code is supposed to be 'as!' instead of 'as'. Emit
the appropriate fixit if that branch of the disjunction is chosen by the
constraint solver.
This is a more comprehensive fix for <rdar://problem/19499340> than the
one in r24815.
Swift SVN r24872
- Closures that are comprised of only a single return statement are now considered to be "single expression" closures. (rdar://problem/17550847)
- Unannotated single expression closures with non-void return types can now be used in void contexts. (rdar://problem/17228969)
- Situations where a multi-statement closure's type could not be inferred because of the lack of a return-type annotation are now properly diagnosed. (rdar://problem/17212107)
I also encountered a number of crashers along the way, which should now be fixed.
Swift SVN r24817
Aside from tidying things up, doing this results in some significant benefits:
- Allows for global constraint ordering optimizations over a given expression, not just on a peephole basis.
- Eliminates a set of order-dependent bugs in the solver that have been dogging us for a while. (rdar://problem/19459079)
- Brings another set of tyvar-to-tyvar solving problems out of the realm of the exponential. (rdar://problem/19005271)
- Opens up the possibility of optimizing constraints during later solving phases - not just while generating them.
Swift SVN r24693
Also, these changes fix the performance regressions that were introduced as a result of September's convertible/init requirement modifications, and allow us to roll back the associated workarounds that were added to the Adventure sample (rdar://problem/18942100).
Swift SVN r24520
- Addresses many common user-reported "expression too complex" bugs, including rdar://problem/18876786.
- Shaves up to 10% off of the total time to run our unit tests. (Unscientifically measured on my iMac: 427.46s before, 385.17s after.)
Swift SVN r24514
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
