At some point I want to propose a revised model for exports, but for now
just mark that support for '@exported' is still experimental and subject
to change. (Thanks, Max.)
This is required to correctly use the mock SDK when the SDK overlay is
built and tested separately. (Otherwise, the mock SDK might not get
used, because the overlay SDK options would expand from the
%-substitution, appear first on the command line, and shadow the mock
SDK in the search path).
Swift SVN r25185
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
Also, remove calls to isSwiftReservedName in
ClangImporter::Implementation::importName(), since 'true' and 'false'
are now keywords and rdar://problem/13187570 is no longer a problem.
rdar://problem/18797808
Swift SVN r23244
The name was not only long and unwieldy, but inconsistent with our
conscious decision to avoid the use of "elements" in APIs as mostly
redundant.
Swift SVN r22408
There is some follow-up work remaining:
- test/stdlib/UnicodeTrie test kills the type checker without manual type annotations. <rdar://problem/17539704>
- test/Sema/availability test raises a type error on 'a: String == nil', which we want, but probably not as a side effect of string-to-pointer conversions. I'll fix this next.
Swift SVN r19477
instead of importing them as _Nil (which will be going away when nil becomes an expr).
You now get an error saying:
error: 'NULL' is unavailable: use 'nil' instead of this imported macro
This is pretty cool all around, except for the GCD macros that need to be fixed, I'll
handle that as a follow-up.
Swift SVN r18747
These are too close to "true" and "false" for comfort; they add confusion and
mess up code completion. If the names appear in other contexts, though (such
as enumerator names), we should still bring them through.
<rdar://problem/17080279>
Swift SVN r18670
When doing name lookup into a Clang module, look for a macro with the given name and try to convert it into a Swift decl. Turn simple literal macros with expansions <number>, -<number>, or (-<number>) into Swift read-only properties. Map integer literals to Swift 'Int' and float literals to Swift 'Double' for want of a better type to map them to--it would probably be better if we had a decl that behaved like Pascal 'const' and converted like a literal value. Codegen for the synthesized properties isn't wired up, so compiling code that tries to use macro values will currently die because of missing externals.
Swift SVN r3941
