Skip to content

Upstream Rust tools requiring rustc #1768

Open
@UebelAndre

Description

@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:

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:

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions