...because otherwise option sets that get imported as members using
NS_SWIFT_NAME are printed with an 'enum' tag, and the definition of
NS_OPTIONS only declares the typedef under C++.
We should come back and figure out something more principled for this
later, but for now this solves an issue with generated headers
imported into C++ translation units.
rdar://problem/27130343
* [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.
These tests explicitly disable the use of modules. However, the lit
configuration is such that the module cache path will be passed unconditionally
to the clang invocation. Squelch the unused option warning (error).
Let's say I am a good citizen and document my private symbols:
/** My TOP SECRET DOCUMENTATION */
private class Foo {
}
When I go to distribute the compiled binary, I find out my private
documentation is distributed as well:
$ swiftc test.swift -emit-module -module-name "test"
$ strings test.swiftdoc
My TOP SECRET DOCUMENTATION
/** My TOP SECRET DOCUMENTATION */
If a client can't use a symbol (e.g. it's private [or internal and not
-enable-testing]) don't emit the documentation for a symbol in the
swiftdoc.
Fixes: SR-762, rdar://21453624
The test coverage implements this truth table:
| visibility | -enable-testing | documentation? |
|------------|-----------------|----------------|
| private | no | ❌ |
| internal | no | ❌ |
| public | no | ✅ |
| private | yes | ❌ |
| internal | yes | ✅ |
| public | yes | ✅ |
Modified the existing comments test coverage to expect non-public
documentation not to be emitted.
Don't rely on existing comment structure
Refuse to emit comments if the decl cannot actually have one. To
accomplish this, we move `canHaveComment` into the Decl instance. It
must also be marked `const`, since one of its existing usages operates
on a const pointer.
Perform fewer checks when serializing the standard library.
Otherwise, we cram a conventionally UpperCamelCase thing with a
newly-conventinally-lowerCamelCased thing together and destroy the
word boundaries. Fixes rdar://problem/24947695.
Also make sure the `FooDomain` constant for `ErrorType` enums uses the
correct name.
Fixes SR-693: Custom named @objc enum still exposes original Swift name
in Objective-C
Use the keywords `_Nullable`, `_Nonnull`, and `_Null_unspecified`
instead of the older compatibility forms `__nullable`, `__nonnull`, and
`__null_unspecified`.
Part of rdar://problem/23614638
(And they are '__nonnull' rather than '_Nonnull' for two reasons:
it's a very cheap concession to preserve compatibility with Xcode 6.3,
and the existing code works this way.)
rdar://problem/22805286
Swift SVN r32228
We just use a static string constant for now, which isn't at all resilient.
But it works! Credit to JoeG for coming up with this solution.
Part of rdar://problem/20577517
Swift SVN r28662
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
That's a C11 feature, and we can't force everyone to enable C11 just yet.
Instead, go back to the old way of using "enum Foo" to refer to @objc enums
defined in Swift. Just don't do it unilaterally for non-@objc enums.
Should unstick the buildbot.
Swift SVN r25161
...and then fix our forward-declaration logic that assumed that they did.
This fixes a rare case where we would end up printing "enum" twice if the
user (benignly) misused NS_ENUM.
rdar://problem/19769964
Swift SVN r25143
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
If enums are used as parameters or returns of @objc methods, we may need to forward declare those enums when printing the class @interface.
Swift SVN r23445
This is necessary for @objc enums because, for C compatibility, the representations of the cases must match their raw values. We might want to do this for sufficiently fragile Swift enums in the future too, but that can wait. This lets us successfully print the raw values as ObjC.
Swift SVN r23423
Predefine a SWIFT_ENUM macro that expands the same as NS_ENUM, but which we can use to recognize Swift-defined @objc enums that are imported back. Print enums as ObjC using this SWIFT_ENUM macro.
We currently don't serialize the raw value exprs of enums, so we fail to correctly bring raw values from the enum declaration to the ObjC version.
Swift SVN r23422
