Clean up uses of the unstable `dwarf_version` option #135739

wesleywiser · 2025-01-19T19:23:34Z

Consolidate calculation of the effective value.
Check the target DebuginfoKind instead of using is_like_msvc.
Add the tracking issue to the unstable book page for this feature.

rustbot · 2025-01-19T19:23:42Z

rustbot has assigned @chenyukang.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

compiler/rustc_session/src/session.rs

lqd · 2025-01-19T21:08:03Z

Sweet, r? lqd and r=me with a tiny doc comment and green CI. Thanks!

mati865 · 2025-01-20T00:56:19Z

I think this might break windows-gnu targets. Their spec for some reason states pdb debuginfo but they use dwarf. Previously this was handled by is_like_msvc.

rust/compiler/rustc_target/src/spec/base/windows_gnu.rs

Line 102 in 9a1d156

debuginfo_kind: DebuginfoKind::Pdb,

wesleywiser · 2025-01-20T03:14:08Z

Thanks for pointing that out! That seems super weird. I'll look into that tomorrow.

lqd · 2025-01-20T09:10:23Z

Weird.

We should document that in both cg_llvm and the target specs themselves. And/or maybe the centralization should be in rustc_target/TargetOptions (but made available via the Session if you still want to, without that logic), since it's both target-specific and has subtle rules (that can contradict the spec fields).

…uginfokind, r=lqd Update windows-gnu targets to set `DebuginfoKind::DWARF` These targets have always used DWARF debuginfo and not CodeView/PDB debuginfo like the MSVC Windows targets. However, their target definitions claim to use `DebuginfoKind::PDB` probably to ensure that we do not try to allow the use of split-DWARF debuginfo. This does not appear to be necessary since the targets set their supported split debug info to `Off`. I've looked at all of the uses of these properties and this patch does not appear to cause any functional changes in compiler behavior. I also added UI tests to attempt to validate there is no change in the behavior of these options on stable compilers. cc `@mati865` since you mentioned this in rust-lang#135739 cc `@davidtwco` for split-dwarf

…uginfokind, r=lqd Update windows-gnu targets to set `DebuginfoKind::DWARF` These targets have always used DWARF debuginfo and not CodeView/PDB debuginfo like the MSVC Windows targets. However, their target definitions claim to use `DebuginfoKind::PDB` probably to ensure that we do not try to allow the use of split-DWARF debuginfo. This does not appear to be necessary since the targets set their supported split debug info to `Off`. I've looked at all of the uses of these properties and this patch does not appear to cause any functional changes in compiler behavior. I also added UI tests to attempt to validate there is no change in the behavior of these options on stable compilers. cc ``@mati865`` since you mentioned this in rust-lang#135739 cc ``@davidtwco`` for split-dwarf

…uginfokind, r=lqd Update windows-gnu targets to set `DebuginfoKind::DWARF` These targets have always used DWARF debuginfo and not CodeView/PDB debuginfo like the MSVC Windows targets. However, their target definitions claim to use `DebuginfoKind::PDB` probably to ensure that we do not try to allow the use of split-DWARF debuginfo. This does not appear to be necessary since the targets set their supported split debug info to `Off`. I've looked at all of the uses of these properties and this patch does not appear to cause any functional changes in compiler behavior. I also added UI tests to attempt to validate there is no change in the behavior of these options on stable compilers. cc ```@mati865``` since you mentioned this in rust-lang#135739 cc ```@davidtwco``` for split-dwarf

…uginfokind, r=lqd Update windows-gnu targets to set `DebuginfoKind::DWARF` These targets have always used DWARF debuginfo and not CodeView/PDB debuginfo like the MSVC Windows targets. However, their target definitions claim to use `DebuginfoKind::PDB` probably to ensure that we do not try to allow the use of split-DWARF debuginfo. This does not appear to be necessary since the targets set their supported split debug info to `Off`. I've looked at all of the uses of these properties and this patch does not appear to cause any functional changes in compiler behavior. I also added UI tests to attempt to validate there is no change in the behavior of these options on stable compilers. cc ````@mati865```` since you mentioned this in rust-lang#135739 cc ````@davidtwco```` for split-dwarf

