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://152598492
Consider the following Swift, adapted from a real-world framework:
```swift
@available(macOS 10.8, *)
@_originallyDefinedIn(module: "another", macOS 11.0)
public struct SimpleStruct {}
@available(macOS 12.0, iOS 13.0, *)
public extension SimpleStruct {
struct InnerStruct {}
}
```
In this scenario, `SimpleStruct` was originally in a module called
`another`, but was migrated to this module around the time of macOS
11.0. Since then, the module was ported to iOS and gained a nested type
`SimpleStruct.InnerStruct`. When mangling USRs for this nested type, the
result differs depending on whether we're targeting macOS or iOS.
They're mostly the same, but the macOS build yields a USR with an `AAE`
infix, designating that the `InnerStruct` was defined in an extension
from a module with the name of the base module. On iOS, this infix does
not exist.
The reason this is happening is because of the implementation of
`getAlternateModuleName` checking the availability spec in the
`@_originallyDefinedIn` attribute against the currently active target.
If the target matches the spec, then the alternate module name is
reported, otherwise the real module name is. Since the iOS build reports
the real module name, the mangling code doesn't bother including the
extension-context infix, instead just opting to include the parent
type's name and moving on.
This PR routes around this issue by passing the
`RespectOriginallyDefinedIn` variable to the
`ExtensionDecl::isInSameDefiningModule` method, and using that to skip
the alternate module name entirely. It also sets
`RespectOriginallyDefinedIn` to `false` in more places when mangling
USRs, but i'm not 100% confident that it was all necessary. The goal was
to make USRs more consistent across platforms, regardless of the
surrounding context.
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
Introduce a marker protocol SendableMetatype that is used to indicate
when the metatype of a type will conform to Sendable. Specifically,
`T: SendableMetatype` implies `T.Type: Sendable`. When strict
metatype sendability is enabled, metatypes are only sendable when `T:
SendableMetatype`.
All nominal types implicitly conform to `SendableMetatype`, as do the
various builtin types, function types, etc. The `Sendable` marker
protocol now inherits from `SendableMetatype`, so that `T: Sendable`
implies `T.Type: Sendable`.
Thank you Slava for the excellent idea!
* 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
While doing #76740 I iteratively was adding new `REQUIRES:` as new
usages of the features were found, but I did not realize that at the
same time other people might be removing some of those usages. The tests
in this commit had some `REQUIRES:` line for a previous
`-enable-experimental/upcoming-feature`, but they not longer use those
features, so the `REQUIRES:` were effectively disabling the tests (at
least in the case of `KeyPathWithStaticMembers`. In other cases they
might still had executed).
Find all the usages of `--enable-experimental-feature` or
`--enable-upcoming-feature` in the tests and replace some of the
`REQUIRES: asserts` to use `REQUIRES: swift-feature-Foo` instead, which
should correctly apply to depending on the asserts/noasserts mode of the
toolchain for each feature.
Remove some comments that talked about enabling asserts since they don't
apply anymore (but I might had miss some).
All this was done with an automated script, so some formatting weirdness
might happen, but I hope I fixed most of those.
There might be some tests that were `REQUIRES: asserts` that might run
in `noasserts` toolchains now. This will normally be because their
feature went from experimental to upcoming/base and the tests were not
updated.
* 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
Use the `%target-swift-5.1-abi-triple` substitution to compile the tests for
deployment to the minimum OS versions required for use of _Concurrency APIs,
instead of disabling availability checking.
10.50 was once greater than any real macOS version, but now it compares
less than real released versions, which makes these tests depend on the
deployment target unnecessarily. Update these tests to use even larger
numbers to hopefully keep them independent a little longer.
The legacy `module.map` spelling of module map files was deprecated by llvm/llvm-project#75142 and clang expects to remove support for them in the future. Switch all tests to use the supported spelling.
Fixes rdar://128431478.
For example when we have
```swift
protocol BaseProtocol {}
extension BaseProtocol {
/// Say hello
func hello() { }
}
struct MyStruct: BaseProtocol {
func hello() {}
}
```
Then `MyStruct.hello` should inherit the doc comment from the implementation of `BaseProtocol.hello`. Currently no doc comment is associated with `MyStruct.hello`.
rdar://126240546
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`
