When we specialize the decision matrix on a pattern, we have to start with the *first* preceding wildcard, not the last. Oops. While we're here, clean things up a bit by using Optional instead of magic integer values to track the first wildcard row. Fixes <rdar://problem/17272985>.
Swift SVN r19061
SILGen lowers this to unchecked_trivial_bit_cast or unchecked_ref_bit_cast based on the semantics of the input and output types, raising an unsupported error if one of the types are address-only.
Swift SVN r19058
unconditional_dynamic_cast_addr instruction.
Also, fix some major semantic problems with the
existing specialization of unconditional dynamic
casts by handling optional types and being much
more conservative about deciding that a cast is
infeasible.
This commit regresses specialization slightly by
failing to turn indirect dynamic casts into scalar
ones when possible; we can fix that easily enough
in a follow-up.
Swift SVN r19044
These types are needed by enough of the stack now that it makes sense to centralize their lookup and caching onto the AST context like other core types.
Swift SVN r19029
Add primitive type-checker rules for pointer arguments. An UnsafePointer argument accepts:
- an UnsafePointer value of matching element type, or of any type if the argument is UnsafePointer<Void>,
- an inout parameter of matching element type, or of any type if the argument is UnsafePointer<Void>, or
- an inout Array parameter of matching element type, or of any type if the argument is UnsafePointer<Void>.
A ConstUnsafePointer argument accepts:
- an UnsafePointer, ConstUnsafePointer, or AutoreleasingUnsafePointer value of matching element type, or of any type if the argument is ConstUnsafePointer<Void>,
- an inout parameter of matching element type, or of any type if the argument is ConstUnsafePointer<Void>, or
- an inout or non-inout Array parameter of matching element type, or of any type if the argument is ConstUnsafePointer<Void>.
An AutoreleasingUnsafePointer argument accepts:
- an AutoreleasingUnsafePointer value of matching element type, or
- an inout parameter of matching element type.
This disrupts some error messages in unrelated tests, which is tracked by <rdar://problem/17380520>.
Swift SVN r19008
not a struct wrapping an Optional.
Among other things, this means you can now pattern-match on
an IUO. It also makes it more convenient to build and destroy
them.
SILGen's type lowering should probably canonicalize one kind
of optional to the other so that we don't get silly abstraction
costs from conversion.
Swift SVN r18991
This means that we'll get deferred checking of array and dictionary
downcasts when writing "arr as Derived[]",
"(dict as? Dictionary<DerivedKey, DerivedValue>)!", etc, when the
collection can do so.
This is both a general optimization and also staging for
<rdar://problem/17319154>.
Swift SVN r18975
...in preparation for non-source locations, i.e. locations that don't come
frome source buffers.
No functionality change, but a fair bit of SourceManager API and idioms have
changed.
Swift SVN r18942
s/_dictionaryCheckedDownCast/_dictionaryDownCastConditional/g
s/_dictionaryBridgeFromObjectiveC/_dictionaryBridgeFromObjectiveCConditional/g
Swift SVN r18931
This is all goodness, and eliminates a major source of implicit conversions.
One thing this regresses on though, is that we now reject "x == nil" where
x is an option type and the element of the optional is not Equtatable. If
this is important, there are ways to enable this, but directly testing it as
a logic value is more straight-forward.
This does not include support for pattern matching against nil, that will be
a follow on patch.
Swift SVN r18918
We were emitting an extra retain and/or forgetting to release unowned references when semantically loading them, causing unowned references to almost always leak memory. Fixes <rdar://problem/16980445> and probably other bugs.
Swift SVN r18904
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
Apparently, despite being statically-allocated globals, they still inherit NSObject's reference counting. Oops. Retain a protocol value after forming a reference so, if we happen to release it later, we don't cause the Protocol object to try to free itself.
Swift SVN r18845
Mandatory-inlined (aka transparent functions) are still treated as if they
had the location and scope of the call site. <rdar://problem/14845844>
Support inline scopes once we have an optimizing SIL-based inliner
Patch by Adrian Prantl.
Swift SVN r18835
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
insert the values for variables into the SIL for
expressions correctly.
Instead of hijacking emitLValueForDecl() in
SILGenFunction, we now hook into
emitInitializationForVarDecl. That way we can
emit the proper value and just stick it into
VarLocs.
To support this, we also make two other changes:
- We suppress marking the variable uninitialized
in MarkPatternUninitialized::visitNamedPattern.
- We override DeclChecker in the type checker to
allow LLDB to construct let statements without
initializers.
Swift SVN r18676
literals, don't actually use the source information of the *function
definition* to generate these functions. Doing so leaks information about
source code into the binary, and these default argument generators are never
called anyway.
rdar://17054642
Swift SVN r18654
The CALayer brittleness in <rdar://problem/17014037> is worse than we thought—we can't r/r *at all* before super.init. Go through some contortions to ensure that, when doing direct stored property access in an initializer, we always base off of a +0 value. I tried fixing this in a more general and principled way using SGFContext::AllowPlusZero, but that introduced miscompiles we don't have the luxury of tracking down right now, so hack a more targeted fix that only affects class initializers.
Swift SVN r18635
CALayer and potentially other framework classes implement their own refcounting
schemes that assume [self retainCount] == 1 at initialization time, a guarantee
SILGen didn't attempt to meet until now. Set a flag in SILGenFunction while
doing initializer delegations to indicate that a 'self' reference can consume
the current 'self' binding, and reinitialize rather than reassign 'self' with
the result of the delegation if it was successfully consumed. Fixes
<rdar://problem/17014037>.
Swift SVN r18608
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
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
at the SIL level. Now, the referent type of a WeakStorageType is always
an optional type, instead of always being the underlying reference. This
allows us to represent both optional types. Before, both of these had the
same AST representation of WeakStorageType(T):
weak var x : T?
weak var x : T!
which doesn't work. Now we represent the optional type explicitly in the
AST and at SIL level. This also significantly simplifies a bunch of code
that was ripping off the optional type and resynthesizing it in other places,
and makes SILGen of weak pointers much more straight-forward by eliminating
the need for emitRefToOptional and emitOptionalToRef entirely (see the diffs
in test/SILGen/weak).
Weak pointers still have problems, but this is a big step forward.
Swift SVN r18312
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
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
If a source file contains the main class for its module, then implicitly emit a top_level_code that invokes UIApplicationMain with the name of the marked class.
Swift SVN r18088
This fixes a case where the Swift-variadic and C-varargs versions of
various initializers were superseding each other
<rdar://problem/16801456>.
It also uncovered some more cases where we weren't getting quite the
right semantics for factory-methods-as-initializers, which are also
fixed here.
Swift SVN r18010
