This is needed if we compile StdlibUnittest with -sil-serialize-all
So far I added the imports only in files which needed them. But this may change, depending on the optimizer (inlining).
Adding them in all files doesn't harm and avoids confusion if someone makes an unrelated change which would result in such a linker error.
Most of this is in updating the standard library, SDK overlays, and
piles of test cases to use the new names. No surprises here, although
this shows us some potential heuristic tweaks.
There is one substantive compiler change that needs to be factored out
involving synthesizing calls to copyWithZone()/copy(zone:). Aside from
that, there are four failing tests:
Swift :: ClangModules/objc_parse.swift
Swift :: Interpreter/SDK/Foundation_test.swift
Swift :: Interpreter/SDK/archiving_generic_swift_class.swift
Swift :: Interpreter/SDK/objc_currying.swift
due to two independent remaining compiler bugs:
* We're not getting partial ordering between NSCoder's
encode(AnyObject, forKey: String) and NSKeyedArchiver's version of
that method, and
* Dynamic lookup (into AnyObject) doesn't know how to find the new
names. We need the Swift name lookup tables enabled to address this.
For Dictionary, that's a (KeyType, ValueType) pair. For Set, that's just
the set element type. This is more consistent with the removeAtIndex on
RangeReplaceableCollectionType (which Dictionary and Set don't conform to).
rdar://problem/20299881
Swift SVN r30696
These types are leftovers from the early pre-1.0 times when Int and UInt
were always 64-bit on all platforms. They serve no useful purpose
today. Int and UInt are defined to be word-sized and should be used
instead.
rdar://18693488
Swift SVN r30564
Due to the fact that AnyClass is not Hashable, and that currently
NSKeyedArchiver/Unarchiver work with NSObject-derived, NSCoding
compliant classes, we are marking the decodeObjectOfClasses API refined
for Swift in our objc header and providing the desired overlay in our
overlay as shown below.
Arrays were also considered (for both API), but the underlying
implementation is entirely set-based, and using Arrays in Swift vs Sets
in objective C felt like too far a deviation.
Patch by Michael LeHew Jr.
Changes to the Dictionary test are caused by bumping the Fonudation API
epoch and taking in a fix in the types used in an NSDictionary
initializer.
rdar://21486551
Swift SVN r30297
includes a number of QoI things to help people write the correct code. I will commit
the testcase for it as the next patch.
The bulk of this patch is moving the stdlib, testsuite and validation testsuite to
the new syntax. I moved a few uses of "as" patterns back to as? expressions in the
stdlib as well.
Swift SVN r27959
Use -[NSDictionary copyWithZone:] instead.
CFDictionaryCreateCopy() is buggy in OSes that ship today: it copies the
dictionary unconditionally, even if it is immutable, resulting in O(n)
bridging.
Swift SVN r27732
requires pushing the types out. The only interesting one is this diff:
- var (e,f,g:(),h) = MRV()
+ var (e,f,g,h) : (Int, Float, (), Double) = MRV()
... where the type annotation is required to silence the warning about "void type
may be unexpected". This seems perfectly reasonable to me.
Swift SVN r26161
