Skip to content

Profile setting for -Zfmt-debug #15439

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
ronnychevalier opened this issue Apr 19, 2025 · 1 comment
Open

Profile setting for -Zfmt-debug #15439

ronnychevalier opened this issue Apr 19, 2025 · 1 comment
Labels
A-profiles Area: profiles C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` S-triage Status: This issue is waiting on initial triage.

Comments

@ronnychevalier
Copy link

ronnychevalier commented Apr 19, 2025

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

@ronnychevalier ronnychevalier added C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` S-triage Status: This issue is waiting on initial triage. labels Apr 19, 2025
@epage epage added the A-profiles Area: profiles label Apr 21, 2025
@epage
Copy link
Contributor

epage commented 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:

  • 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-profiles Area: profiles C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` S-triage Status: This issue is waiting on initial triage.
Projects
None yet
Development

No branches or pull requests

2 participants