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
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.
This allows them to be used in generic arguments for NSArray et al.
We already do this for the ones that wrap bridged values (like
NSString/String), but failed to do it for objects that /weren't/
bridged to Swift values (class instances and protocol compositions),
or for Error-which-is-special.
In addition to this being a sensible thing to do, /not/ doing this led
to IRGen getting very confused (i.e. crashing) when we imported a
Objective-C protocol that actually used an NS_TYPED_ENUM in this way.
(We actually shouldn't be using Swift's IRGen logic to emit protocol
descriptors for imported protocols at all, because it's possible we
weren't able to import all the requirements. But that's a separate
issue.)
https://bugs.swift.org/browse/SR-6844
Ownership keywords (weak/unmanaged) in @objc protocols do have an
effect on the generated header, because they get reflected as
weak/assign in the Objective-C `@property`. Therefore, allow these
keywords (again) on properties of @objc protocols.
Fixes SR-7182 / rdar://problem/38418112.
This converts the instances of the pattern for which we have a proper
substitution in lit. This will make it easier to replace it
appropriately with Windows equivalents.
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
Turns out libc++ already defines compatibility typedefs in this case,
and we don't care about any other C++ stdlibs on Apple platforms at
the moment.
rdar://problem/34861807
SourceKit uses a clever pragma to automatically attach an attribute to
every declaration in the file. However, the form of this pragma (clang
attribute push) uses a parenthesized list marked with 'any', which turns
out to be a name that people sometimes use for macros. Guard against this
using the push_macro pragma (originally from MSVC), under the assumption
that anyone who supports the highly-use-specific 'external_source_symbol'
attribute probably implements this more common extension. This does make
the generated header a little uglier, but it's not like it was really
pretty to begin with.
rdar://problem/34168022
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
Now that Clang has availability diagnostics too
(-Wpartial-availability and friends) we need to get this correct, or
people will get warnings in the generated header!
rdar://problem/33313703
Since Swift 3 and Swift 4 might have different views of an Objective-C
API's nullability, we can end up with incompatible overrides,
including with inherited initializers. This is unfortunate but also
realistic; the Swift 3 code is /not/ set up to handle the new nullability
used by Swift 4 and Objective-C. Just silence the warning.
(It would be nice to not print inherited initializers at all, but that
would mean making sure there are no convenience initializers we have
to print as well. Otherwise the class would get mistaken for one
without explicit designated initializers.)
rdar://problem/32571301
These are TypeAliasDecls whose Clang nodes are not TypedefNameDecls.
This worked all right for classes, but dropped the tag keyword
(e.g. 'struct') for tag decls with names of their own, and didn't
print any name at all for C types that used the
typedef-for-anonymous-tag pattern.
rdar://problem/32514335
When available, use Clang's new diagnose_if attribute to mark
Objective-C methods/properties that were generated based on the @objc
inference rules that have been removed from Swift 4. The diagnose_if
warnings aren't likely to be accidentally disabled or hidden by other
deprecated code.
Fixes rdar://problem/32370734.
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.
Only do so in modes where '@objc' /is/ inferred but we're supposed to
warn about it. Neither plain old Swift 3 nor plain old Swift 4 are in
this state, but we have frontend options that allow us to set that up
for migration purposes.
rdar://problem/32284936
This breaks a cycle with a function in Foundation, but isn't a complete
fix: it will be similarly problematic if a function that can't have the
throws conversion is added.
The C preprocessor rules don't short-circuit so "#if defined(__has_feature) && __has_feature(modules)" will always fail if '__has_feature' is not defined.
When Swift 3 infers @objc using one of the rules deprecated in Swift 4, add a “deprecated” attribute to the declarations generated Objective-C header so that Objective-C gets warnings for uses of these APIs.
This test was designed to ensure that extensions that only add a
non-objc-compatible protocol are not printed in a compatibility header.
That case is already covered by the `extension NSString : NotObjC {}`
test in `PrintAsObjC/protocols.swift`.
Most of the time, "generics" means "cannot be exposed to Objective-C"
and certainly "cannot be exposed in the generated header", but there
is one exception: imported Objective-C parameterized types, and their
extensions. We were previously dropping this on the floor and printing
`Foo</* BarType */>` in the generated header, which is nonsense.
https://bugs.swift.org/browse/SR-3480
* Add 'SWIFT_NORETURN' macro to the prologue. This macro is evaluated to
'__attribute__((noreturn))' where supported.
* Apply 'SWIFT_NORETURN' to 'isUninhabited()' methods.
