Unfortunately, I think this somewhat kills the point of
this test; it should probably be replaced by a test of a
method that doesn't get correctly error-imported.
Swift SVN r28054
This reverts commits r26369 & r26381.
After upstream clang changes, reverted r25843 which was compensating for a previous upstream clang change.
But keep test/IDE/complete_from_clang_framework.swift disabled for further investigation, because it
seems to have some duplications in a code-completion test.
rdar://20245658&20247922
Swift SVN r26430
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
We require some level of consistency between the way the overlays were
built and what we work with in our mock SDK. The IDE/sdk_sugar.swift
test failure was because the overlay referenced "init(coder:)" while
the test was looking for "init(withCoder:)". Hilarity ensued
<rdar://problem/17791048>.
This only impacts testing.
Swift SVN r20564
The new sugar is 'NSErrorPointer', which hides 'AutoreleasingUnsafePointer<NSError?>'.
I have not yet tested this on iOS, which previously had problems
with the type sugar import. I'll try and test that now.
Swift SVN r18270
Previously 'NSError**' was imported directly as
ObjCMutablePointer<NSError?>, which is verbose and quite ugly
in the synthesized interfaces and overrides. This remapping
is semantically equivalent by syntactically prettier.
This name needs to go through API review.
The test uses the actual SDK; the clang-importer-sdk didn't work
because the dump of the Foundation module only shows the pieces
from the Swift files, and the Objective-C pieces are just shown
as re-exported modules. Testing the actual SDK provides good
fidelity anyway.
Swift SVN r17707