Currently, the `_os_signpost_emit_with_name_impl` function is not available to be called from Swift. This is the main ABI entrypoint for making os_signpost calls. In order to facilitate more efficient calls to os_signpost in future iterations of the Swift os_signpost API, we need to allow calling this function from Swift.
rdar://70015938
This commit introduces a CMake target for each component, adds install targets
for them, and switches build-script-impl to use the target `install-components`
for installation. Each of the targets for each component depends on each
of the individual targets and outputs that are associated with the
corresponding swift-component.
This is equivalent to what already exists, because right now install rules are
only generated for components that we want to install. Therefore, this commit
should be an NFC.
This is a resubmission (with modifications) of an earlier change. I originally
committed this but there were problems with some installation rules.
This commit introduces a CMake target for each component, adds install targets
for them, and switches build-script-impl to use the target `install-components`
for installation. Each of the targets for each component depends on each
of the individual targets and outputs that are associated with the
corresponding swift-component.
This is equivalent to what already exists, because right now install rules are
only generated for components that we want to install. Therefore, this commit
should be an NFC.
CMake supports the notion of installation components. Right now we have some
custom code for supporting swift components. I think that for installation
purposes, it would be nice to use the CMake component system.
This should be a non-functional change. We should still only be generating
install rules for targets and files in components we want to install, and we
still use the install ninja target to install everything.
Otherwise, we'll think we don't need to install the API notes.
No test because this configuration isn't (yet) tested publicly
anywhere, but it is being tested within Apple.
They're all the same anyway, and no longer even need to be compiled,
just copied in as text.
And drastically simplify how we "generate" them. Instead of attaching
their build jobs to the appropriate overlays, if present, "just" have
one job to copy them all and attach it to the Darwin overlay. That's
what we do for the overlay shim headers, and it's good enough.
(Eventually we want to get out of the business of shipping them
altogether.)
This does have the same flaw as the shim headers: if you /just/ change
API notes, the corresponding overlay does not get rebuilt. You have to
touch that too. But in practice that'll happen most of the time
anyway.
Part of rdar://problem/43545560
Clang's been able to read the textual format for a long time, and
indeed that's what's used in the SDK. This isn't even really a
performance win because the information is cached in PCMs.
rdar://problem/34293901
The framework versions already superseded the files here, so let's not
even bother building and packaging them. There /are/ still a few
frameworks that aren't shipping their own API notes at the moment,
however, though some of them are deprecated in their entirety.
rdar://problem/32908357
Generic Objective-C classes with this annotation will be imported as
non-generic in Swift. The Swift 3 behavior hardcoded a certain set of
class /hierarchies/ as permanently non-generic, and this is preserved
in Swift 3 mode.
Actually using this API note in a versioned way (as opposed to just
marking the class non-generic in all language versions) will cause
horrible source compatibility problems in the mix-and-match cases,
where Swift 3 code presents a non-generic type that Swift 4 expects to
be generic or vice versa. Fixes for this will come later; right now
it's more important to add support for the feature at all.
To avoid unwanted changes in Swift 4, this commit also adds API notes
to make any existing classes in the previously-hardcoded set continue
to import as non-generic even in Swift 4. The difference is that
/subclasses/ of these classes may come in as generic. (If we want to
make a change here, that can be a separate commit.)
rdar://problem/31226414 (Swift side of rdar://problem/28455962)
In the SDK shipped with Swift 3, NSXMLNodeKind's enumerator
NSXMLDTDKind was mistakenly annotated with `NS_SWIFT_NAME(DTDKind)`
instead of `NS_SWIFT_NAME(dtd)`. We'd like to fix that in a later
version of the SDK, but we need to maintain Swift 3 compatibility on
the off-chance someone is using the bad name. If we /do/ decide to
change this, we can undo this change (going back to an API note
SwiftName of 'dtd') and add a Swift-3-versioned SwiftName of 'DTDKind'
instead.
While the second argument to NSFastEnumeration's
countByEnumerating(with:objects:count:) really shouldn't be nil, it's
possible someone got away with it in Swift 3.
Follow-up for rdar://problem/25846421.
Enable CMake policy CMP0057, which allows `if()` statements to use the `IN_LIST`
operator. In addition, simplify several `if()` statements that used the
`list(FIND ...)` operation instead.
Some files accidentally /renamed/ the enums using SwiftName rather than
associating them with an error domain constant. Amazingly, we've gotten
no complaints about this.
We could support this in the future but right now it's causing problems.
There's also a potential ambiguity issue here where a protocol and class
could have the same name.
In addition to updating the importer, remove the two entries from the
CryptoTokenKit API notes that were trying to use this feature.
rdar://problem/27990168
We don't yet support nested types for the target of swift_name, which
is a very unfortunate omission. Instead, use un-qualified names in the
apinotes, which default to the decl's context, which in this case
fortunately interacts with swift_newtype to end up in the properly
nested struct in Swift proper. Gross.
CoreText is below Foundation in the framework stack, so its error enum
uses a CFStringRef constant as its domain instead of an NSString. The
importer doesn't know how to handle that yet, so for now, just don't
import CTFontManagerError as a first-class error type.
rdar://problem/27722004
* [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.
