-
Notifications
You must be signed in to change notification settings - Fork 129
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for symbol graph extraction #772
base: master
Are you sure you want to change the base?
Conversation
keith
commented
Mar 3, 2022
•
edited by brentleyjones
edited by brentleyjones
- d41cdb9
- 47a02f1
- 39dfb23
- 3e90cda
This change adds the following APIs: * An aspect, `swift_symbol_graph_aspect`, which can traverse a dependency graph and extract symbol graphs from Swift modules that it finds. The results are propagated in a `SwiftSymbolGraphInfo` provider. * A rule, `swift_extract_symbol_graph`, which applies the above aspect to one or more targets and combines the results into a single directory. * A low-level Starlark API, `swift_common.extract_symbol_graph`, which creates the action to invoke `swift-symbolgraph-extract` on a single `.swiftmodule`. PiperOrigin-RevId: 430517714
blocked on infra changes that are blocked on aspect_hints |
Lyft integration job started: https://buildkite.com/lyft/rules-swift/builds/248 (must be Lyft employee to view) |
… not using bundled tests (i.e., not Objective-C-runtime-based XCTest) and has no `srcs`. PiperOrigin-RevId: 430526469
…subclasses and their methods from symbol graphs and generate the necessary runner. This is similar to the logic used by Swift Package Manager to do test discovery, except that SPM uses the index store. We use symbol graphs since JSON is much easier to process than index store records and they can be easily extracted from modules after they've been built. Note to open-source rules maintainers: You will need to provide BUILD definitions for swift-argument-parser and swift-docc-symbolkit in order to populate these dependencies. PiperOrigin-RevId: 430518889
… in extensions. This prevents a collision when one discovered test class subclasses another. SwiftPM at HEAD currently doesn't do this (it used to), leading to bugs like SR-15955. This seems like a regression, so I'm fixing it in our tool. PiperOrigin-RevId: 433481652
yea unclear. it's probably quicker if you're worried about it to handle the merge conflicts with cherry picking that commit as I did for the other ones related to compiler plugins |
I'm updating this PR |
9e46353
to
9de9e02
Compare
@jpsim This adds a different way of extracting symbol graphs. It also changes the name of the directory for
|
9de9e02
to
671296e
Compare
_maybe( | ||
http_archive, | ||
name = "com_github_apple_swift_docc_symbolkit", | ||
urls = ["https://github.com/apple/swift-docc-symbolkit/archive/refs/tags/swift-5.10-RELEASE.tar.gz"], | ||
sha256 = "de1d4b6940468ddb53b89df7aa1a81323b9712775b0e33e8254fa0f6f7469a97", | ||
strip_prefix = "swift-docc-symbolkit-swift-5.10-RELEASE", | ||
build_file = "@build_bazel_rules_swift//third_party:com_github_apple_swift_docc_symbolkit/BUILD.overlay", | ||
) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't like adding another non-bzlmod dependency. I assume we should add this to BCR like com_github_apple_swift_argument_parser
?
This change adds the following APIs: * An aspect, `swift_symbol_graph_aspect`, which can traverse a dependency graph and extract symbol graphs from Swift modules that it finds. The results are propagated in a `SwiftSymbolGraphInfo` provider. * A rule, `swift_extract_symbol_graph`, which applies the above aspect to one or more targets and combines the results into a single directory. * A low-level Starlark API, `swift_common.extract_symbol_graph`, which creates the action to invoke `swift-symbolgraph-extract` on a single `.swiftmodule`. PiperOrigin-RevId: 430517714 (cherry picked from commit d41cdb9)
…subclasses and their methods from symbol graphs and generate the necessary runner. This is similar to the logic used by Swift Package Manager to do test discovery, except that SPM uses the index store. We use symbol graphs since JSON is much easier to process than index store records and they can be easily extracted from modules after they've been built. Note to open-source rules maintainers: You will need to provide BUILD definitions for swift-argument-parser and swift-docc-symbolkit in order to populate these dependencies. PiperOrigin-RevId: 430518889 (cherry picked from commit 47a02f1)
… not using bundled tests (i.e., not Objective-C-runtime-based XCTest) and has no `srcs`. PiperOrigin-RevId: 430526469 (cherry picked from commit 39dfb23)
… in extensions. This prevents a collision when one discovered test class subclasses another. SwiftPM at HEAD currently doesn't do this (it used to), leading to bugs like SR-15955. This seems like a regression, so I'm fixing it in our tool. PiperOrigin-RevId: 433481652 (cherry picked from commit 3e90cda)
Should non-Xcode toolchains support |
671296e
to
4d91e55
Compare
I got confirmation that the Linux toolchain isn't being upstreamed anymore. So there are parts we need to do here for that. |
This symbol graph rule also seems to better support extending the symbol graph (e.g. with minimum access level attr). Theres more flags related to symbol graph generation we could add too, such as the one required to support: bazelbuild/rules_apple#2445. I have a work-in-progress PR that adds |
I would like to get @jpsim's thoughts on this. |
I'm no longer involved with any projects that would use this or the previous symbol extraction for DocC. If this is what's upstreamed and sounds like more useful than we have today, then I'm all for cherry-picking it in. |