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
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)
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.
Introduce typed accesses for the error types of AVFoundation,
CloudKit, Contacts, and CoreLocation. While here, fix the API notes
for the Contacts framework, which had an embarrassingly-wrong file
name ;)
These apinotes will swift_private many of the bounding box methods,
and adjust the overlays appropriately. Those APIs have better
alternatives provided by the overlays, and thus shouldln't be exposed.
The Clang attribute allows one to state that a particular enumeration
type describes an error, and associates it with a particular domain
constant. However, due to lack of API notes support, this attribute
wasn't actually getting used. Instead, we had a number of explicit
extensions to enum types to make them conform to the _BridgedNSError
protocol explicitly.
Now that we have API notes, use them to make these enums into error
enums with the appropriate domain, so that the Clang importer will
synthesize the _BridgedNSError conformances. Then, remove all of the
explicit conformances---and with them, the overlays for 12 frameworks.
There is a small fix to more eagerly consider these conformances as
"used" if an expression is formed with the error enum as a value
type. This better ensures that the conformances will be available at
runtime when needed.
This cleanup is needed to implement SE-0112 (NSError bridging),
although it is useful by itself.
It was a warning because I didn't want to break anything when I first
added the check, but we've been warning-free for a while now. Let's
keep it that way.
The problem here is that there isn't an obvious way to force a CMake
reconfiguration when you need to add new apinotes. This dates back to
when we (internally) had the apinotes in a separate repo, but that
hasn't been the case for a long time.
We're still not using a /normal/ CMake add_subdirectory for these
because we compile the apinotes as part of building overlays for
frameworks that have both overlays and apinotes, and I didn't want to
touch any of that stuff right now.
Also, move the ObjectiveC overlay into its own directory, so that we can
use the directory name as an indicator of what overlays exist.
This is in preparation for DevPubs providing the contents of the apinotes/
directory. The downside here is that adding new apinotes files doesn't
automatically trigger a rebuild; I intend to mitigate that somewhat by at
least triggering one when the revision number of the DevPubs repo changes.
Swift SVN r21078
Move all of the information about API notes into the "apinotes"
subdirectory, which specifies the API notes that it provides. The
organization is such that "apinotes" can become its own separate
repository, and the compiler build will pick up those API notes that
are available and build them along with the overlays.
Swift SVN r20406