wesleywiser · 2025-01-28T15:55:34Z

Now that #135790 has landed, I think this is good to go.

src/doc/unstable-book/src/compiler-flags/dwarf-version.md

lqd · 2025-01-28T16:57:55Z

r=me with the link fixed

- Consolidate calculation of the effective value. - Check the target `DebuginfoKind` instead of using `is_like_msvc`.

lqd · 2025-01-30T06:27:40Z

Thanks! @bors r+

bors · 2025-01-30T06:27:43Z

📌 Commit 4d5a63f has been approved by lqd

It is now in the queue for this repository.

…, r=lqd Clean up uses of the unstable `dwarf_version` option - Consolidate calculation of the effective value. - Check the target `DebuginfoKind` instead of using `is_like_msvc`. - Add the tracking issue to the unstable book page for this feature. cc rust-lang#103057

…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#133636 ([rustdoc] Add sans-serif font setting) - rust-lang#135434 (Match Ergonomics 2024: update edition 2024 behavior of feature gates) - rust-lang#135739 (Clean up uses of the unstable `dwarf_version` option) - rust-lang#135882 (simplify `similar_tokens` from `Option<Vec<_>>` to `&[_]`) - rust-lang#136179 (Allow transmuting generic pattern types to and from their base) - rust-lang#136199 (Fix a couple Emscripten tests) - rust-lang#136238 (ci: refactor how directories are removed in free-disk-space disk) - rust-lang#136251 (use impl Into<String> instead of explicit type args with bounds) r? `@ghost` `@rustbot` modify labels: rollup

…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#133636 ([rustdoc] Add sans-serif font setting) - rust-lang#135434 (Match Ergonomics 2024: update edition 2024 behavior of feature gates) - rust-lang#135739 (Clean up uses of the unstable `dwarf_version` option) - rust-lang#135882 (simplify `similar_tokens` from `Option<Vec<_>>` to `&[_]`) - rust-lang#136179 (Allow transmuting generic pattern types to and from their base) - rust-lang#136199 (Fix a couple Emscripten tests) - rust-lang#136251 (use impl Into<String> instead of explicit type args with bounds) r? `@ghost` `@rustbot` modify labels: rollup

Rollup merge of rust-lang#135739 - wesleywiser:dwarf_version_handling, r=lqd Clean up uses of the unstable `dwarf_version` option - Consolidate calculation of the effective value. - Check the target `DebuginfoKind` instead of using `is_like_msvc`. - Add the tracking issue to the unstable book page for this feature. cc rust-lang#103057

