Home Original page

Stabilize `-Zdebuginfo-compression` as `-Cdebuginfo-compression` by wesleywiser · Pull Request #150625 · rust-lang/rust

I propose stabilizing -Zdebuginfo-compression as -Cdebuginfo-compression. This PR adds a new -Cdebuginfo-compression flag, leaving the unstable -Z flag as-is to ease the transition period. The -Z flag will be removed in the future.

-Zdebuginfo-compression stabilization report

What is the RFC for this feature and what changes have occurred to the user-facing design since the RFC was finalized?

No RFC/MCP, this flag was added in #115358 and was not deemed large enough to require additional process.

The tracking issue for this feature is #120953.

What behavior are we committing to that has been controversial? Summarize the major arguments pro/con.

None that has been extensively debated but there is one obvious question:

  1. What is the behavior when flag is used on targets that do not support compressed debuginfo?
    Currently, passing -{C,Z} debuginfo-compression on targets like *-windows-msvc does not do anything. I believe it generally makes sense to alert the user when codegen flags are being ignored and I've opened an MCP Lint unsupported, target-specifc codegen flags compiler-team#957 that proposes handling this in a consistent way rather than on a ad-hoc, per-flag basis.

Are there extensions to this feature that remain unstable? How do we know that we are not accidentally committing to those.

No extensions per se, although not all debuginfo formats support compression (such as PDB/CodeView). If those formats incorporate compression support in the future, this feature can be extended when that support materializes. The implementation does not blindly forward the flag to the linker so we'll need to intentionally modify the compiler to enable that support.

Summarize the major parts of the implementation and provide links into the code (or to PRs)

  • We calculate the effective value of the flag taking into account both -{C,Z} debuginfo-compression (preferring the stabilized -C version)
    pub fn debuginfo_compression(&self) -> DebugInfoCompression {
    self.opts
    .cg
    .debuginfo_compression
    .or(self.opts.unstable_opts.debuginfo_compression)
    .unwrap_or(DebugInfoCompression::None)
    }
  • The flag is validated in case the LLVM backend build does not support zlib or zstd compression (our LLVM builds include support for both)
    let debuginfo_compression = match sess.debuginfo_compression() {
    config::DebugInfoCompression::None => llvm::CompressionKind::None,
    config::DebugInfoCompression::Zlib => {
    if llvm::LLVMRustLLVMHasZlibCompression() {
    llvm::CompressionKind::Zlib
    } else {
    sess.dcx().emit_warn(UnknownCompression { algorithm: "zlib" });
    llvm::CompressionKind::None
    }
    }
    config::DebugInfoCompression::Zstd => {
    if llvm::LLVMRustLLVMHasZstdCompression() {
    llvm::CompressionKind::Zstd
    } else {
    sess.dcx().emit_warn(UnknownCompression { algorithm: "zstd" });
    llvm::CompressionKind::None
    }
    }
    };
  • When the linker is invoked, we pass along the requested debuginfo compression
    match self.sess.debuginfo_compression() {
    config::DebugInfoCompression::None => {}
    config::DebugInfoCompression::Zlib => {
    self.link_arg("--compress-debug-sections=zlib");
    }
    config::DebugInfoCompression::Zstd => {
    self.link_arg("--compress-debug-sections=zstd");
    }
    }

The default for the flag is to not request debuginfo compression thus users have to opt-in to any level of compression. Zlib compression is widely supported across many versions of binutils and other tools that read debuginfo like gdb, lldb, perf, etc but zstd compression support is significantly newer and may require using the latest versions of these tools to support it. Users are responsible for ensuring whatever tools they use support the compression algorithm they've requested.

Summarize existing test coverage of this feature

Has a call-for-testing period been conducted? If so, what feedback was received?

No call-for-testing has been conducted but Rust for Linux has been using this flag without issue.

What outstanding bugs in the issue tracker involve this feature? Are they stabilization-blocking?

All reported bugs have been resolved.

Summarize contributors to the feature by name for recognition and assuredness that people involved in the feature agree with stabilization

What FIXMEs are still in the code for that feature and why is it ok to leave them there?

No FIXMEs related to this feature.

What static checks are done that are needed to prevent undefined behavior?

This feature cannot cause undefined behavior.

In what way does this feature interact with the reference/specification, and are those edits prepared?

No changes to reference/spec, the stable book has documentation added as part of this stabilization PR.

Does this feature introduce new expressions and can they produce temporaries? What are the lifetimes of those temporaries?

No.

What other unstable features may be exposed by this feature?

None.

What is tooling support like for this feature, w.r.t rustdoc, clippy, rust-analzyer, rustfmt, etc.?

No support needed for rustdoc, clippy, rust-analyzer, rustfmt or rustup.

Cargo could expose this as an option in build profiles but currently does not.

Closes #120953