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
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
- 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
The bridging function takes the original value at +1, so it needs to be consumed so it isn't released in the caller. Fixes <rdar://problem/16877676>.
Swift SVN r17944
Generalize the bridging of AnyObject[] to NSArray into bridging T[] to
NSArray, following what we already have for dictionaries. Use some new
Foundation-level entry points for the bridging, which could use an
audit from someone who understands Array better than I do.
Part of <rdar://problem/16535097>.
Swift SVN r17869
for capture lists and add testcases for stuff that works.
Still more to come, weak pointers need work and one unowned pointer case doesn't work.
Swift SVN r17860
There were two problems here: emitRValueForDecl wasn't doing a semantic
conversion to an RValue when loading from let vardecls of reference storage
type, and we were trying to capture the rvalue type (not the storage type)
when forming the capture.
Swift SVN r17854
'unowned let' initializations don't drop their ReferenceStorageInitialization
transformation. This defines away another class of problems related to weak and
unowned pointers, and allows us to remove a hack added to paper over rdar://16681656.
Swift SVN r17846
Eliminate the duplicate half-broken bridging logic in emitClassConstructorAllocator by referencing foreign initializers through their foreign-to-native thunks, which SILGen knows how to emit already. Do the same thing for factory initializers by suppressing their normal allocating initializer codegen and just referencing the usual foreign-to-native thunk for them. This fixes <rdar://problem/16853205> because we get the ownership thunking right now.
Swift SVN r17840
This keeps us from prematurely releasing values before they're needed by the underlying initializer, which caused a crash if you tried to pass a Swift array into NSArray(objects:count:) via pointer bridging. <rdar://problem/16738050>
Swift SVN r17812
This mostly falls out from the metatype cast infrastructure, but we need to generalize some Sema and SILGen code to accept AnyMetatypeType. Concrete-to-existential metatypes will need more runtime checking that isn't implemented, so raise a 'not implemented' error on those for now.
Swift SVN r17798
This was an artifact of their long-dead C++-based implementations that was way past due to clean up. It's also a convenient workaround for <rdar://problem/16835447>, since we no longer have to look up constructor members for String at SILGen time and potentially lazily instantiate Clang-imported types during SILGen. This totally isn't a real solution to that problem, but it puts out the fire for now.
Swift SVN r17643
Subscript declarations were still encoding the names of index
variables in the subscript type, which unintentionally made them
keyword arguments. Bring subscript declarations into the modern day,
using compound names to encode the subscript argument names, which
provides consistency for the keyword-argument world
<rdar://problem/14462349>. Note that arguments in subscripts default
to not being keyword arguments, which seems like the right default.
We now get keyword arguments for subscripts, so one can overload
subscripts on the names of the indices, and distinguish at the call
site. Under -strict-keyword-arguments, we require strictness here as well.
The IRGen/IDE/SILGen test updates are because the mangling of common
subscripts changed from accidentally having keyword arguments to not
having keyword arguments.
Swift SVN r17393
There were a bunch of things broken here--it's amazing this ever appeared to work.
- Retain 'self' before partial_applying it to the method, so we don't overrelease it.
- Correctly lower the ownership conventions of the dynamic method against the SILDeclRef, so we don't overrelease arguments or over-over-release self, and we handle ObjC methods with weird conventions correctly.
- Thunk when there are bridging type differences between the partially-applied ObjC method and a Swift method, so we don't crash if the method takes NSStrings or other bridged types.
Add verifier checks that the result of 'dynamic_method' and BB arg of 'dynamic_method_br' actually match the method they're dispatching.
Swift SVN r17198
Make ObjC method partial applications go through a native-to-foreign thunk so that we properly handle bridging conversions in the resulting function value. Partial applications through dynamic lookup are still broken because they apparently go through a different path.
Swift SVN r17108