…n, r=petrochenkov Stabilize `-Zdwarf-version` as `-Cdwarf-version` I propose stabilizing `-Zdwarf-version` as `-Cdwarf-version`. This PR adds a new `-Cdwarf-version` flag, leaving the unstable `-Z` flag as is to ease the transition period. The `-Z` flag will be removed in the future. # `-Zdwarf-version` 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 rust-lang#98350 and was not deemed large enough to require additional process. The tracking issue for this feature is rust-lang#103057. ## What behavior are we committing to that has been controversial? Summarize the major arguments pro/con. None that has been extensively debated but there are a few questions that could have been chosen differently: 1. What should the flag name be? The current flag name is very specific to DWARF. Other debuginfo formats exist (msvc's CodeView format or https://en.wikipedia.org/wiki/Stabs) so we could have chosen to generalize the flag name (`-{C,Z} debuginfo-version=dwarf-5` for example). While this would extend cleanly to support formats other than DWARF, there are some downsides to this design. Neither CodeView nor Stabs have specification or format versions so it's not clear what values would be supported beyond `dwarf-{2,3,4,5}` or `codeview`. We would also need to take care to ensure the name does not lead users to think they can pick a format other than one supported by the target. For instance, what would `--target x86_64-pc-windows-msvc -Cdebuginfo-version=dwarf-5` do? 2. What is the behavior when flag is used on targets that do not support DWARF? Currently, passing `-{C,Z} dwarf-version` on targets like `*-windows-msvc` does not do anything. It may be preferable to emit a warning alerting the user that the flag has no effect on the target platform. Alternatively, we could emit an error but this could be annoying since it would require the use of target specific RUSTFLAGS to use the flag correctly (and there isn't a way to target "any platform that uses DWARF" using cfgs). 3. Does the precompiled standard library potentially using a different version of DWARF a problem? I don't believe this is an issue as debuggers (and other such tools) already must deal with the possibility that an application uses different DWARF versions across its statically or dynamically linked libraries. ## 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 future DWARF versions could be considered as such. At present, we validate the requested DWARF version is between 2 and 5 (inclusive) so new DWARF versions will not automatically be supported until the validation logic is adjusted. ## Summarize the major parts of the implementation and provide links into the code (or to PRs) - Targets define their preferred or default DWARF version: https://github.com./rust-lang/rust/blob/34a5ea911c56e79bd451c63f04ea2f5023d7d1a3/compiler/rustc_target/src/spec/mod.rs#L2369 - We use the target default but this can be overriden by `-{C,Z} dwarf-version` https://github.com./rust-lang/rust/blob/34a5ea911c56e79bd451c63f04ea2f5023d7d1a3/compiler/rustc_session/src/session.rs#L738 - The flag is validated https://github.com./rust-lang/rust/blob/34a5ea911c56e79bd451c63f04ea2f5023d7d1a3/compiler/rustc_session/src/session.rs#L1253-L1258 - When debuginfo is generated, we tell LLVM to use the requested value or the target default https://github.com./rust-lang/rust/blob/34a5ea911c56e79bd451c63f04ea2f5023d7d1a3/compiler/rustc_codegen_llvm/src/debuginfo/mod.rs#L106 ## Summarize existing test coverage of this feature - Test that we actually generate the appropriate DWARF version - https://github.com./rust-lang/rust/blob/master/tests/assembly/dwarf5.rs - https://github.com./rust-lang/rust/blob/master/tests/assembly/dwarf4.rs - Test that LTO with different DWARF versions picks the highest version - https://github.com./rust-lang/rust/blob/master/tests/assembly/dwarf-mixed-versions-lto.rs - Test DWARF versions 2-5 are valid while 0, 1 and 6 report an error - https://github.com./rust-lang/rust/blob/master/tests/ui/debuginfo/dwarf-versions.rs - Ensure LLVM does not report a warning when LTO'ing different DWARF versions together - https://github.com./rust-lang/rust/blob/master/tests/ui/lto/dwarf-mixed-versions-lto.rs ## 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 - Initial implementation in rust-lang#98350 by `@pcwalton` - Stop emitting `.debug_pubnames` and `.debug_pubtypes` when using DWARF 5 in rust-lang#117962 by `@weihanglo.` - Refactoring & cleanups (rust-lang#135739), fix LLVM warning on LTO with different DWARF versions (rust-lang#136659) and argument validation (rust-lang#136746) by `@wesleywiser` ## 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. We ensure the DWARF version is one of the supported values [here](https://github.com./rust-lang/rust/blob/34a5ea911c56e79bd451c63f04ea2f5023d7d1a3/compiler/rustc_session/src/session.rs#L1255-L1257). ## In what way does this feature interact with the reference/specification, and are those edits prepared? No changes to reference/spec, unstable rustc docs are moved to the stable book as part of the 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? `-Zembed-source` requires use of DWARF 5 extensions but has its own feature gate. ## 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 I would expect the decision as to what version should be used would be made for the entire crate graph at build time rather than by individual package authors. cc-rs has support for detecting the presence of `-{C,Z} dwarf-version` in `RUSTFLAGS` and providing the corresponding flag to Clang/gcc (rust-lang/cc-rs#1395). --- Closes rust-lang#103057

