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
Rather than just saying "'Foo' is not constructible with '()'", say
"'Foo' cannot be constructed because it has no accessible initializers",
which would help framework authors realize what they did wrong.
<rdar://problem/17717714>
Swift SVN r20232
Create a new "OptionalObject" constraint kind in the solver that relates an optional type to its payload type, preserving lvalue-ness, and use it to model ForceValueExpr under the optional-lvalues regime.
Swift SVN r20140
Previously, bridged value types and their corresponding Objective-C
classes allow inter-conversion via a number of user-defined conversion
functions in the Foundation module. Instead, make this a general
feature of the type checker so we can reason about it more
directly. Fixes <rdar://problem/16956098> and
<rdar://problem/17134986>, and eliminates 11 (half) of the
__conversion functions from the standard library and overlays.
A few notes:
- The XCTest changes are because a String can no longer directly
conform to CVarArg: this is a Good Thing (TM), because it should be
ambiguous: did you mean to pass it as an NSString or a C string?
- The Objective-C representations for the bridged collections are
hard-coded in the type checker. This is unfortunate and can be
remedied by adding another associated type to the
_BridgedToObjectiveC protocol.
Swift SVN r19618
These methods all act on the desugared type, so the result would always be
false/null.
Also removes a few mistaken uses of getAs caught by this change.
Swift SVN r19585
- Change the parser to accept "objc" without an @ sign as a contextual
keyword, including the dance to handle the general parenthesized case.
- Update all comments to refer to "objc" instead of "@objc".
- Update all diagnostics accordingly.
- Update all tests that fail due to the diagnostics change.
- Switch the stdlib to use the new syntax.
This does not switch all tests to use the new syntax, nor does it warn about
the old syntax yet. That will be forthcoming. Also, this needs a bit of
refactoring, which will be coming up.
Swift SVN r19555
If the lookup was resolved by optional unwrapping, unwrap the metatype when we apply the solution so we don't try to create an invalid metatype conversion from T?.Type to T.Type. Fixes <rdar://problem/17542185>.
Swift SVN r19500
When we see a '.member' expression in optional context, look for the member in the optional's object type if it isn't found in Optional itself. <rdar://problem/16125392>
Swift SVN r19469
Allow a String value to be implicitly converted to ConstUnsafePointer<{UInt8,Int8,Void}> by string-to-pointer conversion, when enabled by a staging flag.
Swift SVN r19366
JoeP helped tweak things to ensure that pointer conversions are still
considered, but we no longer need the disjunction on InOutExprs to accommodate
user-defined inout conversions.
This causes some regressions in error reporting:
<rdar://problem/17489983> inout type mismatches complain about '@lvalue inout T'
<rdar://problem/17489894> inout not rejected as operand to assignment operator
Swift SVN r19306
We still don't want 'array1 == array2' to accidentally work via pointer comparison. However, we still admit pointer conversions when an inout is involved. 'pointer == &x' is desirable, and more importantly, explicit about what the user wants.
Swift SVN r19271
