Skip to content

Add support for setting -gdwarf-{version} based on RUSTFLAGS - #1395

Merged
madsmtm merged 1 commit into
rust-lang:mainfrom
wesleywiser:dwarf_version
Feb 11, 2025
Merged

Add support for setting -gdwarf-{version} based on RUSTFLAGS#1395
madsmtm merged 1 commit into
rust-lang:mainfrom
wesleywiser:dwarf_version

Conversation

@wesleywiser

@wesleywiser wesleywiser commented Feb 8, 2025

Copy link
Copy Markdown
Member

Detect if -Zdwarf-version (which will probably be stabilized soon as -Cdwarf-version) was passed in RUSTFLAGS and set the corresponding Clang/GCC option to the same value.

NobodyXu
NobodyXu approved these changes Feb 9, 2025
View reviewed changes

@NobodyXu NobodyXu left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks LGTM!

cc @madsmtm for a double checkq

madsmtm
madsmtm reviewed Feb 9, 2025
View reviewed changes

@madsmtm madsmtm left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks fine after parsing. I verified that the semantics are the same.

Comment thread src/flags.rs Resolved
@madsmtm madsmtm mentioned this pull request Feb 9, 2025
Open
@wesleywiser
Add support for setting -gdwarf-{version} based on RUSTFLAGS
894fae4 
Detect if `-Zdwarf-version` (which will probably be stabilized soon
as `-Cdwarf-version`) was passed in RUSTFLAGS and set the corresponding
Clang/GCC option to the same value.
madsmtm
madsmtm approved these changes Feb 11, 2025
View reviewed changes

@madsmtm madsmtm left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

For posterity, I'll note that I considered if it would make sense to restrict even further (e.g. only accept 2, 3, 4 or 5), but then again, Clang and GCC support more versions than rustc (and that will probably be true for the foreseeable future), and the compiler driver will just error if it doesn't support the flag anyhow. So it's probably better to treat these as integers, and be "future compatible" with a hypothetical DWARF 6.

@madsmtm
madsmtm merged commit c0bb1e3 into rust-lang:main Feb 11, 2025
@wesleywiser wesleywiser mentioned this pull request Feb 12, 2025
Merged
@github-actions github-actions Bot mentioned this pull request Feb 14, 2025
Merged
This was referenced Feb 14, 2025
Closed
Closed
bors added a commit to rust-lang-ci/rust that referenced this pull request Feb 15, 2025
@bors
Auto merge of rust-lang#137024 - jieyouxu:bump-compiler-cc-cmake, r=<…
ceacda5 
…try>

Bump compiler cc to 1.2.14

