Help test rustc-dev component splitting

#1

The release team is hoping to reduce the size of std installs/tarballs for most users, but the last time we tried to enable this we ran into some bugs in the implementation. We'd like to ask users to test via this command: RUSTUP_DIST_SERVER=https://dev-static.rust-lang.org rustup toolchain install nightly-2019-10-16 (only that specific nightly will work) and report back on this thread if you run into any problems. We're not quite sure what might break so the "expected" testing is hard to define, but just using that nightly in the daily workflow for a single 'build' is likely to expose any bugs.

Testing can likely look something like cargo +nightly-2019-10-16 ... or rustup default nightly-2019-10-16 (can be reverted with e.g. rustup default stable).

If you'd like some more context, see the latest PR we hope to land, and the original PR.

5 Likes
#2

In particular, if you normally use a Tier 2 or 3 non-x86 target, testing would be helpful!

1 Like
#3

The command should include rustc-dev component if one want to test clippy or rustfmt:

rustup set profile minimal
RUSTUP_DIST_SERVER=https://dev-static.rust-lang.org rustup toolchain install nightly-2019-10-16 -c rustc-dev
#4

Tested on Aarch64 little-endian system by building clippy and rustup. Everything looks good.

#5

To be clear, you should not need to include the rustc-dev component to use clippy/rustfmt/RLS -- that is the critical thing here. We should also be able to build the tools if the component is added, but that's less critical to test.

#6

Compiled and ran successfully in ppc64le linux system