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.
These have historically been defined as protocols in Objective-C
(under a pile of macros), but when imported into Swift they're classes
instead. Reverse this bit of magic by hard-coding the prefix "OS_" and
the header <os/object.h>, and emitting the classic 'foo_bar_t'-style
type names.
rdar://problem/29790636
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."
Simplify e.g., ASTContext::getBridgedToObjC(), which no longer needs
the optional return.
Eliminate the now-unused constraint kind for checking bridging to
Objective-C.
This was causing issues where the compiler rejected overrides of
imported members as being non-ObjC-compatible, even though the type
was exactly the same as what the Clang importer was using.
https://bugs.swift.org/browse/SR-2344
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
Like Swift generics, Objective-C generics may have constraints; unlike
Swift generics, Objective-C doesn't do separate parsing and
type-checking passes. This means that any generic arguments for
constrained generic parameters must be fully-defined, in order to
check that they satisfy the constraints.
This commit addresses this problem with three different mechanisms,
one for each kind of declaration that might run into this issue:
- For classes, if a member references a type with constrained generic
parameter, and the corresponding argument type hasn't been printed
yet, that member is "delayed", which means it is put into a category
at the end of the file.
- Protocols cannot have categories, so for protocols we instead see if
we can print the definition of the other type first. To break
circular dependencies, the printer will not attempt this if both the
type and the protocol are already being depended on. This isn't
perfect (see below).
- Rather than delaying members of extensions, we just delay them
wholesale. This keeps related members together, but also has
problems (see below).
These approaches solve the most common cases while still not crashing
in the uncommon ones. However, there are still a number of problems:
- The protocol heuristic is overly negative, which means we may generate
an invalid header even when there's a reasonable ordering. For example,
a single class might inherit from a class A and conform to protocol P,
and protocol P depends on class A as a generic argument. In this case,
defining class A first is the right thing to do, but it's possible for
the printer to decide that there's circularity here and just forward-
declare A instead.
- Protocols really can be circular. This can be fixed by printing a
forward-declared protocol alongside the generic constraints, i.e.
'id <MoreThanNSCopying, NSCopying>' instead of just
'id <MoreThanNSCopying>'.
- Extensions can introduce protocols as well. This is not modeled at
all; if a member depends on a protocol conformance, it's assumed
that simply printing the class would be sufficient. This could be
fixed by checking how a generic argument satisfies its constraints,
possibly delaying individual members from extensions in order to
print them sooner.
- More cases I haven't thought about.
Test cases for some of these problems are in the new
circularity-errors.swift file, mostly to make sure the ObjC printer
doesn't crash when it encounters them.
rdar://problem/27109377
...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
Don't allow types conforming to 'Error' or protocol compositions
involving 'Error' to be reflected in Objective-C. We still allow
bridging conversions, but they are not statically bridged. Fixes
SR-2249/rdar://problem/27658940.
We would crash because 'Any' doesn't have a corresponding bridged type through the normal bridging mechanism. Handle this correctly, and correctly recognize 'AnyHashable' and 'Any' as the upper bounds of Dictionary, Set, and Array so we present the unqualified NS types in the generated header.
* [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.
One last bit of SE-0072. We shouldn't fall back to bridged classes in the absence of type context for literals anymore. By itself, this kind of hoses the use of literals with NS types, but I think we can get most of the QoI back with overlay changes I plan to propose following this.