[cc v1.2.14](https://github.com/rust-lang/cc-rs/releases/tag/cc-v1.2.14):
> - Regenerate target info (rust-lang/cc-rs#1398)
> - Add support for setting -gdwarf-{version} based on RUSTFLAGS (rust-lang/cc-rs#1395)
> - Add support for alternative network stack io-sock on QNX 7.1 aarch64 and x86_64 (rust-lang/cc-rs#1312)

try-job: dist-apple-various
bors added a commit to rust-lang-ci/rust that referenced this pull request Feb 15, 2025
@bors
Auto merge of rust-lang#137022 - jieyouxu:bump-bootstrap-cc-cmake, r=…
b4d46e1 
…<try>

Bump bootstrap cc to 1.2.14 and cmake to 0.1.54

## Summary

Bump bootstrap's `cc` and `cmake` deps:

1. To make it easier to add new/unofficial targets. In particular, `cc` v1.2.4+ allows using env vars to pass target parameters to the `cc` crate. This was previously attempted in rust-lang#134344 but ran into macos-cross-to-iOS problems with `cmake` (and also rust-lang#136440, rust-lang#136720). See also discussions in rust-lang/cc-rs#1317.
2. Fix some flag inheritance warnings. Fixes rust-lang#136338.

## `cc` changelogs between `1.2.0` and `1.2.14`

> ## [1.2.14](rust-lang/cc-rs@cc-v1.2.13...cc-v1.2.14) - 2025-02-14
>
> ### Other
>
> - Regenerate target info ([rust-lang#1398](rust-lang/cc-rs#1398))
> - Add support for setting `-gdwarf-{version}` based on RUSTFLAGS ([rust-lang#1395](rust-lang/cc-rs#1395))
> - Add support for alternative network stack io-sock on QNX 7.1 aarch64 and x86_64 ([rust-lang#1312](rust-lang/cc-rs#1312))
>
> ## [1.2.13](rust-lang/cc-rs@cc-v1.2.12...cc-v1.2.13) - 2025-02-08
>
> ### Other
>
> - Fix cross-compiling for Apple platforms ([rust-lang#1389](rust-lang/cc-rs#1389))
>
> ## [1.2.12](rust-lang/cc-rs@cc-v1.2.11...cc-v1.2.12) - 2025-02-04
>
> ### Other
>
> - Split impl Build ([rust-lang#1382](rust-lang/cc-rs#1382))
> - Don't specify both `-target` and `-mtargetos=` on Apple targets ([rust-lang#1384](rust-lang/cc-rs#1384))
>
> ## [1.2.11](rust-lang/cc-rs@cc-v1.2.10...cc-v1.2.11) - 2025-01-31
>
> ### Other
>
> - Fix more flag inheritance ([rust-lang#1380](rust-lang/cc-rs#1380))
> - Include wrapper args. in `stdout` family heuristics to restore classifying `clang --driver-mode=cl` as `Msvc { clang_cl: true }` ([rust-lang#1378](rust-lang/cc-rs#1378))
> - Constrain `-Clto` and `-Cembed-bitcode` flag inheritance to be `clang`-only ([rust-lang#1379](rust-lang/cc-rs#1379))
> - Pass deployment target with `-m*-version-min=` ([rust-lang#1339](rust-lang/cc-rs#1339))
> - Regenerate target info ([rust-lang#1376](rust-lang/cc-rs#1376))
>
> ## [1.2.10](rust-lang/cc-rs@cc-v1.2.9...cc-v1.2.10) - 2025-01-17
>
> ### Other
>
> - Fix CC_FORCE_DISABLE=0 evaluating to true ([rust-lang#1371](rust-lang/cc-rs#1371))
> - Regenerate target info ([rust-lang#1369](rust-lang/cc-rs#1369))
> - Make hidden lifetimes explicit. ([rust-lang#1366](rust-lang/cc-rs#1366))
>
> ## [1.2.9](rust-lang/cc-rs@cc-v1.2.8...cc-v1.2.9) - 2025-01-12
>
> ### Other
>
> - Don't pass inherited PGO flags to GNU compilers (rust-lang#1363)
> - Adjusted zig cc judgment and avoided zigbuild errors([rust-lang#1360](rust-lang/cc-rs#1360)) ([rust-lang#1361](rust-lang/cc-rs#1361))
> - Fix compilation on macOS using clang and fix compilation using zig-cc ([rust-lang#1364](rust-lang/cc-rs#1364))
>
> ## [1.2.8](rust-lang/cc-rs@cc-v1.2.7...cc-v1.2.8) - 2025-01-11
>
> ### Other
>
> - Add `is_like_clang_cl()` getter (rust-lang#1357)
> - Fix clippy error in lib.rs ([rust-lang#1356](rust-lang/cc-rs#1356))
> - Regenerate target info ([rust-lang#1352](rust-lang/cc-rs#1352))
> - Fix compiler family detection issue with clang-cl on macOS ([rust-lang#1328](rust-lang/cc-rs#1328))
> - Update `windows-bindgen` dependency ([rust-lang#1347](rust-lang/cc-rs#1347))
> - Fix clippy warnings ([rust-lang#1346](rust-lang/cc-rs#1346))
>
> ## [1.2.7](rust-lang/cc-rs@cc-v1.2.6...cc-v1.2.7) - 2025-01-03
>
> ### Other
>
> - Regenerate target info ([rust-lang#1342](rust-lang/cc-rs#1342))
> - Document new supported architecture names in windows::find
> - Make is_flag_supported_inner take an &Tool ([rust-lang#1337](rust-lang/cc-rs#1337))
> - Fix is_flag_supported on msvc ([rust-lang#1336](rust-lang/cc-rs#1336))
> - Allow using Visual Studio target names in `find_tool` ([rust-lang#1335](rust-lang/cc-rs#1335))
>
> ## [1.2.6](rust-lang/cc-rs@cc-v1.2.5...cc-v1.2.6) - 2024-12-27
>
> ### Other
>
> - Don't inherit the `/Oy` flag for 64-bit targets ([rust-lang#1330](rust-lang/cc-rs#1330))
>
> ## [1.2.5](rust-lang/cc-rs@cc-v1.2.4...cc-v1.2.5) - 2024-12-19
>
> ### Other
>
> - Check linking when testing if compiler flags are supported ([rust-lang#1322](rust-lang/cc-rs#1322))
>
> ## [1.2.4](rust-lang/cc-rs@cc-v1.2.3...cc-v1.2.4) - 2024-12-13
>
> ### Other
>
> - Add support for C/C++ compiler for Neutrino QNX: `qcc` ([rust-lang#1319](rust-lang/cc-rs#1319))
> - use -maix64 instead of -m64 ([rust-lang#1307](rust-lang/cc-rs#1307))
>
> ## [1.2.3](rust-lang/cc-rs@cc-v1.2.2...cc-v1.2.3) - 2024-12-06
>
> ### Other
>
> - Improve detection of environment when compiling from msbuild or msvc ([rust-lang#1310](rust-lang/cc-rs#1310))
> - Better error message when failing on unknown targets ([rust-lang#1313](rust-lang/cc-rs#1313))
> - Optimize RustcCodegenFlags ([rust-lang#1305](rust-lang/cc-rs#1305))
>
> ## [1.2.2](rust-lang/cc-rs@cc-v1.2.1...cc-v1.2.2) - 2024-11-29
>
> ### Other
>
> - Inherit flags from rustc ([rust-lang#1279](rust-lang/cc-rs#1279))
> - Add support for using sccache wrapper with cuda/nvcc ([rust-lang#1304](rust-lang/cc-rs#1304))
> - Fix msvc stdout not shown on error ([rust-lang#1303](rust-lang/cc-rs#1303))
> - Regenerate target info ([rust-lang#1301](rust-lang/cc-rs#1301))
> - Fix compilation of C++ code for armv7-unknown-linux-gnueabihf ([rust-lang#1298](rust-lang/cc-rs#1298))
> - Fetch target info from Cargo even if `Build::target` is manually set ([rust-lang#1299](rust-lang/cc-rs#1299))
> - Fix two files with different extensions having the same object name ([rust-lang#1295](rust-lang/cc-rs#1295))
> - Allow disabling cc's ability to compile via env var CC_FORCE_DISABLE ([rust-lang#1292](rust-lang/cc-rs#1292))
> - Regenerate target info ([rust-lang#1293](rust-lang/cc-rs#1293))
>
> ## [1.2.1](rust-lang/cc-rs@cc-v1.2.0...cc-v1.2.1) - 2024-11-14
>
> ### Other
>
> - When invoking `cl -?`, set stdin to null ([rust-lang#1288](rust-lang/cc-rs#1288))

## `cmake` changelogs `0.1.51` to `0.1.54`

> ## [0.1.54](rust-lang/cmake-rs@v0.1.53...v0.1.54) - 2025-02-10
>
> ### Other
>
> - Remove workaround for broken `cc-rs` versions ([rust-lang#235](rust-lang/cmake-rs#235))
> - Be more precise in the description of `register_dep` ([rust-lang#238](rust-lang/cmake-rs#238))
>
> ## [0.1.53](rust-lang/cmake-rs@v0.1.52...v0.1.53) - 2025-01-27
>
> ### Other
>
> - Disable broken Make jobserver support on OSX to fix parallel builds ([rust-lang#229](rust-lang/cmake-rs#229))
>
> ## [0.1.52](rust-lang/cmake-rs@v0.1.51...v0.1.52) - 2024-11-25
>
> ### Other
>
> - Expose cc-rs no_default_flags for hassle-free cross-compilation ([rust-lang#225](rust-lang/cmake-rs#225))
> - Add a `success` job to CI
> - Change `--build` to use an absolute path
> - Merge pull request [rust-lang#195](rust-lang/cmake-rs#195) from meowtec/feat/improve-fail-hint
> - Improve hint for cmake not installed in Linux (code 127)
>
> ## [0.1.51](rust-lang/cmake-rs@v0.1.50...v0.1.51) - 2024-08-15
>
> ### Added
>
> - Add JOM generator support ([rust-lang#183](rust-lang/cmake-rs#183))
> - Improve visionOS support ([rust-lang#209](rust-lang/cmake-rs#209))
> - Use `Generic` for bare-metal systems ([rust-lang#187](rust-lang/cmake-rs#187))
>
> ### Fixed
>
> - Fix cross compilation on android armv7 and x86 ([rust-lang#186](rust-lang/cmake-rs#186))

try-job: dist-apple-various
@jieyouxu jieyouxu mentioned this pull request Feb 28, 2025
Merged
github-merge-queue Bot pushed a commit to rust-lang/cargo that referenced this pull request Feb 28, 2025
@epage
Bump cc to 1.2.16 to fix x86 windows jobs in rust-lang/rust CI (#…
2622e84 
…15245)

### What does this PR try to resolve?

GitHub Runner Images 20250224.5.0+ ship Windows 11 SDK 10.0.26100+
compared to the previous Windows 11 SDK 10.0.22621, which bumped the
UCRT headers. The new UCRT headers use SSE2 types. However, `cc`
versions <= 1.2.15 emit `/arch:IA32` for `x86` Windows targets for
`clang-cl`, which causes compilation errors since `clang-cl` can't find
SSE2 types without `/arch:SSE2` specified (or defaulted). (Note that
MSVC at the time of writing silently accepts and emits instruments for
code using SSE2 types, as opposed to `clang-cl` hard error-ing).

`cc` 1.2.16 contains a fix for this problem,
rust-lang/cc-rs#1425, to correctly emit
`/arch:SSE2` instead of `/arch:IA32` to enable `clang-cl` to find the
SSE2 types. However, cargo's `cc` currently is still on 1.2.13.

To fix this for rust-lang/rust CI, we need to bump anything that
transitively relies on `cc` and tries to use `clang-cl` on `x86` Windows
targets to compile any C/C++ code that transitively use functions or
types that require SSE2 types, such as `<wchar.h>`.

### How should we test and review this PR?

The fix was initially intended for `rustc_{codegen_ssa,llvm}` `cc`, and
based on testing in rust-lang/rust#137724, I was
able to successfully build `rustc_{codegen_ssa,llvm}` with a forked `cc`
based on 1.2.15 which contains the fix from
rust-lang/cc-rs#1425. Note that in the same PR,
while the compiler build succeeded, the build of cargo itself failed
since it transitively used a `cc` *without* the fix to build
`curl-sys`[^dep-chain], which failed as one might expect (`curl-sys`
tries to build C code that uses `<wchar.h>` which runs into the same
problem). Hence, this PR is opened to bump cargo's `cc` to a `cc`
version containing the fix.

### Additional information

This `x86` Windows CI problem is:

- Discussed in
https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/spurious.20.28.3F.29.20i686.20msvc.20errors.
- Tracked by rust-lang/rust#137733.

#### `cc` changelog between 1.2.13 and 1.2.16

<details>
<summary>`cc` changes since 1.2.13 up to and including 1.2.16</summary>

#####
[1.2.16](rust-lang/cc-rs@cc-v1.2.15...cc-v1.2.16)
- 2025-02-28

###### Fixed

- force windows compiler to run in `out_dir` to prevent artifacts in cwd
(#1415)

###### Other

- use `/arch:SSE2` for `x86` target arch (#1425)
- Regenerate windows-sys binding
([#1422](rust-lang/cc-rs#1422))
- Regenerate target info
([#1418](rust-lang/cc-rs#1418))
- Add LIB var when compiling flag_check (#1417)
- Change flag ordering
([#1403](rust-lang/cc-rs#1403))
- Fix archiver detection for musl cross compilation
([#1404](rust-lang/cc-rs#1404))

#####
[1.2.15](rust-lang/cc-rs@cc-v1.2.14...cc-v1.2.15)
- 2025-02-21

###### Other

- Regenerate target info
([#1406](rust-lang/cc-rs#1406))
- Always read from all `CFLAGS`-style flags
([#1401](rust-lang/cc-rs#1401))
- Simplify the error output on failed `Command` invocation
([#1397](rust-lang/cc-rs#1397))

#####
[1.2.14](rust-lang/cc-rs@cc-v1.2.13...cc-v1.2.14)
- 2025-02-14

###### Other

- Regenerate target info
([#1398](rust-lang/cc-rs#1398))
- Add support for setting `-gdwarf-{version}` based on RUSTFLAGS
([#1395](rust-lang/cc-rs#1395))
- Add support for alternative network stack io-sock on QNX 7.1 aarch64
and x86_64 ([#1312](rust-lang/cc-rs#1312))

</details>

[^dep-chain]: I think the dep chain is something like git2 ->
libgit2-sys -> curl -> curl-sys?
@jieyouxu jieyouxu mentioned this pull request Feb 28, 2025
Merged
jieyouxu added a commit to jieyouxu/rust that referenced this pull request Feb 28, 2025
@jieyouxu
Rollup merge of rust-lang#137788 - jieyouxu:bump-compiler-cc, r=lqd,K…
46f5dea 
…obzol

Bump `rustc_{codegen_ssa,llvm}` `cc` to 1.2.16 to fix `x86` Windows jobs on newest Windows SDK

Part of rust-lang#137733.

Bump `rustc_{codegen_ssa,llvm}` `cc` to 1.2.16 which contains rust-lang/cc-rs#1425 to help with rust-lang#137733. Previously tested in rust-lang#137724.

#### `cc` changelog between 1.2.13 and 1.2.16

<details>
<summary>`cc` changes since 1.2.13 up to and including 1.2.16</summary>

##### [1.2.16](rust-lang/cc-rs@cc-v1.2.15...cc-v1.2.16) - 2025-02-28

###### Fixed

- force windows compiler to run in `out_dir` to prevent artifacts in cwd (rust-lang#1415)

###### Other

- use `/arch:SSE2` for `x86` target arch (rust-lang#1425)
- Regenerate windows-sys binding ([rust-lang#1422](rust-lang/cc-rs#1422))
- Regenerate target info ([rust-lang#1418](rust-lang/cc-rs#1418))
- Add LIB var when compiling flag_check (rust-lang#1417)
- Change flag ordering ([rust-lang#1403](rust-lang/cc-rs#1403))
- Fix archiver detection for musl cross compilation ([rust-lang#1404](rust-lang/cc-rs#1404))

##### [1.2.15](rust-lang/cc-rs@cc-v1.2.14...cc-v1.2.15) - 2025-02-21

###### Other

- Regenerate target info ([rust-lang#1406](rust-lang/cc-rs#1406))
- Always read from all `CFLAGS`-style flags ([rust-lang#1401](rust-lang/cc-rs#1401))
- Simplify the error output on failed `Command` invocation ([rust-lang#1397](rust-lang/cc-rs#1397))

##### [1.2.14](rust-lang/cc-rs@cc-v1.2.13...cc-v1.2.14) - 2025-02-14

###### Other

- Regenerate target info ([rust-lang#1398](rust-lang/cc-rs#1398))
- Add support for setting `-gdwarf-{version}` based on RUSTFLAGS ([rust-lang#1395](rust-lang/cc-rs#1395))
- Add support for alternative network stack io-sock on QNX 7.1 aarch64 and x86_64 ([rust-lang#1312](rust-lang/cc-rs#1312))

</details>

r? `@Kobzol`
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Feb 28, 2025
@rust-timer
Unrolled build for rust-lang#137788
166504f 
Rollup merge of rust-lang#137788 - jieyouxu:bump-compiler-cc, r=lqd,Kobzol

Bump `rustc_{codegen_ssa,llvm}` `cc` to 1.2.16 to fix `x86` Windows jobs on newest Windows SDK

Part of rust-lang#137733.

Bump `rustc_{codegen_ssa,llvm}` `cc` to 1.2.16 which contains rust-lang/cc-rs#1425 to help with rust-lang#137733. Previously tested in rust-lang#137724.

#### `cc` changelog between 1.2.13 and 1.2.16

<details>
<summary>`cc` changes since 1.2.13 up to and including 1.2.16</summary>

##### [1.2.16](rust-lang/cc-rs@cc-v1.2.15...cc-v1.2.16) - 2025-02-28

###### Fixed

- force windows compiler to run in `out_dir` to prevent artifacts in cwd (rust-lang#1415)

###### Other

- use `/arch:SSE2` for `x86` target arch (rust-lang#1425)
- Regenerate windows-sys binding ([rust-lang#1422](rust-lang/cc-rs#1422))
- Regenerate target info ([rust-lang#1418](rust-lang/cc-rs#1418))
- Add LIB var when compiling flag_check (rust-lang#1417)
- Change flag ordering ([rust-lang#1403](rust-lang/cc-rs#1403))
- Fix archiver detection for musl cross compilation ([rust-lang#1404](rust-lang/cc-rs#1404))

##### [1.2.15](rust-lang/cc-rs@cc-v1.2.14...cc-v1.2.15) - 2025-02-21

###### Other

- Regenerate target info ([rust-lang#1406](rust-lang/cc-rs#1406))
- Always read from all `CFLAGS`-style flags ([rust-lang#1401](rust-lang/cc-rs#1401))
- Simplify the error output on failed `Command` invocation ([rust-lang#1397](rust-lang/cc-rs#1397))

##### [1.2.14](rust-lang/cc-rs@cc-v1.2.13...cc-v1.2.14) - 2025-02-14

###### Other

- Regenerate target info ([rust-lang#1398](rust-lang/cc-rs#1398))
- Add support for setting `-gdwarf-{version}` based on RUSTFLAGS ([rust-lang#1395](rust-lang/cc-rs#1395))
- Add support for alternative network stack io-sock on QNX 7.1 aarch64 and x86_64 ([rust-lang#1312](rust-lang/cc-rs#1312))

</details>

r? `@Kobzol`
Zalathar added a commit to Zalathar/rust that referenced this pull request Apr 16, 2025
@Zalathar
Rollup merge of rust-lang#136926 - wesleywiser:stabilize_dwarf-versio…
8213969 
…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
bors added a commit to rust-lang-ci/rust that referenced this pull request Apr 16, 2025
@bors
Auto merge of rust-lang#136926 - wesleywiser:stabilize_dwarf-version,…
afa859f 
… 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
github-actions Bot pushed a commit to rust-lang/rustc-dev-guide that referenced this pull request Apr 17, 2025
@bors
Auto merge of #136926 - wesleywiser:stabilize_dwarf-version, r=petroc…
94acf3c 
…henkov

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/rust#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: 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/rust#98350 by `@pcwalton`
- Stop emitting `.debug_pubnames` and `.debug_pubtypes` when using DWARF 5 in rust-lang/rust#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](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 #103057
github-actions Bot pushed a commit to rust-lang/miri that referenced this pull request Apr 17, 2025
@bors
Auto merge of #136926 - wesleywiser:stabilize_dwarf-version, r=petroc…
6334caa 
…henkov

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/rust#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: 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/rust#98350 by `@pcwalton`
- Stop emitting `.debug_pubnames` and `.debug_pubtypes` when using DWARF 5 in rust-lang/rust#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](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 #103057
lnicola pushed a commit to lnicola/rust-analyzer that referenced this pull request Apr 28, 2025
@bors
Auto merge of #136926 - wesleywiser:stabilize_dwarf-version, r=petroc…
d638e47 
…henkov

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/rust#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: 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/rust#98350 by `@pcwalton`
- Stop emitting `.debug_pubnames` and `.debug_pubtypes` when using DWARF 5 in rust-lang/rust#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](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 #103057
wangchen-vivo pushed a commit to wangchen-vivo/cc-rs that referenced this pull request Aug 13, 2026
@wesleywiser @wangchen-vivo
Add support for setting -gdwarf-{version} based on RUSTFLAGS (rust-…
87298bf 
…lang#1395)

Detect if `-Zdwarf-version` (which will probably be stabilized soon
as `-Cdwarf-version`) was passed in RUSTFLAGS and set the corresponding
Clang/GCC option to the same value.
zhaowenbo-vivo pushed a commit to vivoblueos/cc-rs that referenced this pull request Oct 14, 2026
@wangchen-vivo @NobodyXu
@github-actions @madsmtm @graydon @tgross35 @nicholasbishop @dot-asm @nmattia @mati865 @ChrisDenton @tronical @flaub @mrkajetanp @dlon @mustartt @flba-eb @clubby789 @kennykerr @MarijnS95 @phoepsilonix @tnewsome-lynx @marcoieni @dependabot @jieyouxu @ErichDonGubler @Qix- @wesleywiser @wmmc88 @arjunr2 @justsmth @Kobzol @fiveseven-lambda @onur-ozkan @folkertdev @PaulWagener @chyyran @no92 @lawkai-vivo @han-jiang277
Upgrade BlueOS cc-rs to v1.2.28 (#3)
384adcf 
* Update doc for detecting changes/upgrades of compilers (rust-lang#1218)

* chore: release (rust-lang#1220)

* Add auto cancellation for CI jobs (rust-lang#1222)

when pushing new commits to the PR, cancel the previous jobs

Signed-off-by: Jiahao XU <Jiahao_XU@outlook.com>

* Reduce the need for the host target triple (rust-lang#1224)

* Fix wasm32-wasip1-threads:  shared-memory disallowed due to not compiled with 'atomics' or 'bulk-memory' features (rust-lang#1221)

* chore: release (rust-lang#1223)

* Remove incorrect "lib" prefixes in CXXSTDLIB doc comments (rust-lang#1228)

* chore: release (rust-lang#1229)

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

* Use debug version of MSVC runtime library on debug (rust-lang#1231)

* Use debug version of MSVC runtime library on debug

Fixed rust-lang#1230

* Fix clippy

* chore: release (rust-lang#1232)

* Disable `CC_ENABLE_DEBUG_OUTPUT` if it is set to "0" (rust-lang#1234)

* Revert "Use debug version of MSVC runtime library on debug (rust-lang#1231)" (rust-lang#1237)

This reverts commit c80a706.

* chore: release (rust-lang#1235)

* Environment variables: For one accepting boolean, treat "0", "false" and empty env as false (rust-lang#1238)

* Add getenv_boolean

* Update Build methods to use getenv_boolean

And update getenv_boolean, to treat "false" as false.

* Fix Build::getenv_Boolean and treat empty env as false

* Env CC_ENABLE_DEBUG_OUTPUT: treat "false" or empty str as false

* Fix Build::getenv_boolean

* Fix clippy

* chore: release (rust-lang#1239)

* Regenerate target info (rust-lang#1243)

Co-authored-by: github-actions <github-actions@github.com>

* chore: release (rust-lang#1244)

* Don't pass -fPIC by default on wasm (rust-lang#1245)

* Don't pass -fPIC by default on wasm

Fix rust-lang#1240

* Fix cargo fmt

* chore: release (rust-lang#1246)

* Add comment explaining why cc does not rebuild on env PATH change (rust-lang#1247)

* chore: release v1.1.31 (rust-lang#1248)

* Use Cargo's target information when possible (rust-lang#1225)

* Reduce the need for the host target triple

* Use Cargo's target information when possible

rustc's target triples generally only have a vague resemblance to each
other and to the information needed by `cc`. Let's instead prefer
`CARGO_CFG_*` variables when available, since these contain the
information directly from the compiler itself.

In the cases where it isn't available (i.e. when running outside of a
build script), we fall back to parsing the target triple, but instead of
doing it in an ad-hoc fashion with string manipulation, we do it in a
more structured fashion up front.

* Remove unnecessary derive

* Use pre-generated target information

* Use Cow<'static, str> in Target

* Remove redundant test

* Redo from_cargo_environment_variables to be more error resilient

* Fix after merge

* Appease clippy

* Add support for targets within MSRV

* Fix test

* Fix a few more tests

* Properly match previous behaviour

* Update to Rust 2024-10-25

* Use a `const` and binary search instead of a match

* Fix formatting

* Use `rustc`'s knowledge of LLVM/Clang target triples (rust-lang#1252)

* Rename Target -> TargetInfo

* Add LLVM target triple to TargetInfo

* Remove AppleOs wrapper struct

* Simplify SDK name lookup code

* Fix passing --target to Clang

Use the same LLVM target triple as rustc does

* Don't pass `--target` twice on Windows

* Simplify LLVM target triple version removal

* Appease clippy

* Fix naming mistake

* Simplify

* chore: release v1.1.32 (rust-lang#1250)

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

* Reduce size of `cc::Build`  and size of generated targets (rust-lang#1257)

* chore: release v1.1.33 (rust-lang#1258)

* Apple: Remove redundant flags (rust-lang#1256)

* Refactor Apple flags

Non-functional change.

* Apple: Remove redundant architecture flags

The architecture is specified for Clang with the --target option, and
both -arch and -m32/-m64 are passed to GCC elsewhere (should probably be
changed to -march, but that's a different issue).

* Don't output version flag on Clang

It is redundant, the version is already specified in `-target`.

* Appease clippy

* chore: release v1.1.34 (rust-lang#1259)

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

* Use -windows-gnu for all UEFI targets (rust-lang#1264)

This restores the behavior prior to
rust-lang#1252, when the UEFI targets were
hardcoded in src/lib.rs.

* Do not add -fPIC by default on UEFI targets (rust-lang#1263)

This fixes a regression caused by 290a629.

* Remove support for FRC (rust-lang#1268)

* chore: release v1.1.35 (rust-lang#1267)

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

* Fix CUDA build with clang++. (rust-lang#1273)

* chore: release v1.1.36 (rust-lang#1274)

* Regenerate target info (rust-lang#1280)

* Use relative directory for obj files hash (rust-lang#1270)

* chore: release v1.1.37 (rust-lang#1282)

* Fix WASM vs. WASI options (rust-lang#1284)

* windows_registry: Allow only specifying the architecture (rust-lang#1285)

* feat: add i686-pc-windows-gnullvm prefix detection (rust-lang#1283)

* chore: release v1.1.38 (rust-lang#1286)

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

* When invoking `cl -?`, set stdin to null (rust-lang#1288)

* chore: release v1.2.1 (rust-lang#1289)

* CI: Cap release at once per week (rust-lang#1291)

Signed-off-by: Jiahao XU <Jiahao_XU@outlook.com>

* Regenerate target info (rust-lang#1293)

* Allow disabling cc's ability to compile via env var CC_FORCE_DISABLE (rust-lang#1292)

* Fix two files with different extensions having the same object name (rust-lang#1295)

* Fix: Fetch target info from Cargo even if `Build::target` is manually set (rust-lang#1299)

* Fix compilation of C++ code for armv7-unknown-linux-gnueabihf (rust-lang#1298)

* Regenerate target info (rust-lang#1301)

Co-authored-by: github-actions <github-actions@github.com>

* CI: Avoid running scheduled jobs on forks (rust-lang#1302)

* Fix msvc stdout not shown on error (rust-lang#1303)

* Fix msvc stdout not shown on error

Fixed rust-lang#1260

* Fix clippy lint

* Call disable_localization unconditionally

* Call disable_localization in try_get_compiler`

* Set localization env based on msvc

* Fix setting env

* Fix fmt

* Fix confusing wording in comment

* Add support for using sccache wrapper with cuda/nvcc (rust-lang#1304)

* build: Inherit flags from rustc (rust-lang#1279)

* chore: release v1.2.2 (rust-lang#1306)

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

* Optimize RustcCodegenFlags (rust-lang#1305)

* Optimize RustcCodegenFlags

Use `&str` instead of `String`.

* Fix lifetime annotations

* Fix compilation

* Fix lifetime in flags.rs

And remove unnecessary `.into()`

* Fix compilation in flags.rs: Avoid allocation in prefix handling

* FIx cargo-fmt in flags.rs

* Better error message when failing on unknown targets (rust-lang#1313)

* Improve detection of environment when compiling from msbuild or msvc (rust-lang#1310)

* Enable manual-run of release-pr.yml (rust-lang#1318)

* chore: release v1.2.3 (rust-lang#1316)

* use -maix64 instead of -m64 (rust-lang#1307)

* Add support for C/C++ compiler for Neutrino QNX: `qcc` (rust-lang#1319)

* chore: release v1.2.4 (rust-lang#1320)

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

* Check linking when testing if compiler flags are supported (rust-lang#1322)

* chore: release v1.2.5 (rust-lang#1323)

* Don't inherit the `/Oy` flag for 64-bit targets (rust-lang#1330)

* chore: release v1.2.6 (rust-lang#1333)

* CI: Fix caching (rust-lang#1334)

* CI: Fix caching

Create lockfile before invoking rust-cache to make sure it is invalidated when new versions of dependencies have released

* Fix main.yml

* Allow using Visual Studio target names in `find_tool` (rust-lang#1335)

* Allow using VS target names in find_tool

Also fix a bug in vs15plus_vc_paths due to shadowing of the `target` variable.

* code review update

* Fix is_flag_supported on msvc (rust-lang#1336)

* Make is_flag_supported_inner take an &Tool (rust-lang#1337)

* Document new supported architecture names in windows::find

* CI: Add "test-pass" job (rust-lang#1340)

* Regenerate target info (rust-lang#1342)

* chore: release v1.2.7 (rust-lang#1341)

* Fix cuda testing (rust-lang#1343)

Fix feature name

* Optimize CI (rust-lang#1344)

Parameterize cargo flags into matrix for parallel building and better caching

* Fix clippy warnings (rust-lang#1346)

Signed-off-by: Jiahao XU <Jiahao_XU@outlook.com>

* Update `windows-bindgen` dependency (rust-lang#1347)

* Run regenerate-target-info on Thu (rust-lang#1349)

And run whenever the generation code has changed.

* Run regenerate-windows-sys on Thu (rust-lang#1348)

And run whenever the generation code has changed.

* Fix compiler family detection issue with clang-cl on macOS (rust-lang#1328)

* Fix opening PR in regenerate-target-info.yml (rust-lang#1351)

* Regenerate target info (rust-lang#1352)

* Fix opening PR in regenerate-windows-sys.yml (rust-lang#1353)

* Fix clippy error in lib.rs (rust-lang#1356)

* tool: Add `is_like_clang_cl()` getter (rust-lang#1357)

* chore: release v1.2.8 (rust-lang#1355)

* Fix compilation on macOS using clang and fix compilation using zig-cc (rust-lang#1364)

* Fix compilation on macOS using clang and fix zig-cc

* Reenable test detecting the regression

* Fix fmt in tool.rs

* Add comment

* Adjusted zig cc judgment and avoided zigbuild errors(rust-lang#1360) (rust-lang#1361)

* Adjusted zig cc judgment and avoided zigbuild errors(rust-lang#1360)

Adjusted is_zig_cc judgment and adjusted how supports_path_delimiter is handled.

* Update src/lib.rs

Co-authored-by: Jiahao XU <30436523+NobodyXu@users.noreply.github.com>

* typo fix and format check

cargo fmt --check

* Revert "Update src/lib.rs"

This reverts commit a69d8bb.

---------

Co-authored-by: Jiahao XU <30436523+NobodyXu@users.noreply.github.com>

* build: Don't pass inherited PGO flags to GNU compilers (rust-lang#1363)

Clang and GNU use different PGO libraries, so PGO flags inherited
from rustc should not automatically be passed to GNU compilers.

Fixes rust-lang#1354

* chore: release v1.2.9 (rust-lang#1365)

* Make hidden lifetimes explicit. (rust-lang#1366)

Mainline rustc has deprecated hidden lifetime parameters.

This change is required to build rustc with your own cc-rs fork.

* chore(ci): move ubuntu-20 job to ubuntu-22 (rust-lang#1368)

* Regenerate target info (rust-lang#1369)

* Fix CC_FORCE_DISABLE=0 evaluating to true (rust-lang#1371)

* chore: release v1.2.10 (rust-lang#1370)

* Update rusqlite requirement from 0.32.0 to 0.33.0 (rust-lang#1374)

* Regenerate target info (rust-lang#1376)

* Pass deployment target with `-m*-version-min=` (rust-lang#1339)

* Constrain `-Clto` and `-Cembed-bitcode` flag inheritance to be `clang`-only (rust-lang#1379)

* Include wrapper args. in `stdout` family heuristics to restore classifying `clang --driver-mode=cl` as `Msvc { clang_cl: true }` (rust-lang#1378)

* Fix more flag inheritance (rust-lang#1380)

* chore: release v1.2.11 (rust-lang#1377)

* Don't specify both `-target` and `-mtargetos=` on Apple targets (rust-lang#1384)

* allow specifying `rustc` when generating target information (rust-lang#1385)

* test: ensure `clang --driver-mode=cl` is MSVC- and `clang-cl`-like (rust-lang#1381)

* Split impl Build (rust-lang#1382)

* chore: release v1.2.12 (rust-lang#1387)

* Fix cross-compiling for Apple platforms (rust-lang#1389)

* chore: release v1.2.13 (rust-lang#1394)

* Add support for alternative network stack io-sock on QNX 7.1 aarch64 and x86_64 (rust-lang#1312)

* Add support for setting `-gdwarf-{version}` based on RUSTFLAGS (rust-lang#1395)

Detect if `-Zdwarf-version` (which will probably be stabilized soon
as `-Cdwarf-version`) was passed in RUSTFLAGS and set the corresponding
Clang/GCC option to the same value.

* Regenerate target info (rust-lang#1398)

* chore: release v1.2.14 (rust-lang#1400)

* Simplify the error output on failed `Command` invocation (rust-lang#1397)

* Always read from all `CFLAGS`-style flags (rust-lang#1401)

* Regenerate target info (rust-lang#1406)

* chore: release v1.2.15 (rust-lang#1408)

* Fix archiver detection for musl cross compilation (rust-lang#1404)

* Update windows-bindgen requirement from 0.59 to 0.60 (rust-lang#1412)

* Change flag ordering (rust-lang#1403)

* fix: force windows compiler to run in `out_dir` to prevent artifacts in cwd (rust-lang#1415)

* MSVC: Add LIB var when compiling flag_check (rust-lang#1417)

* Regenerate target info (rust-lang#1418)

* Fix regenerate-windows-sys.yml (rust-lang#1420)

Should run whenever the code is updated

* Fix gen-windows-sys-binding (rust-lang#1419)

--no-core is renamed to --no-deps

* Regenerate windows-sys binding (rust-lang#1422)

* Rename windows_targets.rs to windows_link.rs

* Update windows/mod.rs

* Fix windows-bindgen

* update windows-sys binding

* clang-cl: use `/arch:SSE2` for `x86` target arch (rust-lang#1425)

- Official Rust Windows targets require `SSE2` as part of baseline
  target features.
    - `i586` Windows target without SSE2 is in process of being removed,
      so wasn't changed in this commit.
- STL is built with `/arch:SSE2` and no longer `/arch:IA32` since
  <microsoft/STL#4741>.

This was noticed in rust-lang/rust CI for `i686-pc-windows-msvc`, where
`rustc_llvm` builds failed because `__m128i` wasn't available, and we
suspected it was due to `/arch:IA32`.

* chore: release v1.2.16 (rust-lang#1427)

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

* Update rusqlite requirement from 0.33.0 to 0.34.0 (rust-lang#1428)

* Added base support for `wasm32-wali-linux-musl` target (rust-lang#1373)

* Regenerate target info (rust-lang#1429)

* Parse `rustc` target names (rust-lang#1413)

Parse target names instead of using a pre-generated list.
Allows target names like those used by certain Linux distributions,
even when compiling outside build.rs.

* Fix failure from cargo not propagating because of pipe (rust-lang#1432)

* ci: fix creating issue comment (rust-lang#1433)

* Fix wasm32-wali-linux-musl target parsing (rust-lang#1434)

* Update windows-bindgen requirement from 0.60 to 0.61 (rust-lang#1436)

* Regenerate windows sys bindings (rust-lang#1437)

* Regenerate target info (rust-lang#1439)

* chore: release v1.2.17 (rust-lang#1435)

* Use compiler prefix `x86_64-linux-musl` (rust-lang#1443)

* Fix mips64-openwrt-linux-musl parsing (rust-lang#1449)

* Use `std::thread::available_parallelism` for determining the default number of jobs (rust-lang#1447)

* Regenerate target info (rust-lang#1450)

* chore: release v1.2.18 (rust-lang#1451)

* Fix musl compilation: Add musl as a prefix fallback (rust-lang#1455)

Fixed rust-lang#1452

* chore: release v1.2.19 (rust-lang#1458)

* Fix parser.rs on latest rustc nightly (rust-lang#1459)

Fixes rust-lang#1426

* Update rusqlite requirement from 0.34.0 to 0.35.0 (rust-lang#1460)

* Regenerate target info (rust-lang#1461)

* chore: release v1.2.20 (rust-lang#1462)

* Fix wasm32-unknown-unknown by passing -c (rust-lang#1424)

* Fix wasm32-unknown-unknown by passing -c

Fix rust-lang#1423

* Update lib.rs

Co-authored-by: Mads Marquart <mads@marquart.dk>

---------

Co-authored-by: Mads Marquart <mads@marquart.dk>

* chore: release v1.2.21 (rust-lang#1464)

* Add `flags` method to `cc::Build` for adding multiple flags (rust-lang#1466)

* chore: release v1.2.22 (rust-lang#1467)

* support "vxworks" and "nto" OSes on `get_base_archiver_variant` (rust-lang#1456)

* chore: release v1.2.23 (rust-lang#1470)

* Regenerate windows sys bindings (rust-lang#1471)

* chore: release v1.2.24 (rust-lang#1472)

* Update rusqlite requirement from 0.35.0 to 0.36.0 (rust-lang#1476)

* make `powerp64` use `powerpc64-linux-gnu` prefix (rust-lang#1474)

It used `powerpc-linux-gnu` before, which is 32-bit powerpc

* chore: release v1.2.25 (rust-lang#1478)

* Detect -Wslash-u-filename warning on clang-cl (rust-lang#1477)

* use windows 2022 in CI (rust-lang#1479)

* Also set `SDKROOT` when building apple platforms (rust-lang#1475)

* chore: release v1.2.26 (rust-lang#1481)

* Regenerate target info (rust-lang#1483)

* Update windows-bindgen requirement from 0.61 to 0.62 (rust-lang#1484)

* Regenerate windows sys bindings (rust-lang#1485)

* chore: release v1.2.27 (rust-lang#1486)

* Fix clippy warnings about not using variables in `format!` strings (rust-lang#1489)

* Recognize `mlibc` environment (rust-lang#1488)

* chore: release v1.2.28 (rust-lang#1491)

* [BlueOS] Support vivo BlueOS's toolchain

Adapted to cc-rs 1.2.28's TargetInfo struct API when resolving
conflicts; the -mfloat-abi=hard check is now
`target.arch == "arm" && target.abi == "eabihf"`.

(cherry picked from commit f158c93)

---------

Signed-off-by: Jiahao XU <Jiahao_XU@outlook.com>
Co-authored-by: Jiahao XU <30436523+NobodyXu@users.noreply.github.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Mads Marquart <mads@marquart.dk>
Co-authored-by: Graydon Hoare <graydon@pobox.com>
Co-authored-by: Trevor Gross <t.gross35@gmail.com>
Co-authored-by: github-actions <github-actions@github.com>
Co-authored-by: Nicholas Bishop <nbishop@nbishop.net>
Co-authored-by: Andy Polyakov <9038069+dot-asm@users.noreply.github.com>
Co-authored-by: Nicolas Mattia <nicolas@nmattia.com>
Co-authored-by: Mateusz Mikuła <mati865@users.noreply.github.com>
Co-authored-by: Chris Denton <chris@chrisdenton.dev>
Co-authored-by: Simon Hausmann <hausmann@gmail.com>
Co-authored-by: Frank Laub <github@frank.laub.io>
Co-authored-by: Kajetan Puchalski <kajetan.puchalski@tuta.io>
Co-authored-by: David Lönnhager <dv.lnh.d@gmail.com>
Co-authored-by: Henry Jiang <h243jian@uwaterloo.ca>
Co-authored-by: Florian Bartels <108917393+flba-eb@users.noreply.github.com>
Co-authored-by: clubby789 <jamie@hill-daniel.co.uk>
Co-authored-by: Kenny Kerr <kenny@kennykerr.ca>
Co-authored-by: Marijn Suijten <marijns95@gmail.com>
Co-authored-by: Masato TOYOSHIMA <77603626+phoepsilonix@users.noreply.github.com>
Co-authored-by: Kajetan Puchalski <kajetan.puchalski@kajetanp.co.uk>
Co-authored-by: tnewsome-lynx <tnewsome@lynx.com>
Co-authored-by: Marco Ieni <11428655+marcoieni@users.noreply.github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: 许杰友 Jieyou Xu (Joe) <39484203+jieyouxu@users.noreply.github.com>
Co-authored-by: Erich Gubler <erichdongubler@gmail.com>
Co-authored-by: Josh Junon <Qix-@users.noreply.github.com>
Co-authored-by: Wesley Wiser <wwiser@gmail.com>
Co-authored-by: Melvin Wang <melvin.mc.wang@gmail.com>
Co-authored-by: Arjun Ramesh <90422058+arjunr2@users.noreply.github.com>
Co-authored-by: Justin W Smith <103147162+justsmth@users.noreply.github.com>
Co-authored-by: Jakub Beránek <berykubik@gmail.com>
Co-authored-by: fiveseven <44082628+fiveseven-lambda@users.noreply.github.com>
Co-authored-by: Onur Özkan <onurozkan.dev@outlook.com>
Co-authored-by: Folkert de Vries <flokkievids@gmail.com>
Co-authored-by: Paul Wagener <mail@paulwagener.nl>
Co-authored-by: Ronny Chan <ronny6993@gmail.com>
Co-authored-by: no92 <no92@users.noreply.github.com>
Co-authored-by: Kai Law <lawkai@vivo.com>
Co-authored-by: Han Jiang <jianghan@vivo.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@madsmtm madsmtm madsmtm approved these changes
@NobodyXu NobodyXu NobodyXu approved these changes

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@wesleywiser @madsmtm @NobodyXu