Although the declaration of macros doesn't appear in Swift source code
that uses macros, they still operate as declarations within the
language. Rework `Macro` as `MacroDecl`, a generic value declaration,
which appropriate models its place in the language.
The vast majority of this change is in extending all of the various
switches on declaration kinds to account for macros.
Custom attributes were being skipped as their attribute name started
with a "_". Underscored attributes are typically unstable and thus
shouldn't be printed, but "_" is not being used for that purpose in the
case of "_custom".
Rather than checking for "_" or "__", just use `UserInaccessible`. This
property is used for attributes that shouldn't be shown to users in eg.
completion/printing/etc.
Resolves rdar://99029554.
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
* Revert "Revert "consider requirements of an underscored protocol to also be underscored""
* make SkipsPublicUnderscore more resilient to non-determinism
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
