Currently symbol graphs are always written in files that contain 1 to 2
module names. It's possible for Swift module names to be very long, so
combining 2 of them in file name like `module1@module2...` in the same
path component means the name can be too long for some file systems. The
new option `-symbol-graph-shorten-output-names` changes the symbol graph
output files to use a MD5 hash of the module name(s) as the filename and
outputs an additional JSON file with the original names mapped to the
real filename. The module names JSON can be used to construct a VFS
overlay with the original naming scheme.
fix#83723
I considered using vfsoverlay, which seems like a viable solution, but
the vfsoverlay options don't seem to apply to any of the outputs from
the compiler. When I set an overlay to remap the symbol graph file
outputs, the remapped external paths aren't used so the root problem of
too long file names remains.
Having a test for this was a nice idea but there just doesn't seem like there's
a way to test it reliably given that cross compilation happens in a wide
variety of CI bot configs.
Resolves rdar://157170133.
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.
