Find all the usages of `--enable-experimental-feature` or
`--enable-upcoming-feature` in the tests and replace some of the
`REQUIRES: asserts` to use `REQUIRES: swift-feature-Foo` instead, which
should correctly apply to depending on the asserts/noasserts mode of the
toolchain for each feature.
Remove some comments that talked about enabling asserts since they don't
apply anymore (but I might had miss some).
All this was done with an automated script, so some formatting weirdness
might happen, but I hope I fixed most of those.
There might be some tests that were `REQUIRES: asserts` that might run
in `noasserts` toolchains now. This will normally be because their
feature went from experimental to upcoming/base and the tests were not
updated.
Prviously swift-ide-test enabled importing of ObjC forward declarations
with the -enable-objc-forward-declarations option. The compiler enables
the same behavior via -enable-upcoming-feature.
Now that swift-ide-test also supports upcoming-features, make enabling
the ImportObjcForwardDeclarations language feature have the expected
effect in swift-ide-test.
The old flag is also removed.
This modifies the ClangImporter to introduce an opaque placeholder
representation for forward declared Objective-C interfaces and
protocols when imported into Swift.
In the compiler, the new functionality is hidden behind a frontend
flag -enable-import-objc-forward-declarations, and is on by default
for language mode >6.
The feature is disabled entirely in LLDB expression evaluation / Swift
REPL, regardless of language version.
* [ClangImporter] Remove importer-based NS stripping.
As Tony puts it, in the end we wound up with more Foundation
declarations imported as members or keeping "NS" than those that
dropped it, and any further decisions will be made on a case-by-case
basis. Move all of the existing cases of prefix-stripping into
Foundation's API notes and drop the logic from the compiler.
Tested by dumping the generated interface for Foundation and its
submodules for both macOS and the iOS simulator, and comparing the
results. A few cases did slip through here because of the interaction
between "SwiftName" and "Availability: nonswift".
The next commit will re-add "NS" to some stragglers that we missed.
rdar://problem/26880017
* APINotes: Add "NS" back to a few types.
NSKeyedUnarchiverDelegate
NSKeyedArchiverDelegate
NSTextCheckingTypes
NSBinarySearchingOptions
NSEnumerationOptions
NSSortOptions
More rdar://problem/26880017
* Remove now-redundant SwiftNames from API notes.
No change observed in the generated interface of Foundation and its
submodules.
Finishes rdar://problem/26880017.
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
This re-applies r21857, which was reverted r21871, fixing a use-of-
uninitialized-memory error that only showed up in optimized builds.
Swift SVN r21933
When we print the ObjectiveC module, we really shouldn't see extensions that
come from Foundation. Admittedly, we don't see them correctly in Foundation
either, but that's a separate issue.
There is one slightly unsafe hack here: we still import NSString as String,
by name alone, even when Foundation isn't present. This is because NSString
shows up in the ObjectiveC module, but we want people to be using String
when interacting with NSObject in real life.
Swift SVN r21857
This can be used by SourceKit's interface printer to display modules with
forward declarations of classes in dependent modules, e.g. ObjectiveC
forward-declaring Foundation's NSString for use in NSObject. We can consider
doing something similar for C tag types (structs and enums).
Part of rdar://problem/18273845
Swift SVN r21828
