rules_swift
rules_swift copied to clipboard
bazelbuild
Add support for symbol graph extraction
- d41cdb923c8dff27570709add2838c3e4c8e40ff
- 47a02f143a93f3f2ef8e61c69a634ad042c652bf
- 39dfb233289c78a73c37d27b7275cb17a06ecebc
- 3e90cda20649d1f729524ffecf787d63c5a65acf
Lyft integration job started: https://buildkite.com/lyft/rules-swift/builds/248 (must be Lyft employee to view)
@keith is this still blocked? Im trying to cherry-pick 6cae838e1fcbcc344fa2a29dc272261e719cba6e which has some dependencies on this for swift_test
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
@jpsim This adds a different way of extracting symbol graphs. It also changes the name of the directory for derived_files.symbol_graph_directory (to match what was used upstream), and I'm not sure if that could cause a clash if your feature is also enabled while using the new rule/aspect. So, two questions:
- Does this new stuff replace the need for your existing stuff?
- If not, is there anything that should be changed here, to ensure that they work well together (including potential doc changes)?
Should non-Xcode toolchains support swift_action_names.SYMBOL_GRAPH_EXTRACT?
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: https://github.com/bazelbuild/rules_apple/issues/2445.
I have a work-in-progress PR that adds -emit-extension-block-symbols via a swift.emit_symbol_graph_extension_blocks feature but using an attr in this new rule makes more sense. Do we think the change to the existing symbol graph code is worth making or should we wait for this new rule? Do we think this will land soon
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.
