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.
SDK conformance nodes include only protocol
`name` and `printedName`, both are demangled.
USR field of the protocol type is added, to be able
to uniquely identify conformances.
This commit adds a new type DynamicLookupInfo that provides information
about how a dynamic member lookup found a particular Decl. This is
needed to correctly handle KeyPath dynamic member lookups, but for now
just plumb it through everywhere.
We were relying on attributes being propagated by the type-checker, for
example from a property to its accessors, but the goal is for these to
be caculated lazily by the request evaluator, so we should be checking
the AST predicates instead. As a workaround, force calculating them to
cause the attributes to be added for now to fix a CI failure.
Patch by @slavapestov
rdar://50184238
For some unclear reasons, calling getAllConformances on Int.Words and
UInt.Words returns duplicate entries for conforming to RandomAccessCollection.
Since this isn't the case for swift-5.1-branch, we saw false positives shown
in rdar://49568079.
This patch fixes the ABI/API checker by de-duplicate results collected from
getAllConformances.
ABI placeholders are decls with attribute '@available(macOS 9999, iOS
9999, tvOS 9999, watchOS 9999, *)'. The diagnostics phase could be
forgiving for ABI breakages on these decls since they are added
recently. This patch adds a new flag to the json file indicating whether
a declaration or a conformance is an ABI placeholder. The checking of
placeholder is transitive, meaning a decl is an ABI placeholder if its
decl context is one.
rdar://49502365
Protocol requirements may not necessarily add new entries to the witness table if
it's inherited from super protocol. This patch teaches the json dump to
include a flag indicating whether a protocol requirement requires new
witness table entry and diagnoses the change of such flag as ABI
breakages.
rdar://47657204
cl is unable to disambiguate between `swift::KnownProtocolKind` and
`swift::ide::api::KnownProtocolKind`. Use the elaborated typename to
disambiguate the type. This allows us to build `swift-api-digester`
with cl again.
Upon seeing an extension for a type outside the current module, the digester
creates a dummy type node and puts all the extensions’ members and conformances
in that type. This allows us to track new API endpoints that are retroactively
added.
Unfortunately, if there are no public members/conformances (only internal or
private ones), the type itself ends up in the SDK dump without any public
children. This causes an issue when you dump the SDK from a parseable
interface, where the internal extension was not printed.
Modeling ProtocolConformance as a standalone node allows us to keep
track of all type witnesses and re-use existing matching algorithm
to diagnose type witness changes.
