Profile setting for -Zfmt-debug

[ronnychevalier]

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.

[epage]

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:

• Not easy to use RUSTFLAGS
• Wanting to customize this per-profile

How much of this is also looking towards when this is stabilized? That can change the discussion because

• We'd need to figure out what its general path towards stabilization is (not every unstable feature takes a short, direct path) as that helps us understand the time table for designing for a stable feature
• Its not always an automatic decision to directly expose compiler behavior in profile but 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.
• There is a cost, as highlighted on Internals, to adding support for profile settings

it would allow users to define a different value depending on the profile

In focusing only on -Zfmt-debug as an unstable feature, this need can be handled by the unstable per-profile rustflags.

[ronnychevalier]

Wanting to customize this per-profile

Yes, the problem is not being able to enable this feature per-profile, and having to use RUSTFLAGS. Since cargo and the Cargo.toml file are the main interface people use to build their project, it is a problem when users have to resort to add flags to RUSTFLAGS since it breaks the usual user experience one has with cargo.

In focusing only on -Zfmt-debug as an unstable feature, this need can be handled by the unstable per-profile rustflags.

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-format setting is that it is much more limited in scope (in comparison to the rustflags setting), and having a setting in cargo exposing the fmt-debug option should help in testing this feature, and maybe help to eventually stabilize fmt-debug.

There is a cost, as highlighted on Internals, to adding support for profile settings

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 RUSTFLAGS or the proposition to add the profile setting rustflags. 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-debug is already part of rustc (nightly), and for the steps regarding cargo, I have a local branch that implements them.

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.

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 if fmt-debug is stabilized you would be more inclined to accept such a feature?

[weihanglo]

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 if fmt-debug is stabilized you would be more inclined to accept such a feature?

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 adding cargo-features = ….