fix building libstd without backtrace feature

[RalfJung]

Fixes#64410

r? @alexcrichton

[alexcrichton]

Thanks! I think this ended up having a bit more #[cfg] than I was hoping for though. Could this perhaps go for an alternative strategy where libstd always depends on the backtrace crate, but only if the standard library's backtrace feature is enabled does it actually enable features of backtrace? If you remove all features from backtrace-the-crate it should basically compile anywhere since it's just a bunch of empty stubs, and that should remove any need for #[cfg] here.

[RalfJung]

@alexcrichton is backtrace without any features Rust-only, or does it still need a C toolchain?
Right now, libstd without features can be built without a C toolchain, which would be nice to preserve I think (once we no longer build a dylib, that makes cross-compilation so much simpler).

[RalfJung]

@alexcrichton I implemented your suggestion. However, for reasons I do not understand, it still builds "backtrace-sys" even when the backtrace feature is not set:

 Updating crates.io index
Compiling core v0.0.0 (/home/r/src/rust/rustc.2/src/libcore)
Compiling compiler_builtins v0.1.19
Compiling libc v0.2.62
Compiling cc v1.0.45
Compiling build_helper v0.1.0 (/home/r/src/rust/rustc.2/src/build_helper)
Compiling cmake v0.1.42
Compiling unwind v0.0.0 (/home/r/src/rust/rustc.2/src/libunwind)
Compiling backtrace-sys v0.1.31
Compiling rustc_tsan v0.0.0 (/home/r/src/rust/rustc.2/src/librustc_tsan)
Compiling rustc_asan v0.0.0 (/home/r/src/rust/rustc.2/src/librustc_asan)
Compiling rustc_msan v0.0.0 (/home/r/src/rust/rustc.2/src/librustc_msan)
Compiling rustc_lsan v0.0.0 (/home/r/src/rust/rustc.2/src/librustc_lsan)
Compiling std v0.0.0 (/home/r/src/rust/rustc.2/src/libstd)
Compiling rustc-std-workspace-core v1.99.0 (/home/r/src/rust/rustc.2/src/tools/rustc-std-workspace-core)
Compiling cfg-if v0.1.8
Compiling alloc v0.0.0 (/home/r/src/rust/rustc.2/src/liballoc)
Compiling rustc-demangle v0.1.16
Compiling panic_abort v0.0.0 (/home/r/src/rust/rustc.2/src/libpanic_abort)
Compiling backtrace v0.3.37
Compiling rustc-std-workspace-alloc v1.99.0 (/home/r/src/rust/rustc.2/src/tools/rustc-std-workspace-alloc)
Compiling panic_unwind v0.0.0 (/home/r/src/rust/rustc.2/src/libpanic_unwind)
Compiling hashbrown v0.5.0
Finished release [optimized] target(s) in 26.09s
Compiling rustc-std-workspace-std v1.99.0 (/home/r/src/rust/rustc.2/src/tools/rustc-std-workspace-std)
Compiling proc_macro v0.0.0 (/home/r/src/rust/rustc.2/src/libproc_macro)
Compiling term v0.0.0 (/home/r/src/rust/rustc.2/src/libterm)
Compiling unicode-width v0.1.6
Compiling getopts v0.2.21
Compiling test v0.0.0 (/home/r/src/rust/rustc.2/src/libtest)
Finished release [optimized] target(s) in 10.36s

[RalfJung]

Ah, I suppose the reason is this in backtrace's Cargo.toml:

rustc-dep-of-std = ["backtrace-sys/rustc-dep-of-std", "cfg-if/rustc-dep-of-std", "core", "compiler_builtins", "libc/rustc-dep-of-std", "rustc-demangle/rustc-dep-of-std"]

[alexcrichton]

Looks great! Just one minor nit and otherwise r=me

[RalfJung]

@alexcrichton done (I made log_backtrace default to None instead of trying to reorganize the code).

@bors r=alexcrichton

However, do you have any idea how we could avoid building backtrace-sys when the backtrace feature is not set? Seems like currently, setting the rustc-dep-of-std feature flag of the backtrace crate also enables backtrace-sys.

[bors]

📌 Commit 49854c4 has been approved by alexcrichton

[alexcrichton]

It may be sort of roundaboutedly possible but it's probably best to just have a feature for the crate itself which, if disabled, causes the build script to return immediately. That way when the backtrace crate really depends on backtrace-sys, it enables something like backtrace-sys/actually-build or something like that.

[RalfJung]

So, implicitly enabling "foo" when "foo/feature" is enabled is deliberate? That's quite unfortunate as it is a serious reduction in expressivity; not doing that would be easily worked around by enabling both "foo" and "foo/feature" when needed. Is there a tracking issue for such improvements/changes to the feature mechanism (I guess this one would have to be opt-in or tied to an "edition" or so)?

[est31]

implicitly enabling "foo" when "foo/feature" is enabled is deliberate? That's quite unfortunate

@RalfJung there is an issue about this: rust-lang/cargo#3494

See also my comment in one of its dupes for a possible syntax that doesn't require a new edition: rust-lang/cargo#7259 (comment)