* Revert "Revert "[SymbolGraphGen] synthesize child symbols for type aliases of private…" (#79062)"
This reverts commit cac82978bc.
* clean up use of DenseMap in SymbolGraphGen
rdar://143865173
This change is two fold. Firstly it enables collection of exported
imports from non source file units. Additionally this recurses through
the exported imports to ensure the transitive set is collected.
Fixes https://github.com/apple/swift/issues/59920
rdar://89687175
This includes:
- bumping the SWIFT_SYMBOLGRAPH_FORMAT_MINOR version
- introduction of the "swift.extension" symbol and "extensionTo" relationship
- adding support for ExtensionDecl to the Symbol class
- adding a "typeKind" field to the symbol's extension mixin which indicates what kind
of symbol was extended
- intoduction of the -emit-extension-block-symbols flag, which enables the behavior
outlined below
- adaptions to SymbolGraphASTWalker that ensure a swift.extension symbol is emitted
for each extension to a type that does not exist in the local symbol graph
- adaptions to SymbolGraph and SymbolGraphASTWalker that ensure member and conformance
relationships are correctly associated with the swift.extension symbol instead of
the original type declaration's (extended nominal's) symbol where applicable
- adaptions to SymbolGraphASTWalker that ensure swift.extension symbols are connected
to their respective extended nominal's symbol using an extensionTo relationship
Testing:
- adds SymbolGraph tests that test behavior only relevant in
-emit-extension-block-symbols mode
- adapts some SymbolGraph tests to additionally test similar behavior for
extensions to external types in -emit-extension-block-symbols mode
- adapts some SymbolGraph tests to (additionally or exclusively) test the
behavior with -emit-extension-block-symbols mode enabled
Bugfixes:
- fixes a bug where some conformsTo relationships implicated by the conformances
declared on an extension to an external type were not emitted
(see test/SymbolGraph/Relationships/ConformsTo/Indirect.swift)
Further changes:
- documents the strategy for naming and associating children declared in extensions
to typealiases (see test/SymbolGraph/Relationships/MemberOf/Typealias.swift,
test/SymbolGraph/Symbols/Names.swift)
* only include the given symbol for qualified imports
rdar://96309088
* re-exporting one type should not allow unrelated types to sneak in
* ensure that children of re-exported types are also re-exported
When emitting a symbol graph file for a module that import modules via
`@_exported import`, emits those modules' symbols as well.
SR-15753
rdar://89547374
LLVM, as of 77e0e9e17daf0865620abcd41f692ab0642367c4, now builds with
-Wsuggest-override. Let's clean up the swift sources rather than disable
the warning locally.
Consider declarations inside `@_spi` extensions to be internal.
Clean up the "implicitly private" check to work for `Decl` and not just
`ValueDecl`, allowing it to be used directly on extensions instead of having to
look for extensions everywhere.
rdar://63361634
When extending another module's type in your module, serialize declarations in
the extension into the other module's "extension" symbol graph file, including
relationships. This mechanic should continue up to the rootmost module. For
example:
A.AStruct <- B.BStruct < C.CStruct
Both BStruct and CStruct should go in `@A` symbol graph files because AStruct
owns BStruct and by extension owns CStruct. This is reflected in
documentation curation in some form already.
rdar://60796811
Requirements on extensions were only being gathered indirectly. This adds a new
optional field to `conformsTo` relationship edges, `swiftConstraints`, which
provides the requirements there.
rdar://60091161
Emit copies of default implementations in protocol extensions and superclass declarations in conforming types and subclasses respectively using a virtual USR, i.e. `${REAL_USR}::SYNTHESIZED::${CONFORMING_OR_SUBCLASS_TYPE_USR}`.
- Add a -skip-synthesized-members option to skip these synthesized members.
- Create a new wrapping `Symbol` type that can also contain a base type declaration as well as the inherited declaration for those synthesized cases. Move some symbol-specific APIs there.
- Doc comments can “cascade” down to protocol extensions or refinements in concrete types. When emitting the doc comment for a symbol, look up through to superclasses or protocol requirements for where a doc comment is actually written.
- Clean up filtering of implicitly private (e.g. “public underscored”) types
rdar://problem/59128787
When a module extends a type from another module, serialize those symbols into
separated files dedicated to those extended modules. This makes it easier to
ingest and categorize those symbols under the extended module if desired.
rdar://58941718
Up to now, the `SymbolGraphASTWalker` was only concerned with one module. This
change prepares for emitting multiple symbol graph files, for each module that
the module of interest extended. There is only one walker, so extract the
symbol logic into `SymbolGraph`, where it can be reused.
rdar://58941718
`pathComponents` doesn't help with disambiguation, so it shouldn't be a part of
the identifier, but can be moved up one level. Include an interface language in
the identifier instead.
rdar://problem/58853310
Adds a tool `swift-symbolgraph-extract` that reads an existing Swift
module and prints a platform- and language-agnostic JSON description of
the module, primarly for documentation.
Adds a small sub-library `SymbolGraphGen` which houses the core
implementation for collecting relevant information about declarations.
The main entry point is integrated directly into the driver as a mode:
the tool is meant to be run outside of the normal edit-compile-run/test
workflow to avoid impacting build times.
Along with common options for other tools, unique options include
`pretty-print` for debugging, and a `minimum-access-level` options for
including internal documentation.
A symbol graph is a directed graph where the nodes are symbols in a
module and the edges are relationships between them. For example, a
`struct S` may have a member `var x`. The graph would have two nodes for
`S` and `x`, and one "member-of" relationship edge. Other relationship
kinds include "inherits-from" or "conforms to". The data format for a
symbol graph is still under development and may change without notice
until a specificiation and versioning scheme is published.
Various aspects about a symbol are recorded in the nodes, such as
availability, documentation comments, or data needed for printing the
shapes of declarations without having to understand specifics about the
langauge.
Implicit and public-underscored stdlib declarations are not included by
default.
rdar://problem/55346798
