Upstream Rust tools requiring rustc

[UebelAndre]

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:

• Added Rust 1.66.1 #1767
• Enable experimental_individual_tool_repositories #1163
• Splitting `rust_toolchain` into multiple toolchains #815

[UebelAndre]

cc @illicitonion @scentini @krasimirgg for thoughts 🙏

[UebelAndre]

I've also not done any bisecting at this time to find what the specific change was between rust-nightly-2022-12-15 and rust-nightly-2023-01-11 that introduced the failure found in https://buildkite.com/bazel/rules-rust-rustlang/builds/7852#0185a41a-1067-4ffb-a137-bc08cb6ca567

[UebelAndre]

An additional data-point. The hope in splitting rust_toolchain into multiple toolchains/repositories was to be able to register toolchains vai the rust_register_toolchains macro that would power various rules and aspects defined in rules_rust without consumers of the repo needing to do additional configuration for them. Bazel's ability to skip downloading unnecessary repositories is very powerful and it'd be ideal if the rust_toolchain not required for compilation could be gated behind that same mechanism.

[UebelAndre]

e38d0aa is a fix to the issue in the original post and a demonstration of the change I'm asking for additional thoughts on.

#1769 is a pull-request for just this change.

[krasimirgg]

It's kinda unfortunate that we'll need a rustc for a rustfmt_toolchain_repository...

Just to clarify, the issue from above w.r.t. rustfmt being unable to locate librustc-driver.so is just about not being able to locate librustc-driver.so, not the rustc binary itself, right? (and I assume the same issue would be for clippy and rust-analyzer, since they also dynamically link the librustc-driver.so.)
So maybe we can carve out and download just these main .so files required for the various rust_foo_toolchain-s with some sort of mapping where they need to be located relative to the binaries... with all of this functionality being optional: it's possible to manually build versions of the rustfmt etc binaries that statically link the driver code (by manually changing the crate type of the rustc_driver code to an rlib during x.py toolchain bootstrapping). In cases like this standalone binaries would be sufficient.

[titanous]

This upstream change also broke bazel-bin/external/rust_linux_x86_64__x86_64-unknown-linux-gnu__stable_tools/rust_toolchain/bin/rustfmt, which we use from rust-analyzer, with the same error:

error while loading shared libraries: librustc_driver-23b27f3d25796dfb.so: cannot open shared object file: No such file or directory

[jgao54]

we just encountered this issue as above when trying to upgrade to 0.22:

$(bazel info output_base)/external/rust_linux_x86_64__x86_64-unknown-linux-gnu__stable_tools/bin/rustfmt is failing with

rustfmt: error while loading shared libraries: librustc_driver-e9ace2a97781a33e.so: cannot open shared object file: No such file or directory

On rust version 1.65

Update: was able to work around this by specifying rustfmt_version to match versions specified in rust_register_toolchains rule.