Build host dependencies with opt-level 0 by default

[alexcrichton]

This commit updates Cargo's build of host dependencies to build them
with optimization level 0 by default instead of matching the profile of
the final binary.

Since Cargo's inception build dependencies have, by default, been built
in a profile that largely matches the profile of the final target
artifact. Build dependencies, however, rarely actually need to be
optimized and are often executing very small tasks, which means that
optimizing them often wastes a lot of build time. A great example of
this is procedural macros where syn and friends are pretty heavyweight
to optimize, and the amount of Rust code they're parsing is typically
quite small, so the time spent optimizing rarely comes as a benefit.

The goal of this PR is to improve build times on average in the
community by not spending time optimizing build dependencies (build
scripts, procedural macros, and their transitive dependencies). The PR
will not be a universal win for everyone, however. There's some
situations where your build time may actually increase:

• In some cases build scripts and procedural macros can take quite a
  long time to run!
• Cargo may not build dependencies more than once if they're shared with
  the main build. This only applies to builds without --target where
  the same crate is used in the final binary as in a build script.

In these cases, however, the build-override profile has existed for
some time know and allows giving a knob to tweak this behavior. For
example to get back the previous build behavior of Cargo you would
specify, in Cargo.toml:

[profile.release.build-override]
opt-level = 3

or you can configure this via the environment:

export CARGO_PROFILE_RELEASE_BUILD_OVERRIDE_OPT_LEVEL=3

There are two notable features we would like to add in the future which
would make the impact of a change like this smaller, but they're not
implemented at this time (nor do we have concrete plans to implement
them). First we would like crates to have a way of specifying they
should be optimized by default, despite default profile options. Often
crates, like lalrpop historically, have abysmal performance in debug
mode and almost always (even in debug builds) want to be built in
release mode. The second feature is that ideally crate authors would be
able to tell Cargo to minimize the number of crates built, unifying
profiles where possible to avoid double-compiling crates.

At this time though the Cargo team feels that the benefit of changing
the defaults is well worth this change. Neither today nor directly after
this change will be a perfect world, but it's hoped that this change
makes things less bad!

[joshtriplett]

I posted #8501 for an option a crate can use to recommend optimization, and #8502 to avoid building shared build-time and runtime dependencies twice.

Suggested release-note language:

When building build-time dependencies, which will not be invoked at runtime,
Cargo now defaults to opt-level 0, to reduce build time. If you have a
dependency used only at build time, but it still benefits enough from
optimization to outweigh the time taken to optimize it, you can override
this for an individual crate with:
```toml
[profile.release.package.cratename]
opt-level = 3
```
If you have crates that should almost always be optimized, even when used as a
build-time-only dependency, consider contributing to [cargo issue
8501](https://github.com/rust-lang/cargo/issues/8501) to provide a way to mark
those crates. If you have crates that are used at both build-time and runtime,
consider contributing to [cargo issue
8502](https://github.com/rust-lang/cargo/issues/8502) to build such crates just
once, with optimization. The Cargo team would greatly appreciate your
contributions.

[Eh2406]

As discussed in the meeting:
@bors r+

[bors]

📌 Commit dc4b695 has been approved by Eh2406

[bors]

⌛ Testing commit dc4b695 with merge 2a64ae8...

[bors]

☀️ Test successful - checks-actions
Approved by: Eh2406
Pushing 2a64ae8 to master...

[matklad]

drive-by comment, but we might also want to disable debuginfo generation for host deps, as that takes quite a bit of disk space otherwise.

[alexcrichton]

That was one thing I considered, yeah, but ended up not doing it just yet. I don't think we'd want to disable debuginfo because it's required for line numbers in backtraces, but -Cdebuginfo=1 should in theory be quite a bit smaller than -Cdebuginfo=2. It felt a bit odd though to change dev builds because it's another vector for causing double compilations (today you might share artifacts but tomorrow you'd rebuild build deps with -Cdebuginfo=1 and two). That was enough to make me hesitate and not land it in this round, but as an idea I think it'd be good to land!

[ehuss]

Sorry, bit behind on reviews. I finally had a chance to look at this. This doesn't seem to work if the user has not explicitly set a profile, was that intended?

FWIW, I ran some benchmarks with a patched cargo on a handful of projects, and it seemed to be uniformly faster.

[alexcrichton]

Oh dear that is indeed a bug, my mistake! I think I see a fix as well, let me try to get that with a test up tomorrow

[teohhanhui]

If I set:

RUSTFLAGS="-C opt-level=2 -C target-cpu=native"

would that affect the build dependencies as well?

[bjorn3]

Yes, but only if you don't pass --target to cargo. Otherwise it only applies to the crates built for the target.