… r=petrochenkov Stabilize `-Zdwarf-version` as `-Cdwarf-version` I propose stabilizing `-Zdwarf-version` as `-Cdwarf-version`. This PR adds a new `-Cdwarf-version` flag, leaving the unstable `-Z` flag as is to ease the transition period. The `-Z` flag will be removed in the future. # `-Zdwarf-version` 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 rust-lang#98350 and was not deemed large enough to require additional process. The tracking issue for this feature is rust-lang#103057. ## What behavior are we committing to that has been controversial? Summarize the major arguments pro/con. None that has been extensively debated but there are a few questions that could have been chosen differently: 1. What should the flag name be? The current flag name is very specific to DWARF. Other debuginfo formats exist (msvc's CodeView format or https://en.wikipedia.org/wiki/Stabs) so we could have chosen to generalize the flag name (`-{C,Z} debuginfo-version=dwarf-5` for example). While this would extend cleanly to support formats other than DWARF, there are some downsides to this design. Neither CodeView nor Stabs have specification or format versions so it's not clear what values would be supported beyond `dwarf-{2,3,4,5}` or `codeview`. We would also need to take care to ensure the name does not lead users to think they can pick a format other than one supported by the target. For instance, what would `--target x86_64-pc-windows-msvc -Cdebuginfo-version=dwarf-5` do? 2. What is the behavior when flag is used on targets that do not support DWARF? Currently, passing `-{C,Z} dwarf-version` on targets like `*-windows-msvc` does not do anything. It may be preferable to emit a warning alerting the user that the flag has no effect on the target platform. Alternatively, we could emit an error but this could be annoying since it would require the use of target specific RUSTFLAGS to use the flag correctly (and there isn't a way to target "any platform that uses DWARF" using cfgs). 3. Does the precompiled standard library potentially using a different version of DWARF a problem? I don't believe this is an issue as debuggers (and other such tools) already must deal with the possibility that an application uses different DWARF versions across its statically or dynamically linked libraries. ## 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 future DWARF versions could be considered as such. At present, we validate the requested DWARF version is between 2 and 5 (inclusive) so new DWARF versions will not automatically be supported until the validation logic is adjusted. ## Summarize the major parts of the implementation and provide links into the code (or to PRs) - Targets define their preferred or default DWARF version: https://github.com./rust-lang/rust/blob/34a5ea911c56e79bd451c63f04ea2f5023d7d1a3/compiler/rustc_target/src/spec/mod.rs#L2369 - We use the target default but this can be overriden by `-{C,Z} dwarf-version` https://github.com./rust-lang/rust/blob/34a5ea911c56e79bd451c63f04ea2f5023d7d1a3/compiler/rustc_session/src/session.rs#L738 - The flag is validated https://github.com./rust-lang/rust/blob/34a5ea911c56e79bd451c63f04ea2f5023d7d1a3/compiler/rustc_session/src/session.rs#L1253-L1258 - When debuginfo is generated, we tell LLVM to use the requested value or the target default https://github.com./rust-lang/rust/blob/34a5ea911c56e79bd451c63f04ea2f5023d7d1a3/compiler/rustc_codegen_llvm/src/debuginfo/mod.rs#L106 ## Summarize existing test coverage of this feature - Test that we actually generate the appropriate DWARF version - https://github.com./rust-lang/rust/blob/master/tests/assembly/dwarf5.rs - https://github.com./rust-lang/rust/blob/master/tests/assembly/dwarf4.rs - Test that LTO with different DWARF versions picks the highest version - https://github.com./rust-lang/rust/blob/master/tests/assembly/dwarf-mixed-versions-lto.rs - Test DWARF versions 2-5 are valid while 0, 1 and 6 report an error - https://github.com./rust-lang/rust/blob/master/tests/ui/debuginfo/dwarf-versions.rs - Ensure LLVM does not report a warning when LTO'ing different DWARF versions together - https://github.com./rust-lang/rust/blob/master/tests/ui/lto/dwarf-mixed-versions-lto.rs ## 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 - Initial implementation in rust-lang#98350 by `@pcwalton` - Stop emitting `.debug_pubnames` and `.debug_pubtypes` when using DWARF 5 in rust-lang#117962 by `@weihanglo.` - Refactoring & cleanups (rust-lang#135739), fix LLVM warning on LTO with different DWARF versions (rust-lang#136659) and argument validation (rust-lang#136746) by `@wesleywiser` ## 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. We ensure the DWARF version is one of the supported values [here](https://github.com./rust-lang/rust/blob/34a5ea911c56e79bd451c63f04ea2f5023d7d1a3/compiler/rustc_session/src/session.rs#L1255-L1257). ## In what way does this feature interact with the reference/specification, and are those edits prepared? No changes to reference/spec, unstable rustc docs are moved to the stable book as part of the 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? `-Zembed-source` requires use of DWARF 5 extensions but has its own feature gate. ## 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 I would expect the decision as to what version should be used would be made for the entire crate graph at build time rather than by individual package authors. cc-rs has support for detecting the presence of `-{C,Z} dwarf-version` in `RUSTFLAGS` and providing the corresponding flag to Clang/gcc (rust-lang/cc-rs#1395). --- Closes rust-lang#103057

