When the checker found a breakage listed in the user-specified list,
the breage should be consumed internally without failing the check.
rdar://68086477
Removing or updating @_alwaysEmitIntoClient functions are never ABI-breaking, thus
we should exclude them from the symbol set for ABI stability checking.
rdar://67883661
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.
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
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 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.
