user0/rust
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
my rust fork https://www.rust-lang.org
286516 commits 10 branches 154 tags 1.3 GiB
Find a file
bors afa859f812 Auto merge of #136926 - wesleywiser:stabilize_dwarf-version, 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 https://github.com/rust-lang/rust/pull/98350 and was not deemed large enough to require additional process.

The tracking issue for this feature is #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: 34a5ea911c/compiler/rustc_target/src/spec/mod.rs (L2369)
- We use the target default but this can be overriden by `-{C,Z} dwarf-version` 34a5ea911c/compiler/rustc_session/src/session.rs (L738)
- The flag is validated 34a5ea911c/compiler/rustc_session/src/session.rs (L1253-L1258)
- When debuginfo is generated, we tell LLVM to use the requested value or the target default 34a5ea911c/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 https://github.com/rust-lang/rust/pull/98350 by `@pcwalton`
- Stop emitting `.debug_pubnames` and `.debug_pubtypes` when using DWARF 5 in https://github.com/rust-lang/rust/pull/117962 by `@weihanglo.`
- Refactoring & cleanups (#135739), fix LLVM warning on LTO with different DWARF versions (#136659) and argument validation (#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](34a5ea911c/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 (https://github.com/rust-lang/cc-rs/pull/1395).

---

Closes #103057
2025-04-16 06:38:00 +00:00
.github Use rust-cache to speed-up citool compilation 2025-04-15 10:04:25 +02:00
compiler Auto merge of #136926 - wesleywiser:stabilize_dwarf-version, r=petrochenkov 2025-04-16 06:38:00 +00:00
library Add warning comment to Take::get_ref and Chain::get_ref 2025-04-15 10:54:08 -07:00
LICENSES Synchronize Unicode license text from unicode.org 2024-11-20 00:54:12 -08:00
src Auto merge of #136926 - wesleywiser:stabilize_dwarf-version, r=petrochenkov 2025-04-16 06:38:00 +00:00
tests Auto merge of #136926 - wesleywiser:stabilize_dwarf-version, r=petrochenkov 2025-04-16 06:38:00 +00:00
.clang-format Add .clang-format 2024-06-26 05:56:00 +08:00
.editorconfig Don't apply editorconfig to llvm 2025-02-09 16:21:14 -05:00
.git-blame-ignore-revs Git blame ignore recent formatting commit 2025-02-09 12:00:23 -08:00
.gitattributes Mark .pp files as Rust 2025-03-29 12:39:06 +01:00
.gitignore change config.toml to bootstrap.toml for bootstrap module 2025-03-17 12:56:41 +05:30
.gitmodules move autodiff from EnzymeAD/Enzyme to our rust-lang/Enzyme soft-fork 2025-04-01 17:17:39 -04:00
.ignore change config.toml to bootstrap.toml for bootstrap module 2025-03-17 12:56:41 +05:30
.mailmap Add myself to mailmap 2025-04-14 14:27:15 +01:00
bootstrap.example.toml create new option build.compiletest-use-stage0-libtest 2025-04-05 14:22:08 +03:00
Cargo.lock Rollup merge of #139813 - RalfJung:miri-sync, r=RalfJung 2025-04-14 21:55:41 +02:00
Cargo.toml Alphabetize the root workspace members 2025-03-13 12:21:14 -07:00
CODE_OF_CONDUCT.md Remove the code of conduct; instead link https://www.rust-lang.org/conduct.html 2019-10-05 22:55:19 +02:00
configure Ensure ./configure works when configure.py path contains spaces 2024-02-16 18:57:22 +00:00
CONTRIBUTING.md Fix some typos 2025-03-04 16:05:32 +08:00
COPYRIGHT dist: Re-work how we describe the licence of Rust in our distributions 2024-12-09 10:18:55 +00:00
INSTALL.md change config.toml to bootstrap.toml for bootstrap module 2025-03-17 12:56:41 +05:30
LICENSE-APACHE Remove appendix from LICENCE-APACHE 2019-12-30 14:25:53 +00:00
license-metadata.json Update license metadata 2025-02-15 16:48:37 +01:00
LICENSE-MIT dist: Re-work how we describe the licence of Rust in our distributions 2024-12-09 10:18:55 +00:00
README.md Update Rust Foundation links in Readme 2025-03-16 19:03:40 -07:00
RELEASES.md Apply suggestions from code review 2025-03-30 15:45:44 -07:00
REUSE.toml change config.toml to bootstrap.toml for bootstrap module 2025-03-17 12:56:41 +05:30
rust-bors.toml Increase timeout for new bors bot 2024-03-13 08:31:07 +01:00
rustfmt.toml rustfmt does not support use closures yet 2025-04-07 16:53:11 -03:00
triagebot.toml Rollup merge of #139687 - spastorino:add-spastorino-to-vacation, r=Urgau 2025-04-11 21:21:02 +02:00
x Look for python3 first on MacOS, not py 2025-02-13 10:24:54 -05:00
x.ps1 use & instead of start-process in x.ps1 2023-12-09 09:46:16 -05:00
x.py Reformat Python code with ruff 2024-12-04 23:03:44 +01:00

README.md

This is the main source code repository for Rust. It contains the compiler, standard library, and documentation.

Why Rust?

  • Performance: Fast and memory-efficient, suitable for critical services, embedded devices, and easily integrated with other languages.

  • Reliability: Our rich type system and ownership model ensure memory and thread safety, reducing bugs at compile-time.

  • Productivity: Comprehensive documentation, a compiler committed to providing great diagnostics, and advanced tooling including package manager and build tool (Cargo), auto-formatter (rustfmt), linter (Clippy) and editor support (rust-analyzer).

Quick Start

Read "Installation" from The Book.

Installing from Source

If you really want to install from source (though this is not recommended), see INSTALL.md.

Getting Help

See https://www.rust-lang.org/community for a list of chat platforms and forums.

Contributing

See CONTRIBUTING.md.

License

Rust is primarily distributed under the terms of both the MIT license and the Apache License (Version 2.0), with portions covered by various BSD-like licenses.

See LICENSE-APACHE, LICENSE-MIT, and COPYRIGHT for details.

Trademark

The Rust Foundation owns and protects the Rust and Cargo trademarks and logos (the "Rust Trademarks").

If you want to use these names or brands, please read the Rust language trademark policy.

Third-party logos may be subject to third-party copyrights and trademarks. See Licenses for details.