bazelbuild / bazelbuild/rules_rust
FR: support for linking via cc_common.link
- Dominant language
- Starlark
- Stars
- 843
- Forks
- 651
- Avg merge
- 2d 18h
- Merged PRs (30d)
- 15
Description
We would like to add support to rules_rust for linking rust binaries via the [cc_common.link](https://docs.bazel.build/versions/main/skylark/lib/cc_common.html) Bazel mechanism. This feature would allow for better cross-language interoperability and make it easier to provide cross-language integration of features like LTO and sanitizer support by adapting the rust compilation pipeline to produce actions and artifacts that are more uniform with other languages' rules implementation from Bazel point of view.
This feature should co-exist with the existing rules_rust mechanism that uses rustc as the linker driver, since there are use cases where rustc as the driver makes sense. For projects that are mostly written in rust using rustc-as-a-driver is simpler to set up and more flexible with respect to features such as custom rust allocator support. The use of cc_common.link would require a fully configured C++ toolchain and custom allocator library for example.
Initially we'd like to experiment with this and focus on rust_binary and rust_test, possibly extending the support to other targets that require linking in the future.
As a rough design, we'd like to be able to control the default linking mechanism on a rust_toolchain level, and additionally be able to selectively override the behavior on a per-target basis until the feature is complete.
We'd add
* a new boolean build setting `--//rules_rust/rust/settings:experimental_use_cc_common_link`, defaulting to false,
* a new `rust_toolchain` label attribute `experimental_use_cc_common_link`, defaulting to the build setting above.
* a new temporary int rust_{binary|test|shared_library}.experimental_use_cc_common_link attribute with possible values `[-1, 0, 1]` to rust_binary and other crate types that require linking, defaulting to -1. This is to support gradually moving targets t/from using the new feature; after the feature is stable, we'll remove this attribute.
Given rust `rust_{binary|...}(name = bin)`, and a `rust_toolchain`, common_cc.link is enabled if:
* `bin.experimental_use_cc_common_link` is 1, or
* `bin.experimental_use_cc_common_link` is -1 and `rust_toolchain.experimental_use_cc_common_link` points to a label whose value is true.
Otherwise common_cc.link is disabled.
When enabled, instead of emitting one rustc_compile_action that does both compilation and linking using `rustc`, we will emit 2 actions:
* A rustc one with [`–emit=obj`](https://doc.rust-lang.org/rustc/command-line-arguments.html#--emit-specifies-the-types-of-output-files-to-generate) to produce an .o file
* A `cc_common.link` one to produce the final binary (or appropriate binary artefacts for other crates that require linking).
We'll focus on `rust_binary` first, then `rust_test`, then possibly `rust_shared_library`. After linking with `cc_common.link` has been stabilized, we'll drop the `experimental_` suffix from the build setting and the `rust_toolchain` attribute and drop the rust_{binary|...} attribute.
Contributor guide
Assessment
This issue has not been assessed yet.