Semantically, these expressions handle the same thing: an upcast of a
collection when the underlying element types of the source are
subtypes of or can be bridged to subtypes of the destination. This
reduces some branching in the type checker and eliminates duplication
in SILGen.
Swift SVN r18865
Allow class metatypes (including class-constrained existential metatypes) to be treated as subtypes of AnyObject, and single-@objc protocol metatypes to be treated as subtypes of the Protocol class from objc. No codegen support yet, so this is hidden behind a frontend flag for now.
Swift SVN r18810
Tweak the AST representation and type-checking of default arguments to preserve a full ConcreteDeclRef with substitutions to the owner of the default arguments. In SILGen, emit default argument generators with the same genericity as the original function.
Swift SVN r18760
We removed this feature when we changed casting syntax, but left it in
the type checker to help migrate code via a Fix-It. We no longer need
it.
Swift SVN r18729
Previously, we were only changing whether the object was of the right
type, and not performing a deep check that (for example) the
underlying array contained NSStrings for an "is String[]". Fixes the
rest of <rdar://problem/16972956>.
Swift SVN r18728
Rather than only allowing downcasting from AnyObject, allow it for any
class or Objective-C existential type, e.g., "NSArray() as
Int[]". While here, reduce our reliance on implicit conversions when
checking bridging. This is most of <rdar://problem/16972956>, but 'is'
still doesn't work properly in these cases.
Swift SVN r18693
There's a bit of a reshuffle of the ExplicitCastExpr subclasses:
- The existing ConditionalCheckedCastExpr expression node now represents
"as?".
- A new ForcedCheckedCastExpr node represents "as" when it is a
downcast.
- CoerceExpr represents "as" when it is a coercion.
- A new UnresolvedCheckedCastExpr node describes "as" before it has
been type-checked down to ForcedCheckedCastExpr or CoerceExpr. This
wasn't a strictly necessary change, but it helps us detangle what's
going on.
There are a few new diagnostics to help users avoid getting bitten by
as/as? mistakes:
- Custom errors when a forced downcast (as) is used as the operand
of postfix '!' or '?', with Fix-Its to remove the '!' or make the
downcast conditional (with as?), respectively.
- A warning when a forced downcast is injected into an optional,
with a suggestion to use a conditional downcast.
- A new error when the postfix '!' is used for a contextual
downcast, with a Fix-It to replace it with "as T" with the
contextual type T.
Lots of test updates, none of which felt like regressions. The new
tests are in test/expr/cast/optionals.swift.
Addresses <rdar://problem/17000058>
Swift SVN r18556
Previously, we were relying on user-defined conversions to perform the
final bridging from the Objective-C class type (e.g., NSString) to its
Swift value type (String). That works for NSString <-> String, but not
for arbitrary arrays. Use the bridgeFromObjectiveC() witness instead,
so we can handle:
let obj: AnyObject = ...
let strArr: String[] = obj!
Fixes <rdar://problem/16952771>.
Swift SVN r18422
This allows us to cast an AnyObject (or optional thereof) down to a
specific array, e.g.,
if let strArr = obj as String[] { ... }
Addresses most of <rdar://problem/16952771>.
Swift SVN r18397
We can't actually make the "is" check any more efficient for arrays
anyway, and re-using the checked casting code makes "is" work properly
for arrays. More of <rdar://problem/16952771>.
Swift SVN r18395
The latter has some brilliant code to deal with differing levels of
optionality, binding inner optionals etc. Unifying these code paths
makes array downcasts work when the source has (possibly
implicitly-wrapped) optional type, e.g.,
var arrImplicitOpt: AnyObject[]! = nsarr
if let strArr = arrImplicitOpt as String[] {
println("String array contains \(strArr)")
} else {
println("Not a string array")
}
Another part of <rdar://problem/16952771> and the array-bridging story.
Swift SVN r18392
Array downcast is an explicit cast written "x as U[]", not an implicit
conversion, so make it a subclass of ExplicitCastExpr. The only
effective change here is that we retain the location of the "as" and
the type as written in the AST. No semantic change.
Swift SVN r18391
checked cast expression.
We don't actually *use* that path for anything right now,
because we basically re-check the cast from scratch after
constraint application. This is nonetheless necessary to
avoid collisions with constraints which might be located
on the result, such as would arise in an initialization
context.
In particular, this patch fixes a crash arising when both
the operand and the result of a coercion require a
user-defined conversion. Test to follow.
Swift SVN r18386
The "is" expression itself isn't really able to cope with optionals
well itself, so in the hard cases we'll defer to a conditional checked
cast and then check whether the resulting optional is non-empty. Fixes
the rest of <rdar://problem/16953860>.
Swift SVN r18361
Checked casting handles multiple levels of optionality properly
already, and does so by binding rather than forcing. Fixes the
immediate issue in <rdar://problem/16953860>.
Swift SVN r18351
This allows us to cast "through" a bridged class type in an "as" case,
e.g.,
if let str = obj as String { ... }
where obj is an AnyObject (or optional/implicitly unwrapped optional
thereof). In such cases, we perform a checked cast to the
corresponding class type (NSString in this case) and then convert the
(optional!) result down to the value type.
Addresses the main part of <rdar://problem/15288553>, but we still
have trouble with "is" with optionals, and the #if false'd out
testcase incorrectly fails due to <rdar://problem/16953860>.
Swift SVN r18347
upcasts."
Reinstate "Restrict the array-bridged conversion to non-verbatim
bridging."
Reinstate "[stdlib] Fix T[].bridgeFromObjectiveC"
Reinstate "[stdlib] Fix T[].bridgeFromObjectiveC"
Reinstate "[stdlib] Move _arrayBridgedDownCast to Foundation"
Reinstate "Replace "can" with "cannot" in a message."
Reinstate "Implement support for non-verbatim T[] -> AnyObject[]
upcasts."
This reinstates commit r18291.
This reinstates commit r18290.
This reinstates commit r18288.
This reinstates commit r18287.
This reinstates commit r18286.
This reinstates commit r18293.
This reinstates commit r18283.
John fixed the issue in r18294.
Swift SVN r18299
Revert "Restrict the array-bridged conversion to non-verbatim bridging."
Revert "[stdlib] Fix T[].bridgeFromObjectiveC"
Revert "[stdlib] Fix T[].bridgeFromObjectiveC"
Revert "[stdlib] Move _arrayBridgedDownCast to Foundation"
Revert "Replace "can" with "cannot" in a message."
Revert "Implement support for non-verbatim T[] -> AnyObject[] upcasts."
This reverts commit r18291.
This reverts commit r18290.
This reverts commit r18288.
This reverts commit r18287.
This reverts commit r18286.
This reverts commit r18293.
This reverts commit r18283.
Sorry for the number of reverts, but I needed to do this many to get a clean
revert to r18283.
Swift SVN r18296
Previously, we were relying on overly-general subtyping to determine
when we could perform an array upcast, which pushed some non-verbatim
bridging through that path. Instead, restrict array upcasts to classes
and ObjC existentials, and use bridging casts for the other cases.
Swift SVN r18291
One of my recent type-checker changes starting passing all array
upcasts, including "bridged" ones like String[] -> AnyObject[],
through the library entry point _arrayUpCast, which is only meant for
class/ObjC existential types that are bridged verbatim.
Fixes part of <rdar://problem/16952238>; more cleanup to follow.
Swift SVN r18283
This is a better solution to <rdar://problem/16899681> because the
runtime magic is limited to implementing the witnesses of this
conformance.
The type checker fixes are because we can end up using unchecked
optionals in more places, via bridging, than we could before.
Swift SVN r18120
String interpolation invokes convertFromStringInterpolationSegment() function
now. There is no need to add extensions to String to allow custom types to
participate in string interpolation. Just implementing Printable will do the
right thing.
Swift SVN r18104
- Continue adding support for checked downcasts of array types (rdar://problem/16535104)
- Fix non-bridged array conversions post-r17868
- Fix rdar://problem/16773693
- Add tests for NSArray coercions to and from Array<T>
Swift SVN r17957
Use protocol conformance checks whenever we want to determine whether
a value type is bridged to an Objective-C class, which is simpler and
more robust. Clean up some of the type checker code around bridging,
using TypeBase::isEqual() to compare types and looking through type
sugar more regularly.
As part of this, move Array's conformance to
_ConditionallyBridgedToObjectiveC into the Foundation overlay. This
lets us use NSArray as the bridged type (which is clearer than using
CocoaArray), and follows what we're doing for dictionary bridging.
As part of this, move Array's bridged-to-
Swift SVN r17868
While this should be a pointless performance tweak along a path where
we don't care about performance, it actually matters because we
occasionally end up copying SmallStrings or std::strings, then taking
StringRefs to the copies and holding on to them. This was manifesting
as occasional corruption in keyword-argument diagnostics.
Swift SVN r17811
- Mine conjunction constraints for constraint failure data. (rdar://problem/16833763)
- Rather than crash, add a diagnostic to signify a missing user constraint. (rdar://problem/16747055) I don't have a deterministic repro for this to include as a test, but users hit it from time to time, I'd like to address this issue holistically, and we're hoping that the new diagnostic will help us collect isolated repros.
- As promised, remove the temporary "compiler_submit_version" build configuration predicate in time for WWDC. (rdar://problem/16380797)
Swift SVN r17705
Introduce a new locator kind for argument/parameter comparisons that
tracks both the argument and the parameter, which we will eventually
use in diagnostics more regularly. For now, this helps us smooth over
scalar-to-tuple/tuple-to-tuple/tuple-to-scalar nonsense when dealing
with calls.
Fix a pile of fallout from this change.
Swift SVN r17648
