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)
When the SymbolGraph json is requested via (key.retrieve_symbol_graph: 1) this adds
a new field in the response that lists all the parent contexts of the symbol under
the cursor with their symbol graph kind and name, and their USR:
key.parent_contexts: [
{
key.kind: "swift.struct",
key.name: "Parent",
key.usr: "s:27cursor_symbol_graph_parents6ParentV"
},
...
]
}
Resolves rdar://problem/73904365
Adds a new 'key.retrieve_symbol_graph' option to the request. When set to 1 it
includes the JSON for a SymbolGraph containing a single node for the symbol at
the requested position.
This also extends the SymbolGraph library with a new entry point to get a graph
for a single symbol, and to additionally support type substitution to match the
existing CursorInfo behavior (e.g. so that when invoked on `first` in
`Array<Int>().first`, the type is given as `Int?` rather than `Element?`).
Resolves rdar://problem/70551509
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
- Add DocRangesLayout to the `.swiftsourceinfo`.
This is a blob containing an array of `SingleRawComment`
source locations.
- Add DocLocWriter for serializing `SingleRawComment` locs into the
`DocLocsLayout` buffer.
Serialize start line, start column, and length of `SingleRawComment`
pieces in `.swiftsourceinfo`
- Read doc locs when loading basic declaration locs from a ModuleFile.
- Load `DOC_LOCS` blob into ModuleFile::DocLocsData
- Reconstitute RawComment ranges when available from .swiftsourceinfo
- Allow requesting serialized raw comment if available
rdar://problem/58339492
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
