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
Otherwise, the `SourceManager` may skip over a blank line, causing
it to have a line number off by one.
Measure initial indentation from the first non-blank line.
rdar://61827368
This was just using `hasUnderscoredNaming` before but this only checks the
leafmost type. When filtering extended types, it should continue to look up
through nesting types to see if they are also implicitly private.
rdar://61843516
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
To ease the burden on the client, ignore some generic requirements involving
Self. For example, `Self: P` where we already know that `Self` conforms to `P`.
An example case:
```
public struct S: Equatable {
public static func ==(lhs: S, rhs: S) -> Bool { ... }
}
```
`!=` is defined in terms of `Self` and the default implementation has a `Self:
Equatable`. For the purposes of documentation, it's not necessary to specify
that again on the page of documentation for `!=`.
rdar://60963924
`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.
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
Symbol graph files are processed per platform--documentation for symbols that
are unconditionally unavailable or obsoleted on a platform shouldn't be shown
for that same platform.
Also, removes `isUnconditionallyUnavailable` from the JSON format. If it's
unconditionally unavailable, it won't show up at all.
rdar://60193675
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
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
Use specific operations for setting the compile flags, link flags,
linked libraries, and library search paths. This allows us to use CMake
more effectively, simplifies the logic, and will ensure that flags are
not duplicated.
Add a platform kind and availability attributes for macCatalyst. macCatalyst
uses iOS version numbers and inherits availability from iOS attributes unless
a macCatalyst attribute is explicitly provided.
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
