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.
Because the underlying API for fetching top-level decls returns them in an unspecified order, PrintAsClang sorts the decls before printing them to make the output order more stable. However, the rules currently implemented have at least one known defect (they compare only the unqualified name of a nested class, so two nested classes with the same Swift name sort in an arbitrary order), and there are likely many more.
Add a fallback rule which sorts declarations by their mangled name; this should at least distinguish all non-colliding ValueDecls from each other, albeit according to fairly opaque criteria. Additionally add a rule to help distinguish extensions with very similar content, and tweak other logic so that the comparison function is less likely to give up early rather than continuing to look for a usable difference.
Fixes rdar://129485103.
These conformances are banned when using NSObjectProtocl in the real
SDK. Adding the `self` member has exposed these few places and started
diagnosing them as invalid again.
When @compatibility_alias is used with an ObjC generic class, this ends up importing as a generic typealias. PrintAsObjC previously didn’t handle declarations involving these types correctly; it would fail an assertion in asserts compilers, and potentially print an incorrect compatibility header in non-asserts compilers.
This PR makes it so that PrintAsObjC can now correctly use generic typealiases imported from Objective-C modules. It is, of course, still not possible to declare a generic typealias in Swift that will be printed into the Objective-C header.
Fixes rdar://67256866.
The initial pass through a type’s members to forward-declare or import anything needed by them did not account for _ObjectiveCBridgeable conformances; instead, it would examine the Swift type being bridged from, either tripping an assertion or just failing to do anything. Treat these as references to the bridged type instead.
Fixes rdar://67263753.
We use the just-built clang without any -target or -sdk flags. Keep things
simple and limit the test to macOS for now.
Fixes <rdar://problem/50586614>.
The ObjC generator previously preserved a subtle difference between
'unowned' and 'unowned(unsafe)' / Unmanaged by printing the former as
'assign' and the latter as 'unsafe_unretained'. Upstream Clang,
however, has gotten a new warning to discourage the use of 'assign'
with reference-countable types at all. Since it was always a subtle
distinction, just go with the new convention and print
'unsafe_unretained' for 'unowned' properties as well.
rdar://problem/44290715
Technically, these operations belong in the ObjectiveC module, where NSObject
is defined. Keep them there. However, we need to build the mock ObjectiveC
overlay with `-disable-objc-attr-requires-foundation-module` now.
This ensures that 'Foo' always gets imported before 'Foo_Private'.
This shouldn't strictly be necessary but does end up with more
reliable results in practice.
rdar://problem/36159006
Use the attribute to update the OptionalTypeKind used for various
decls that we print.
I added test cases to make sure we were exercising all the modified
code paths.
The general policy has been that even if something crashes at run
time, we don't make it a hard error in Swift 4 mode (or Swift 3 mode!)
if it wasn't a hard error in Swift 4.0 (3.0). In this case, we thought
we could get away with it, and then it turns out it actually caused
some problems. (And as 2bc010681 shows, we can still make mistakes.)
This change isn't perfect because the diagnostic appears in /clients/
rather than in the module that's being compiled as Swift 4 (instead of
Swift 5). But it still means that someone who hasn't changed
/anything/ from a valid Swift 4.0 project will be able to compile
without any changes, even if they were relying on being able to call
+new when -init was unavailable for some reason.
More rdar://problem/35942058
Follow-up to 49c65facc9 to account for subclasses. An unavailable
-init makes +new unavailable, but reintroducing it in a subclass
should reintroduce +new if the root class is NSObject (where +new is
implemented).
rdar://problem/35914080
Currently a loop-hole exists by which one could end up invoking an unavailable -init initializer from Obj-C
when it is unavailable by using +new (which itself calls -init)
https://bugs.swift.org/browse/SR-5018
For historic reasons, Clang's representation of an Objective-C class
declaration ObjCInterfaceDecl) and compatibility alias
(ObjCCompatibleAliasDecl) are not actually Clang TypeDecl nodes. Cope
with this in Objective-C printing, fixing rdar://problem/32308192.
Initializers that don't look like init methods to ARC need to have
`SWIFT_METHOD_FAMILY(init)`.
Also tighten up the check for init-like methods to not consider e.g.
`initializeFoo` to be an init-like method.
I'm not sure why this didn't occur to me in 8282160d: of course if you
see a generic type with arguments, you need to see the @interface for
that type in order to supply the arguments. Maybe I was thinking the
generated interface would automatically import anything the module
itself imports, but that hasn't ever been true.
rdar://problem/28738008
From the Swift documentation:
"If you define an optional variable without providing a default value,
the variable is automatically set to nil for you."
More specifically, don't try to emit a definition for them. Just fall
through to what we do for forward-declarations...which also needed some
fixing, to make sure we don't use a Swift typealias as its underlying
type but never import the underlying type.
https://bugs.swift.org/browse/SR-2352
* [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.
* [PrintAsObjC] Add unavailable attribute to non-inherited initializers
Initializers that aren't inherited by subclasses cannot be called, so we
should make this visible to Obj-C.
Due to SR-2211, non-inherited convenience initializers do not get this
same treatment.
* [PrintAsObjC] Add unavailable initializers for private overrides
When a public initializer is overridden with a private one, we need to
mark these as unavailable to Obj-C as they're not supposed to be
callable even though they do exist.
* Migrate from `UnsafePointer<Void>` to `UnsafeRawPointer`.
As proposed in SE-0107: UnsafeRawPointer.
`void*` imports as `UnsafeMutableRawPointer`.
`const void*` imports as `UnsafeRawPointer`.
Occurrences of `UnsafePointer<Void>` are replaced with UnsafeRawPointer.
* Migrate overlays from UnsafePointer<Void> to UnsafeRawPointer.
This requires explicit memory binding in several places,
particularly in NSData and CoreAudio.
* Fix a bunch of test cases for Void->Raw migration.
* qsort takes IUO values
* Bridge `Unsafe[Mutable]RawPointer as `void [const] *`.
* Parse #dsohandle as UnsafeMutableRawPointer
* Update a bunch of test cases for Void->Raw migration.
* Trivial fix for the SceneKit test case.
* Add an UnsafeRawPointer self initializer.
This is unfortunately necessary for assignment between types imported from C.
* Tiny simplification of the initializer.
* Migrate from `UnsafePointer<Void>` to `UnsafeRawPointer`.
As proposed in SE-0107: UnsafeRawPointer.
`void*` imports as `UnsafeMutableRawPointer`.
`const void*` imports as `UnsafeRawPointer`.
Occurrences of `UnsafePointer<Void>` are replaced with UnsafeRawPointer.
* Migrate overlays from UnsafePointer<Void> to UnsafeRawPointer.
This requires explicit memory binding in several places,
particularly in NSData and CoreAudio.
* Fix a bunch of test cases for Void->Raw migration.
* qsort takes IUO values
* Bridge `Unsafe[Mutable]RawPointer as `void [const] *`.
* Parse #dsohandle as UnsafeMutableRawPointer
* Update a bunch of test cases for Void->Raw migration.
* Trivial fix for the SceneKit test case.
* Add an UnsafeRawPointer self initializer.
This is unfortunately necessary for assignment between types imported from C.
* Tiny simplification of the initializer.
It sounds good on paper, but in practice we ended up breaking Core Data
projects (because people name their boolean properties 'isFoo' rather
than the Objective-C 'foo'), forcing an Objective-C-side change when
a mixed-source project upgrades to Swift 3, and causing collisions when
there are properties named both 'foo' and 'isFoo'. If people care about
their Swift boolean properties strictly following the Objective-C Cocoa
naming conventions, they'll have to specify them manually.
(We do have a bug to make it easier to rename the getter of a stored
property exposed to Objective-C: rdar://problem/21261564.)
This reverts commit 6fe6266c99.
rdar://problem/26847223
Swift has supported this for a long time using manual casts and going
from Swift to Objective-C; just enable it now for the importer.
rdar://problem/15101588
Bridged value types are implicitly copied as part of bridging.
This isn't 100% correct because it doesn't handle bridged types
that /don't/ conform to NSCopying, but there aren't any of those
today and there probably shouldn't be.
rdar://problem/26917017
