Most of this is enabled by an upstream change to generalize the tests
for the api-digester to properly handle all targets. The primary change
here is to account for the Swift-level ABI differences for the standard
library between Apple Silicon macOS and Intel macOS. Specifically, anything
related to Float80 will be removed from the standard library on Apple Silicon
macOS, so account for the differences.
Most of the changes fall into a few categories:
* Replace explicit "x86_64" with %target-cpu in lit tests
* Cope with architecture differences in IR/asm/etc. macOS-specific tests
Previously inherited constructors would be skipped from added in member list, depending on the order of request evaluator calls.
This was a regression compared to swift 5.2
Client code can't override or subclass a `public` declaration already, so although the ABI differs, the API is the same
whether something is `final` or not.
The API digester tests were being run only for macOS, mainly
because they were not using %target-swift consistently. Lift
the unnecessary restriction so we run these tests more widely.
Using a directory instead of an exact file name for the generated
baseline allows the tool to use target triple as file name, which is
expected by the diagnostic phase.
Lazy loading checked if the ClangDecl was hidden, but loading all
members did not. Let's make loadAllMembers() behave like the lazy
path, and fix some of the mock SDKs in the test suite.
Because we won’t be serializing this attribute, add custom diagnostics for the cases where:
- We add @_hasMissingDesignatedInits to an open class, which means subclasses won’t be able to inherit its inits
- We remove @_inheritsConvenienceInitializers, which means APIs are removed
These symbols were introduced in the following commit, but the
expected ABI test output was not updated accordingly.
commit 0967783170
Merge: c6d51a975c1cce12f20c
Author: David Smith <david_smith@apple.com>
Date: Thu Sep 26 15:20:45 2019
Merge pull request #27341 from Catfish-Man/mutant-arrays
Add an Array-based NSMutableArray subclass
If client's subclass provides an implementation of all of its superclass designated
initializers, it automatically inherits all of the superclass convenience initializers.
This means if a new designated init is added to the base class, the inherited
convenience init may be missing and cause breakage.
SR-11454
ABI/API checker used to hard-code whether adding or removing of a
decl attribute could break the existing ABI/API. This is not ideal because
new attributes may be added to AST without updating the checker. After this
change, new decl attribute could be specified whether it has ABI/API
impact and the checker could pick up the knowledge instantly.
Framework authors may be interested in comparing the current framework build
against an empty baseline to find public APIs without @available attributes. This
change makes such exercise easier.
The framework baselines are installed at 'lib/swift/FrameworkABIBaseline' and the
tool is inside 'bin'. This patch teaches the executable to locate baselines
from the relative path.
In addition, this patch moves the stdlib ABI/API baselines to the canonical
location so we don't have to check the stability of the stdlib using a
different mechanism from other Swift frameworks.
ABI/API checker should check semantic differences of two modules.
Adhering too strictly to the actual ASTs could yield false positives. This
patch populates ObjC, Dynamic and Final to the attribute list if AST
APIs say so.
rdar://50217247
Framework authors usually have different schemes for different deployment
targets. We should exclude platform-unavailable ABIs from the Json file so
developers will only be warned of the breakages that are relevant to the current
scheme.
rdar://54273296
Under `-enable-library-evolution`, a slight AST difference is still found when importing
from .swiftinterface and from .swiftmodule. The difference is whether @objc attribute
is inherited by a Swift class subclassing an Objc class.
ABI checker imports Swift frameworks by using Swift interfaces for various
reasons. The existing way of controlling preferred importing mechanism is by
setting an environment variable (SWIFT_FORCE_MODULE_LOADING), which may lead
to performance issues because the stdlib could also be loaded in this way.
This patch adds a new front-end option to specify module names for
which we prefer to importing via Swift interface. The option currently is only
accessible via swift-api-digester.
rdar://54559888
This change introduces a Json format change where we always print fully
qualified type names everywhere. This is beneficial for diagnosing purposes but
may not be ideal for generating migrator scripts. To resolve this conflict, the
patch also introduces a flag -migrator to opt-out fully qualified type names.
After the format change, we need to update the ABI and API baselines for the
Swift stdlib.
* Revert "Add availability information to the new Math function protocols (#24187)"
This reverts commit d2f695935f.
* Revert "SE-0246: Protocols and static functions (#23824)"
This reverts commit 57a4553832.
* Expected abi changes.
There could be cases where several modules having types of the same name.
Using fully qualified names could help us detect changing from using
one of them to another.
The commit also updates the existing ABI/API baselines to incorporate such change.