rustbot assigned chenyukang Jan 19, 2025

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jan 19, 2025

wesleywiser force-pushed the dwarf_version_handling branch from 89c7fcc to a9fae0d Compare January 19, 2025 20:59

wesleywiser changed the title ~~Clean up uses of the unstable dwarf_verison option~~ Clean up uses of the unstable dwarf_version option Jan 19, 2025

lqd reviewed Jan 19, 2025

View reviewed changes

compiler/rustc_session/src/session.rs Show resolved Hide resolved

rustbot assigned lqd and unassigned chenyukang Jan 19, 2025

wesleywiser force-pushed the dwarf_version_handling branch from a9fae0d to 26c10d0 Compare January 19, 2025 22:02

wesleywiser mentioned this pull request Jan 20, 2025

Update windows-gnu targets to set DebuginfoKind::DWARF #135790

Merged

lqd reviewed Jan 28, 2025

View reviewed changes

src/doc/unstable-book/src/compiler-flags/dwarf-version.md Outdated Show resolved Hide resolved

wesleywiser added 2 commits January 29, 2025 21:44

Clean up uses of the unstable dwarf_version option

51eaa0d

- Consolidate calculation of the effective value. - Check the target `DebuginfoKind` instead of using `is_like_msvc`.

Add tracking issue to docs

4d5a63f

wesleywiser force-pushed the dwarf_version_handling branch from 26c10d0 to 4d5a63f Compare January 30, 2025 03:45

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 30, 2025

matthiaskrgr mentioned this pull request Jan 30, 2025

Rollup of 8 pull requests #136285

Closed

matthiaskrgr mentioned this pull request Jan 30, 2025

Rollup of 7 pull requests #136292

Merged

bors merged commit aedc0a3 into rust-lang:master Jan 30, 2025
6 checks passed

rustbot added this to the 1.86.0 milestone Jan 30, 2025

This was referenced Feb 12, 2025

Tracking issue for -Zdwarf-version #103057

Closed

Stabilize -Zdwarf-version as -Cdwarf-version #136926

Merged

mati865 mentioned this pull request Apr 6, 2025

Can't run x86_64-pc-windows-gnu dev binary with wine #139380

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Clean up uses of the unstable `dwarf_version` option #135739

Clean up uses of the unstable `dwarf_version` option #135739

wesleywiser commented Jan 19, 2025

rustbot commented Jan 19, 2025

lqd commented Jan 19, 2025

mati865 commented Jan 20, 2025

wesleywiser commented Jan 20, 2025

lqd commented Jan 20, 2025

wesleywiser commented Jan 28, 2025

lqd commented Jan 28, 2025

lqd commented Jan 30, 2025

bors commented Jan 30, 2025

Clean up uses of the unstable dwarf_version option #135739

Clean up uses of the unstable dwarf_version option #135739

Conversation

wesleywiser commented Jan 19, 2025

rustbot commented Jan 19, 2025

lqd commented Jan 19, 2025

mati865 commented Jan 20, 2025

wesleywiser commented Jan 20, 2025

lqd commented Jan 20, 2025

wesleywiser commented Jan 28, 2025

lqd commented Jan 28, 2025

lqd commented Jan 30, 2025

bors commented Jan 30, 2025

Clean up uses of the unstable `dwarf_version` option #135739

Clean up uses of the unstable `dwarf_version` option #135739