Debugger support in `dev` profile slows down builds

[epage]

The dev profile serves double duty:

• faster iteration time
• debugger support

These come into conflict with some settings for debuggers slowing down builds, with potential changes to values like

• debug
• opt-level

See also

• Discussion of defaults settings for build dependencies for fastest compile times #10481
• https://blog.rust-lang.org/inside-rust/2024/12/13/this-development-cycle-in-cargo-1.84/#improving-the-built-in-profiles
• https://internals.rust-lang.org/t/feedback-request-performance-improvements-from-reducing-debug-info/21825
• #t-cargo > Effect of disabling debuginfo in the dev profile @ 💬
• #t-cargo > `-Csplit-debuginfo=unpacked` on Linux @ 💬
• https://blog.rust-lang.org/2024/02/19/2023-Rust-Annual-Survey-2023-results.html#challenges has build times and debugging as neck and neck
• https://mas.to/@davidlattimore/113484821980790635

[epage]

Questions for us to deal with:

• The ratio of the number of builds benefited by this compared to the number of builds run through a debugger?
  • If users do debug but its 100 to 1, then the story is different than it being 1 to 1
  • See also https://mas.to/@davidlattimore/113484821980790635
• How much is the limited use of debuggers due to bias of who is using Rust or the quality of the debugger experience?
  • See also https://blog.rust-lang.org/2024/02/19/2023-Rust-Annual-Survey-2023-results.html#challenges
• How do we ease of performant CI vs local development?
• If we make this change, what do we have to maintain compatibility on and how do we do it?

[epage]

If we make this change, what do we have to maintain compatibility on and how do we do it?

Would we provide a built-in profile for debugging? If so, new built-in profiles would be a breaking change because built-in profiles can't inherit from other profiles. So if user had a debugging profile that inherits from dev and we made debugging a built-in, their build would fail.

Options:

Allow users to inherit in any profile with some way to deal with cycles. This would allow users to mask the built-in profiles completely.

One way to avoid the masking of built-in profiles is to move all of the built-in profiles into a namespace (e.g. cargo::dev). In place of the built-in profiles would be default profiles that implicitly inherit from the same-named profile in the namespace (cargo::).

Another alternative is to use an existing reserved name. An obvious choice is debug. The challenge here is that build results for dev builds go in target/debug. A naive solution is dev goes in target/dev and debug goes in target/debug. However, if the default profile remains dev, then that would break users expecting to find final artifacts. What if we had a config field like build.target for the default profile for builds (except install / bench) and the default was dynamic, based on the edition? The first problem is users can specify multiple packages at once and there are no editions for a workspace.