Repository navigation
Profile setting for -Zfmt-debug #15439
Description
Problem
rustc supports the -Zfmt-debug option. When enabled, #[derive(Debug)] and {:?} generate a no-op implementation. This can be useful, for instance, to further strip debug symbols and debug code from a binary. See the implementation PR for a more complete description.
Currently, to use this feature, one needs to add the option manually to RUSTFLAGS when using cargo build.
Proposed Solution
This feature could be available in cargo as a new profile setting called debug-format. It would make it easier to use and it would allow users to define a different value depending on the profile. It would look like this:
# Cargo.toml
cargo-features = ["debug-format"] # or use the unstable flag: `cargo build -Zdebug-format`
[package]
# ...
[profile.release]
debug-format = "none"The possible values would be the same as the one exposed by rustc: full, none, and shallow.
It could also be possible to have by default the value none for the release profile, and full for the dev profile.
Notes
- rustc tracking issue: Tracking Issue for fmt-debug option rust#129709
- rustc implementation PR: debug-fmt-detail option rust#123940
- If the issue gets accepted, I'm willing to work on this and provide an implementation.
Activity
epage commentedon Apr 21, 2025
As an aside, the "Problem" section does not state a problem but describes the mechanics of the situation. Reading the "Proposed Solution", I understand the problems to be:
How much of this is also looking towards when this is stabilized? That can change the discussion because
profilebut care needs to be taken. We recognize that we need to form a general policy on how this should work out, likely in conjunction with the compiler team. We have this on our agenda for the All Hands.In focusing only on
-Zfmt-debugas an unstable feature, this need can be handled by the unstable per-profile rustflags.ronnychevalier commentedon May 13, 2025
Yes, the problem is not being able to enable this feature per-profile, and having to use
RUSTFLAGS. Since cargo and theCargo.tomlfile are the main interface people use to build their project, it is a problem when users have to resort to add flags toRUSTFLAGSsince it breaks the usual user experience one has with cargo.Indeed, this setting exist, but it seems that it is far from being stabilized any time soon?
Another reason to propose the introduction of a
debug-formatsetting is that it is much more limited in scope (in comparison to therustflagssetting), and having a setting in cargo exposing thefmt-debugoption should help in testing this feature, and maybe help to eventually stabilizefmt-debug.I agree, there are numerous steps and boilerplate needed. It hinders the adoption of more profile settings and complexifies the maintenance. Thus, forcing people to use
RUSTFLAGSor the proposition to add the profile settingrustflags. But I think these should only be used as a last resort and as temporary solutions until cargo can provide a more robust interface.Regarding this current issue,
fmt-debugis already part ofrustc(nightly), and for the steps regardingcargo, I have a local branch that implements them.I am really interested in knowing what will be the result of your discussion about such a policy.
Because, indeed, the policy is unclear at the moment since other profile settings have been accepted recently. And it seems the main difference with the current issue (regarding
fmt-debug) is that it is depending on a rustc nightly feature, so does this mean that iffmt-debugis stabilized you would be more inclined to accept such a feature?weihanglo commentedon May 14, 2025
To me yes, if you have to be exposed to nightly, then per-profile-rustflags is at hand. With profile-in-config, you can have a separate config.toml file other than
.cargo/config.toml, and don't clobber with your Cargo.toml addingcargo-features = ….