Description
Over the last few years I've made some changes that attempt to split the current rust_toolchain
into multiple toolchains for components that are not typically required for compiling Rust code:
- Added
rustfmt_toolchain
and refactored toolchain repository rules #1719 - Generated rust-project.json files now include sysroot paths #1641
I'm starting to wonder if this is going against the grain. I'd recently opened #1767 and noticed build failures related to rustfmt
being unable to locate librustc-driver.so
(03:52:05) ERROR: /workdir/test/unit/debug_info/BUILD.bazel:4:31: Rustfmt test/unit/debug_info/myrusttest.rustfmt.ok failed: (Exit 127): process_wrapper failed: error executing command (from target //test/unit/debug_info:myrusttest)
(cd /var/lib/buildkite-agent/.cache/bazel/_bazel_buildkite-agent/ec321eb2cc2d0f8f91b676b6d4c66c29/sandbox/linux-sandbox/494/execroot/rules_rust && \
exec env - \
bazel-out/k8-opt-exec-2B5CBBC6/bin/util/process_wrapper/process_wrapper --touch-file bazel-out/k8-fastbuild/bin/test/unit/debug_info/myrusttest.rustfmt.ok -- external/rustfmt_nightly-2023-01-11__x86_64-unknown-linux-gnu_tools/bin/rustfmt --config-path tools/rustfmt/rustfmt.toml --edition 2018 --check test/unit/debug_info/test.rs)
# Configuration: 362aedf4f02f267774e1298e2f5c5c0104ab07a0e4251fe83fadf56f37f2e212
# Execution platform: @local_config_platform//:host
Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
external/rustfmt_nightly-2023-01-11__x86_64-unknown-linux-gnu_tools/bin/rustfmt: error while loading shared libraries: librustc_driver-dc7808dac7cc7897.so: cannot open shared object file: No such file or directory
I'd noticed in the past that clippy
also has issues working without rustc
being installed (not symlinked) relative to the location of the clippy-driver
binary. While I still think it would be ideal for each tool the Rust org ships (cargo, clippy, rust-analyzer, rustfmt) to exist as it's own toolchain that's only downloaded when needed. There seems to be more reasons to download all tools to one place as more and more things are requiring rustc
.
That said, I'm wondering if it would make more sense to do away with things like rustfmt_toolchain
and rust_analyzer_toolchain
and to instead download all components into one toolchain.
An alternative could be downloading duplicate artifacts, which, in practice, would only result in extracting the same archives into multiple directories. This is something that's already been explored in #1641 by adding rustc
directly to rust_analyzer_toolchain_repository
but may not be ideal as now there's a potential for multiple rustc
binaries with drifting versions.
I'm wondering if other folks have suggestions on how to handle the errors mentioned above and what to do about the Rust org seemingly expanding reliance on rustc
. I don't necessarily have an issue with that, but want to do what I can to minimize time spent in the analysis phase and ensure no unnecessary inputs are included in Rustc
actions.
Other related issues: