Resolves rdar://151911998
This PR addresses an uncommon situation in the symbol graph when
importing Objective-C symbols into Swift. When a class conforms to a
protocol that includes an initializer, that initializer is automatically
generated for that class in the AST. This initializer has the same USR
as the original protocol symbol, but is housed in a different
DeclContext to indicate the membership.
Right now, we catch this situation when the protocol conformance is
declared on the class definition: There's a branch to check for
"implicit" decls with an underlying Clang symbol, and creates a
synthesized USR if that symbols DeclContext points to a type. However,
when the protocol conformance is added in a category extension, the
DeclContext for the generated initializer points to the extension,
causing the symbol to bypass that check and get added to the symbol
graph with a duplicated USR. This PR adds a check to look for
ExtensionDecls as the DeclContext so that the symbol can correctly
receive a synthesized USR.
One of the tests in this PR
(`SymbolGraph/ClangImporter/ObjCInitializer.swift`) tests a similar
situation where this "implicit decl with a Clang node" is created: Some
initializers in Objective-C get imported into Swift twice, with
differently-adapted parameter names. This is covered by the original
code, but i wanted to leave the test in because i broke this case in my
initial investigation! 😅 The other test
(`SymbolGraph/ClangImporter/ProtocolInitializer.swift`) tests the new
behavior that is fixed by this PR.
Resolves rdar://152676102
In Objective-C, it's reasonable to sort extensions of your dependency's
types into headers that match the name of that type. However, this runs
into a bug in SymbolGraphGen when it comes time to generate Swift symbol
graphs for that Objective-C code: At the moment, it only differentiates
between modules based on their base name, regardless of their parent
modules (if any). This causes these extensions to be incorrectly sorted
into the _extending module's_ symbol graph, rather than in an extension
symbol graph where it can be displayed with the _extended module_. When
processed with Swift-DocC, it would cause these symbols to disappear.
This PR updates the `areModulesEqual` function used by the
`SymbolGraphASTWalker` to consider the fully-qualified module name for
comparisons, rather than just the module's base name, causing situations
like the test's `Dependency.DependencyClass` and
`HeaderCollision.DependencyClass` to be properly distinguished from each
other.
The Error enum synthesized declarations, e.g. the struct and its static accessors, should generally appear to be identical to the underlying Clang definitions. There are some specific use cases where the synthesized declarations are necessary though.
I've added an option for USR generation to override the Clang node and emit the USR of the synthesized Swift declaration. This is used by SwiftDocSupport so that the USRs of the synthesized declarations are emitted.
Fixes 79912
* 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
* treat children of underscored protocols as public
Children of underscored protocols should be treated as native children
of their conforming types. To accomplish this, ignore underscored
protocols in the isInherentlyPrivate check.
rdar://124483146
* include underscored protocol methods even when skipping protocols
rdar://128143861
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
`module.map` as a module map name has been discouraged since 2014, and
Clang will soon warn on its usage. This patch renames all instances of
`module.map` in the Swift tests to `module.modulemap` in preparation
for this change to Clang.
rdar://106123303
The code of `ScanDependencies.cpp` was creating invalid JSON since #66031
because in the case of having `extraPcmArgs` and `swiftOverlayDependencies`,
but not `bridgingHeader`, a comma will not be added at the end of
`extraPcmArgs`, creating an invalid JSON file. Additionally that same PR
added a trailing comma at the end of the `swiftOverlayDependencies`, which
valid JSON does not allow, but that bug was removed in #66366.
Both problems are, however, present in the 5.9 branch, because #66936
included #66031, but not #66366.
Besides fixing the problem in `ScanDependencies.cpp` I modified every test
that uses `--scan-dependencies` to pass the produced JSON through
Python's `json.tool` in order to validate proper JSON is produced. In
most cases I was able to pipe the output of the tool into `FileCheck`,
but in some cases the validation is done by itself because the checks
depend on the exact format generated by `--scan-dependencies`. In
a couple of tests I added a call to `FileCheck` that seemed to be
missing.
Without these changes, two tests seems to be generating invalid JSON in
my machine:
- `ScanDependencies/local_cache_consistency.swift` (which outputs `Expecting ',' delimiter: line 525 column 11 (char 22799)`)
- `ScanDependencies/placholder_overlay_deps.swift`
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)
