Default flags and environment variables

[ehuss]

This issue is for working through the implementation issues for determining the default flags passed to rustc for the standard library.

Currently the standard library is built in a relatively straightforward fashion, like any normal Cargo project. However, there are a number of extra rustc flags and environment variables that can be passed to different crates.

The initial implementation will likely need to duplicate some of this logic, but long term I think it would be ideal to avoid duplicating it. We will need to explore how to avoid that. We may also want to consider if we ever want the user to be able to control some of these options.

The bulk of the logic is in rustc.rs with some additional in compile.rs and elsewhere.

[SimonSapin]

Presumably some configuration file needs to be shipped with the rust-src component, like for #13.

[Ericson2314]

I recall that most of this stuff isn't necessary in "normal" situations? At least it wasn't when building core and alloc. Things relating to working around the bootstrap compiler shouldn't matter because users are are using the "final" up-to-date compiler.

[alexcrichton]

This likely has a lot of overlap with #28, notably #28 (comment)

[adamgemmell]

I think the current situation is a lot better than it was when the issue was written, largely due to Eric and Alex's work at the time. @harmou01 did some work to compare the flags and variables bootstrap and cargo -Z build-std use and I think we were able to justify the differences.

This only looked at very common targets. You might think there's lots of if target.contains blocks in bootstrap that set codegen options, but I was only able to find the one, which is only set to let people avoid build-std. Other target-specific blocks seem to build native deps, link in some directories or do other things required to build anything on that target - not that these aren't problems for build-std but they don't fall under this issue.

For completeness, these flags are all different between x.py and Cargo’s -Zbuild-std, but the differences are justifiable.

Codegen (-C):

• debuginfo - distributed std uses 1, cargo uses 2 or 0 for release/debug builds.
• prefer-dynamic - bootstrap builds std as a shared library, Cargo uses static.
• opt-level - always distributed as 3, locally obviously depends on the profile.
• symbol-mangling-version - looks like one job, x86_64 gnu tools, sets this to v0. Otherwise it uses legacy. Clearly std needs to use the same format as other crates in the binary.
• split-debuginfo - this is platform-specific. Clearly std needs to use the same format as other crates in the binary.
• codegen-units - std is distributed with 1, locally this depends on the profile.
• embed-bitcode - the default is yes, and cargo overrides it for non-lto builds.
• force-frame-pointers - bootstrap sets frame pointers to true to distribute std as a safe default to avoid clobbering the fp register - force-frame-pointers flag isn't honored always unless std is recompiled as such rust#103711 (comment). Locally, cargo knows better and can set it for std if required.

These flags are set by bootstrap, but they’re unstable so Cargo cannot:
macro-backtrace, inline-mir, inline-mir-preserve-debug, binary-dep-depinfo

Std crate features are inherently unstable and so can’t currently be set by Cargo. Bootstrap sets a few, such as compiler-builtins-c, profiler/profiler_builtins, since it knows it has a C compiler and will generate PGO profiles. In general these need to be stabilised and then Cargo can go about exposing them or turning some on with its own knowledge.

I found two hardcoded behaviours in Cargo that check Unit.is_std:

• -Z force-unstable-if-unmarked, which comes with a RUSTC_BOOTSTRAP hack on every build command. This would be great to remove but I haven't yet properly understood it. Is it actually necessary to mark std crates.io dependencies as unstable? If not, we could manually mark rustc crates as unstable and with the rustc_private feature and remove this flag.
• Throwing away the dylib crate type that std declares itself as - not really under this issue, but nice to remove. I haven't dug into it yet.