Introduce a [workspace.dependencies] section in the top-level Cargo.toml

[nnethercote]

It lets us avoid a lot of repetition of crate versions, etc.

I've just done a few as a start. Many more can be done in follow-ups.

r? @Kobzol

[rustbot]

Some changes occurred in src/tools/rustfmt

cc @rust-lang/rustfmt

rustc_error_messages was changed

cc @davidtwco, @compiler-errors, @TaKO8Ki

This PR changes rustc_public

cc @oli-obk, @celinval, @ouz-a

Some changes occurred in compiler/rustc_attr_parsing

cc @jdonszelmann

Some changes occurred in compiler/rustc_codegen_ssa

cc @WaffleLapkin

Some changes occurred in exhaustiveness checking

cc @Nadrieril

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

The Miri subtree was changed

cc @rust-lang/miri

Some changes occurred in src/tools/compiletest

cc @jieyouxu

Some changes occurred in compiler/rustc_sanitizers

cc @rcvalle

[Kobzol]

I think that this is a good idea that could help reduce our overall dependency count. If you remove the subtree changes, I'll r+ it.

[rustbot]

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[nnethercote]

I think that this is a good idea that could help reduce our overall dependency count.

How would it reduce our dependency count? AFAIK the benefit is avoiding repetition.

If you remove the subtree changes, I'll r+ it.

I have done this. In case it helps, here are the submodules (edited output from git submodule):

library/backtrace (0.3.75-44-gb65ab93)
src/doc/book (one-book-to-rule-them-all-2909-g3e9dc46a)
src/doc/edition-guide (remotes/origin/HEAD)
src/doc/embedded-book (remotes/origin/HEAD)
src/doc/nomicon (remotes/origin/HEAD)
src/doc/reference (remotes/origin/HEAD)
src/doc/rust-by-example (heads/master-679-gadc1f3b)
src/gcc
src/llvm-project (remotes/origin/rustc/21.1-2025-08-01)
src/tools/cargo (0.86.0-1136-g623d53683)
src/tools/enzyme
src/tools/rustc-perf (heads/master-4965-gdde879cf1)

and here are the subtrees (edited output from git log | grep git-subtree-dir):

compiler/rustc_codegen_cranelift
compiler/rustc_codegen_gcc
compiler/rustc_smir
library/portable-simd
src/tools/clippy
src/tools/miri
src/tools/rust-analyzer
src/tools/rustfmt

[RalfJung]

and here are the subtrees (edited output from git log | grep git-subtree-dir):

FWIW this is not reliable, it'll only find git subtrees but not josh-managed subtrees. Miri and clippy show up because they used to be git subtrees.

---

More importantly, this PR unfortunately broke RA for people working on Miri, clippy, or anything else that uses the rustc-dev rustup package: rust-lang/rust-analyzer#20584.

[Kobzol]

Crap, I was sure that there is in fact Cargo.toml in rustc-src, in fact I even checked for it explicitly 🤔 But I realize now that I was only checking the plain source tarballs and rust-src, not rustc-src, as it is not distributed through rustup.

[RalfJung]

There's rust-src and rustc-dev, but no rustc-src. rustc-dev should be the relevant one here, and it is distributed via rustup.

[Kobzol]

rust/src/bootstrap/src/core/build_steps/dist.rs

Line 1130 in 6864a5b

impl Step for PlainSourceTarball {

rustc-rsc is the plain source tarball 🙃 The naming is really atrocious here.

[RalfJung]

Ah 🤦

[ChayimFriedman2]

This PR also prevents now publishing of rustc crates r-a uses: https://github.com/rust-analyzer/rustc-auto-publish/actions/runs/17381310033/job/49339257240.

[nnethercote]

Is it possible to keep any of the workspace stuff or does it all need to be ripped out?

[ChayimFriedman2]

I think all of them are problematic.

Of course it's possible to make this work, but it means more work. The question is whether it is worth the effort.

[RalfJung]

For the rustc dependency usecase (making RA work with Miri/clippy/...), it should suffice to include the root Cargo.toml in the rustc-dev package -- but it can't be the original workspace Cargo.toml unchanged; it's members need to be filtered.

I don't know how the auto-publish works. I assume in general cargo supports publishing crates with workspace dependencies, and will "inline" those dependencies as part of cargo publish? The logic here does seem to download the entire source tarball as generated by github, but then for some reason moves the Cargo.toml out of the way. Sadly there's no comment explaining why. If rustc-dev has a working workspace, it might suffice to switch auto-publishing over to fetching the sources via rustup instead of directly from github.

[ChayimFriedman2]

CC @lnicola you probably know better than me the autopublish scripts.

[nnethercote]

I will just revert this change, and the related follow-ups. rust-lang/rust/ is so unlike a normal Rust project that it's not worth doing dependencies this way.

[lnicola]

AIUI, we remove the workspace manifest, update the crate manifests to rename them and fix the dependencies between crates, and publishes them individually. It's a fork of a script from 8 years ago, so I guess it's just what worked, historically.