Fixup some crate flags.

[ehuss]

There are some crates that require special compiler flags. The current implementation does not do a good job of passing these flags. It would be ideal if these could be pushed towards some kind of config somewhere. Currently they are scattered in the bootstrap code.

Some that I can think of is:

• compiler_builtins (cc Deps: compiler_builtins #15): https://github.com/rust-lang/rust/blob/8e917f48382c6afaf50568263b89d35fba5d98e4/src/bootstrap/bin/rustc.rs#L210-L214
• compiler_builtins wants a different codegen-units: https://github.com/rust-lang/rust/blob/1a1cc050d8efc906ede39f444936ade1fdc9c6cb/library/Cargo.toml#L14-L25
• panic support: https://github.com/rust-lang/rust/blob/8e917f48382c6afaf50568263b89d35fba5d98e4/src/bootstrap/bin/rustc.rs#L198-L201 (among others)

[alexcrichton]

One issue here is that when considering stabilization of -Z build-std in one form or another this'll be adding an implicit contract with upstream rust-lang/rust about building libstd and the fanciness we can control flags with. That's just always a thing we'd have to deal with though.

To actually deal with the specific issues, though:

• debug-assertions and compiler-builtins - I would ideally hope that we could handle this by configuration in Cargo.toml. We actually already tell Cargo to disable debug assertions everywhere and then they're selectively enabled via src/bootstrap/bin/rustc.rs. In general bin/rustc.rs is sort of a mess and poses a big hazard for std-aware Cargo because libstd is only built by this shim, never natively by Cargo. I would ideally like to remove the need for bin/rustc.rs entirely, but it will take us some time to get there.

• panic=abort and panic_abort - this may actually be possible to fix by just handling panic modes better (Support different panic strategies. #29), and it should be the case that if you compile panic_abort with the unwind strategy it still works, it's just not too useful.

I think all in all I'd sort of see this issue as we "we should delete bin/rustc.rs", or at least to the best extent that we can.

[alexcrichton]

As an update on this, rust-lang/rust#64316 is an attempt to move away from src/bootstrap/bin/rustc.rs as much as possible, partly to prepare for -Zbuild-std where Cargo isn't always passing loads of fancy flags to libstd.

The current shim as of now is largely just a glorified wrapper for dealing with bootstrapping and a few miscellaneous flags, plus the exact two use cases mentioned in the description of this issue. All other flags are passed in one of two locations:

• First is in Builder::cargo, which while a massive method largely just deals with the various build configurations that you can request via config.toml. There is still a risk, however, that special flags are required to build libstd which are only set on CI by accident. As of right this red hot second everything falls into the category of "dylib goop" or "build configuration that Cargo already does" so we're in the clear. Long-term I think we'll want to test, on each commit, that Cargo can indeed build libstd.

• Second is in std_cargo which is where std-specific settings are configured. This has some sanitizer nonsense as well as things related to Figure out how to handle target-specific settings. #30, but otherwise we're good for now.

I've also been trying to figure out what to do about compiler-builtins, but the only reason it's compiled with panic=abort and debug-assertions off was to fix linking issues. I can't for the life of me actually reproduce these linking issues, and I'm not entirely certain as to why. It may be a case though where we can largely sweep it under the rug until it actually comes up. In any case it should be transparently handled so fixing it wouldn't exactly constitute a breaking change.

[tmiasko]

The rust-lang/compiler-builtins#347 is one example of linking issues encountered when build-std is combined with fat LTO on a profile with debug assertions.