Motivation: `GenericSignatureImpl::getCanonicalSignature` crashes for
`GenericSignature` with underlying `nullptr`. This led to verbose workarounds
when computing `CanGenericSignature` from `GenericSignature`.
Solution: `GenericSignature::getCanonicalSignature` is a wrapper around
`GenericSignatureImpl::getCanonicalSignature` that returns the canonical
signature, or `nullptr` if the underlying pointer is `nullptr`.
Rewrite all verbose workarounds using `GenericSignature::getCanonicalSignature`.
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
Structurally prevent a number of common anti-patterns involving generic
signatures by separating the interface into GenericSignature and the
implementation into GenericSignatureBase. In particular, this allows
the comparison operators to be deleted which forces callers to
canonicalize the signature or ask to compare pointers explicitly.
Flush it and the early validation hack now that we can delay computing the underlying interface type on demand and have taught type resolution to honor the structural type of a typealias.
This changes the way requirement signatures are spelled as a side effect.
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.
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
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.
Double-underscored names are reserved for the C++ "implementation"
(language and standard library). Even though "__Consuming" isn't
likely to be part of the C++ standard any time soon, we should follow
the rules.
Note that the API digester will continue to use the string
"__Consuming" for now, even though the underscores aren't really
significant, to avoid invalidating existing dumps.
No functionality change.
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.
The heuristics to decide whether fully qualified type names should be printed may
work differently when generating the baseline and when importing from just built
frameworks. This patch makes it consistent so that such false positives won't happen.
rdar://54276347
Inlinable decls from swift interface files allow us to construct the underlying types
of opaque result types, whose changes can break ABI.
rdar://52273137
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
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.
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
External type declarations are synthesized to incorporate members in extensions to types
of external modules. In diagnostics, we should use 'extension' instead of 'struct/class'
for these decls to avoid confusion.
To incorporate extensions to types from other modules, the tool sometimes needs
to pull type declaration from external modules even though these modules
are not under checking. We need a flag to explicitly mark such case.
