This is a (belatedly-opened) issue with the intention of tracking the -Zrun-dsymutil flag to the compiler. This flag was implemented long ago in #47784 and the intention is to prevent rustc from automatically running dsymutil on macOS, which it automatically does today for builds with debuginfo. The purpose for doing this is that dsymutil is a pretty slow process and can make debug incremental compile times quite painful.

The purpose of dsymutil itself is to collect all debuginfo from the executable and all its dependencies into an adjacent *.dSYM folder next to the executable itself. This form of split-debuginfo is then read by debuggers and such. This consequently means that dsymutil is inherently not incremental. It will unconditionally run over the entire final binary and produce the entire *.dSYM folder each time. Since this runs over the final artifact which typically has a lot of debuginfo this can take quite a long time.

As discovered on #47784, however, the reason this has been unstable for so long is that dsymutil was required for filenames and line numbers with RUST_BACKTRACE by default. It was too unreasonable for Cargo or other tooling to not run dsymutil because it broke this important feature. With the advent of a Rust-based backtrace backend, however, we now have support to parse debuginfo even if dsymutil hasn't run. This uses the same technique LLDB uses to give you debuginfo even when dsymutil hasn't run. This was then later integrated into libstd and is purportedly working well and greatly improving incremental compile time.

As for the nitty-gritty of what this flag does:

• If enabled run-dsymutil will execute dsymutil over the final binary. This flag is enabled by default since it's always been rustc's default behavior.
• If disabled, the compiler both does not run dsymutil and it doesn't delete the object files on disk relevant for the final compilation. This ensures that references in the binary to the object files for debuginfo can be followed and found.

I'd like to, while opening this issue, also propose that this flag get stabilized. I think the interface is work bikeshedding (e.g. naming and such), but I think the functionality is all in what should be the final end state. I think the expected vision for how we ship this benefit to end users is to switch Cargo's defaults to passing run-dsymutil=no (or the equivalent) by default on macOS. That way macOS users should, by default, get the benefit of no dsymutil invocations but should retain the ability to debug executables as well as get filenames/line numbers with backtraces. Furthermore if *.dSYM is still required by the user, end-applications can always run it as part of a build process themselves.