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
Rather than checking the underlying ObjectiveC decl, use the presence of
`OptionalAttr` to determine if a requirement is optional instead. This
is already added by the importer when necessary. An added benefit here
is that this also works for optional requirements defined in Swift (ie.
`@objc optional ...`).
In a mixed Objective-C / Swift module, we have a Clang module overlay that’s a Source file, not a serialized AST as is currently assumed. That assumption caused a crash when retrieving the symbol graph as part of a cursor info request to SourceKit, which was invoked on a method defined in the Objective-C part of the module.
To fix the crash, recursively use the same logic that already exists to serialize a module to also serialize the clang overlay module since that function alreayd correctly handles the distinction between source files and serialized ASTs.
Resolves rdar://76951147
Don’t record a `memberOf` relationship if we couldn’t look up the target, e.g. because the member is declared in an extension whose extended type doesn’t exist.
Resolves rdar://74063899
in some situations, enum element decls are being skipped when rendering
declaration fragments. this trips an assertion in the declaration
fragment renderer that ensures that it always renders something. by
always rendering enum elements, we can sidestep this issue.
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
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
In the cases where we specialize the presentation of type declarations in a
subheading or navigator setting, make sure to use the `identifier` fragment
kind instead of `typeIdentifier` to keep it consistent with the normal or
"full" setting.
rdar://62953144
A type can have multiple overloads available from different protocols from
which it inherits. Ask the type checker to pick the best one where possible.
rdar://60193198
These definitely shouldn't be showing up in symbol graphs with a minimum access
level of `public`, and it's not clear whether another minimum access level
should show these. For now, filter them unconditionally.
rdar://62081711
Subheadings for types are treated more as a title element and can't be
overloaded in the same way that other declarations can be. Abridge these
fragments to only contain the keyword and identifier.
rdar://62040714
To differentiate between freestanding extensions of protocols and matching
default implementations with their requirements. Otherwise, it's difficult to
filter out "duplicate" entries for protocols.
rdar://61459287
`SynthesizedFileUnit` is a container for synthesized declarations. Currently, it
only supports module-level declarations.
It is used by the SIL differentiation transform, which generates implicit struct
and enum declarations.
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
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
