The total Rust archive size has intensified recently

[tesuji]

Edit:

I forgot that with nightly, I also installed clippy, rustfmt, musl target.
The new edit will not contains those.

The total Rust archive size has intensified recently.

% rustc +nightly-2019-07-07-x86_64-unknown-linux-gnu -V
rustc 1.38.0-nightly (dfd52ba6a 2019-07-06)
% du -sch ~/.rustup/toolchains/nightly-2019-07-07-x86_64-unknown-linux-gnu
868M    /home/lzutao/.rustup/toolchains/nightly-2019-07-07-x86_64-unknown-linux-gnu
868M    total

% rustc +nightly-2019-07-08-x86_64-unknown-linux-gnu -V
rustc 1.38.0-nightly (6e310f2ab 2019-07-07)
% du -sch ~/.rustup/toolchains/nightly-2019-07-08-x86_64-unknown-linux-gnu
1.1G    /home/lzutao/.rustup/toolchains/nightly-2019-07-08-x86_64-unknown-linux-gnu
1.1G    total

Is this a regression caused by #59800 ?
cc @Zoxc (for the PR), @Centril (infra team)

[Zoxc]

Yes, this is an expected regression by #59800.

[mati865]

See also #61978

[est31]

This contains justification of the change: #56987 (comment)

This contains suggestions on decreasing the size: #56987 (comment)

There are big improvements in compilation speed, but mostly only startup improvements (relative speedup increasing the smaller the crate is), which makes sense if you read the comment by @alexcrichton I've linked above: there is less work to do at load time of the binary.

[eddyb]

My own suggestion: #59800 (comment) - reproduced below:

Has shipping .rmeta instead of .rlib been considered?
We would have to either include MIR for everything and codegen at the end (potentially subopyimal) or just throw away the .rlib and somehow require the final .so crate to be linked in order to use anything from the component crates.
For the latter, it could be as simple as a check like "at least one of the dependency crates must claim to contain each symbol referenced and be linkable".