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.
If Swift sees this pattern of methods in an @objc protocol:
```
func hello() async -> Int
@available(*, renamed: “hello()”)
func hello(completion: @escaping (Int) -> Void)
```
Then PrintAsClang will print only the completion-handler-based method, not the async one, into a generated header, on the assumption that the completion-handler method may have greater availability.
Fixes rdar://94175167.
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.
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.
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
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
* [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.
This commit defines the ‘Any’ keyword, implements parsing for composing
types with an infix ‘&’, and provides a fixit to convert ‘protocol<>’
- Updated tests & stdlib for new composition syntax
- Provide errors when compositions used in inheritance.
Any is treated as a contextual keyword. The name ‘Any’
is used emit the empty composition type. We have to
stop user declaring top level types spelled ‘Any’ too.
Use the keywords `_Nullable`, `_Nonnull`, and `_Null_unspecified`
instead of the older compatibility forms `__nullable`, `__nonnull`, and
`__null_unspecified`.
Part of rdar://problem/23614638
These classes don't show up well in generated headers (rdar://problem/20855568),
can't actually be allocated from Objective-C (rdar://problem/17184317), and
make the story of "what is exposed to Objective-C" more complicated. Better
to just disallow them.
All classes are still "id-compatible" in that they can be converted to
AnyObject and passed to Objective-C, they secretly implement NSObjectProtocol
(via our SwiftObject root class), and their members can still be individually
exposed to Objective-C.
The frontend flag -disable-objc-attr-requires-foundation-module will disable
this requirement as well, which is still necessary for both the standard
library and a variety of tests I didn't feel like transforming.
Swift SVN r29760
This is half of rdar://problem/17469485. The other half will be
recognizing in the importer that the Objective-C declaration references
a Swift type; see next commit.
Swift SVN r29743
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
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
rdar://problem/17198298
- Allow 'static' in protocol property and func requirements, but not 'class'.
- Allow 'static' methods in classes - they are 'class final'.
- Only allow 'class' methods in classes (or extensions of classes)
- Remove now unneeded diagnostics related to finding 'static' in previously banned places.
- Update relevant diagnostics to make the new rules clear.
Swift SVN r24260
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
This only tackles the protocol case (<rdar://problem/17510790>); it
does not yet generalize to an arbitrary "class" requirement on either
existentials or generics.
Swift SVN r19896
attribute is a "modifier" of a decl, not an "attribute" and thus shouldn't
be spelt with an @ sign. Teach the parser to parse "@foo" but reject it with
a nice diagnostic and a fixit if "foo" is a decl modifier.
Move 'dynamic' over to this (since it simplifies some code), and switch the
@optional and @required attributes to be declmodifiers (eliminating their @'s).
Swift SVN r19787
The upshot of this is that internal decls in an app target will be in the
generated header but internal decls in a framework target will not. This
is important since the generated header is part of a framework's public
interface. Users always have the option to add members via category to an
internal framework type they need to use from Objective-C, or to write the
@interface themselves if the entire type is missing. Only internal protocols
are left out by this.
The presence of the bridging header isn't a /perfect/ way to decide this,
but it's close enough. In an app target without a bridging header, it's
unlikely that there will be ObjC sources depending on the generated header.
Swift SVN r19763
You can still mark them @objc explicitly (or @IBOutlet, or anything else that
would require ObjC interop).
Also, don't print private decls in the generated header, whether @objc or not.
not.
Swift SVN r19733
- Category names weren't unique.
- We were using an attribute to detect if something was a Swift category,
but attributes can't be used on categories.
- The test that this was all working was failing in a way that wasn't caught.
To solve these problems:
- We're using a macro to generate category names based on __LINE__ in addition
to the current module.
- The importer uses the macro to detect that the category comes from Swift
(no attribute needed).
- The test now has a deliberate error for -verify to catch.
<rdar://problem/17342287&17538553>
Swift SVN r19479
