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.
Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances in the swift repo.
Removing accessors other than getter and setter can be ABI breaking. This
patch starts to formally include all accessor decls in the tree and diagnose
their removal. This change only applies to the ABI checker since we still
exclude accessors other than getter and setter when diagnosing source
compatibility.
Including accessors formally can also allow us to check the missing
of availability attributes for newly added accessors.
rdar://52063421
With module stability from the compiler, we can now use an earlier version
of the SDK as the baseline and compare the new SDK with it. This patch
adds a new -bsdk flag to the tool to specify the baseline SDK path.
We used to use a Json format to capture the ABI/API detail of Swift modules to
walk-around module compatibility issues across different compiler versions. Since
Swift module now is in stable format, we can compare two swiftinterface files
directly without dumping the content into Json format.
For frameworks not shipping with OSs, the users should specify this flag
to avoid diagnosing some changes, such as the missing of OS availability
attributes.
New ABIs should have an @available attribute to describe the introducing
version. This patch teaches the tool to diagnose its missing.
Decls with @_AlwaysEmitIntoClient are excluded from the blaming lists since
they are essentially available all the time.
rdar://51089418
