And change a not-testing-anything-new frontend invocation into an
only-slightly-more-useful driver invocation.
This shouldn't really affect anything, but we've seen this test fail
spuriously for a long time. Maybe this fix'll stick.
rdar://problem/42247881
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.
Most tests were using %swift or similar substitutions, which did not
include the target triple and SDK. The driver was defaulting to the
host OS. Thus, we could not run the tests when the standard library was
not built for OS X.
Swift SVN r24504
Doing so is safe even though we have mock SDK. The include paths for
modules with the same name in the real and mock SDKs are different, and
the module files will be distinct (because they will have a different
hash).
This reduces test runtime on OS X by 30% and brings it under a minute on
a 16-core machine.
This also uncovered some problems with some tests -- even when run for
iOS configurations, some tests would still run with macosx triple. I
fixed the tests where I noticed this issue.
rdar://problem/19125022
Swift SVN r23683
Rather than embed AST info directly in binaries, we now include a special
symbol table entry that points to the serialized AST as a separate file.
This requires a very recent version of ld.
We still want to support the __SWIFT,__ast section in a binary because
that's how it's modeled in dSYM, so manually test both modes in
ASTSection_linker.swift.
Part of <rdar://problem/15796201>.
Swift SVN r20421
...as well as the target triple, include paths, and whether or not we're
compiling with debug info. (The last one doesn't currently make any
difference, but it seems prudent to be consistent.)
<rdar://problem/15930675>
Swift SVN r13080
