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.
