PrintAsClang is supposed to emit declarations in the same order regardless of the compiler’s internal state, but we have repeatedly found that our current criteria are inadequate, resulting in non-functionality-affecting changes to generated header content. Add a diagnostic that’s emitted when this happens soliciting a bug report.
Since there *should* be no cases where the compiler fails to order declarations, this diagnostic is never actually emitted. Instead, we test this change by enabling `-verify` on nearly all PrintAsClang tests to make sure they are unaffected.
This did demonstrate a missing criterion that only mattered in C++ mode: extensions that varied only in their generic signature were not sorted stably. Add a sort criterion for this.
Previously they were ignored by the checking of '@objc', but in the
refactoring to a request the attribute started getting marked as
invalid without a diagnostic.
rdar://problem/43401047
Previously (a03c40cb2c) we assumed all Swift enums were non-frozen in
ObjC, a weird choice in retrospect. Now that we actually distinguish
frozen and non-frozen enums in Swift, we can use the
'enum_extensibility' attribute to mark them as open or closed in ObjC.
Note that this only matters for Swift libraries compiled with
-enable-resilience, i.e. those that might get a new implementation at
runtime. Everyone else is now declaring a "closed" enum, matching the
behavior in Swift.
...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
