rust/compiler/rustc_codegen_llvm/src/debuginfo, branch 1.86.0

Rollup merge of #136895 - maurer:fix-enum-discr, r=nikic

2025-02-14T01:46:08+00:00

debuginfo: Set bitwidth appropriately in enum variant tags Previously, we unconditionally set the bitwidth to 128-bits, the largest an enum would possibly be. Then, LLVM would cut down the constant by chopping off leading zeroes before emitting the DWARF. LLVM only supported 64-bit enumerators, so this would also have occasionally resulted in truncated data. LLVM added support for 128-bit enumerators in llvm/llvm-project#125578 That patchset trusts the constant to describe how wide the variant tag is, so the high 64-bits of zeros are considered potentially load-bearing. As a result, we went from emitting tags that looked like: DW_AT_discr_value (0xfe) (because `dwarf::BestForm` selected `data1`) to emitting tags that looked like: DW_AT_discr_value (<0x10> fe ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00 ) This makes the `DW_AT_discr_value` encode at the bitwidth of the tag, which: 1. Is probably closer to our intentions in terms of describing the data. 2. Doesn't invoke the 128-bit support which may not be supported by all debuggers / downstream tools. 3. Will result in smaller debug information.

debuginfo: Set bitwidth appropriately in enum variant tags

2025-02-12T18:01:42+00:00

Previously, we unconditionally set the bitwidth to 128-bits, the largest an discrimnator would possibly be. Then, LLVM would cut down the constant by chopping off leading zeroes before emitting the DWARF. LLVM only supported 64-bit descriminators, so this would also have occasionally resulted in truncated data (or an assert) if more than 64-bits were used. LLVM added support for 128-bit enumerators in llvm/llvm-project#125578 That patchset also trusts the constant to describe how wide the variant tag is. As a result, we went from emitting tags that looked like: DW_AT_discr_value (0xfe) (`form1`) to emitting tags that looked like: DW_AT_discr_value (<0x10> fe ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00 ) This makes the `DW_AT_discr_value` encode at the bitwidth of the tag, which: 1. Is probably closer to our intentions in terms of describing the data. 2. Doesn't invoke the 128-bit support which may not be supported by all debuggers / downstream tools. 3. Will result in smaller debug information.

Document some safety constraints and use more safe wrappers

2025-02-11T09:47:13+00:00

Auto merge of #136751 - bjorn3:update_rustfmt, r=Mark-Simulacrum

2025-02-09T15:44:16+00:00

Update bootstrap compiler and rustfmt The rustfmt version we previously used formats things differently from what the latest nightly rustfmt does. This causes issues for subtrees that get formatted both in-tree and in their own repo. Updating the rustfmt used in-tree solves those issues. Also bumped the bootstrap compiler as the stage0 update command always updates both at the same time.

Rollup merge of #136659 - wesleywiser:dwarf_version_lto_merge_behavior, r=jieyouxu

2025-02-08T23:37:28+00:00

Pick the max DWARF version when LTO'ing modules with different versions Currently, when rustc compiles code with `-Clto` enabled that was built with different choices for `-Zdwarf-version`, a warning will be reported. It's very easy to observe this by compiling most anything (eg, "hello world") and specifying `-Clto -Zdwarf-version=5` since the standard library is distributed with `-Zdwarf-version=4`. This behavior isn't actually useful for a few reasons: - From observation, LLVM chooses to pick the highest DWARF version anyway after issuing the warning. - Clang specifies that in this case, the max version should be picked without a warning and as a general principle, we want to support x-lang LTO with Clang which implies using the same module flag merge behaviors. - Debuggers need to be able to handle a variety of versions within the same debugging session as you can easily have some parts of a binary (or some dynamic libraries within an application) all compiled with different DWARF versions. This commit changes the module flag merge behavior to match Clang and use the highest version of DWARF. It also adds a test to ensure this behavior is respected in the case of two crates being LTO'd together and adds a test to ensure no warning is printed. Fixes #130041 which fails due to these warnings being printed cc #103057

Rustfmt

2025-02-08T22:12:13+00:00

Pick the max DWARF version when LTO'ing modules with different versions

2025-02-08T16:33:36+00:00

Currently, when rustc compiles code with `-Clto` enabled that was built with different choices for `-Zdwarf-version`, a warning will be reported. It's very easy to observe this by compiling most anything (eg, "hello world") and specifying `-Clto -Zdwarf-version=5` since the standard library is distributed with `-Zdwarf-version=4`. This behavior isn't actually useful for a few reasons: - from observation, LLVM chooses to pick the highest DWARF version anyway after issuing the warning - Clang specifies that in this case, the max version should be picked without a warning and as a general principle, we want to support x-lang LTO with Clang which implies using the same module flag merge behaviors - Debuggers need to be able to handle a variety of versions withing the same debugging session as you can easily have some parts of a binary (or some dynamic libraries within an application) all compiled with different DWARF versions This commit changes the module flag merge behavior to match Clang and use the highest version of DWARF. It also adds a test to ensure this behavior is respected in the case of two crates being LTO'd together and updates the test added in the previous commit to ensure no warning is printed.

Rollup merge of #136640 - Zalathar:debuginfo-align-bits, r=compiler-errors

2025-02-08T02:58:45+00:00

Debuginfo for function ZSTs should have alignment of 8 bits, not 1 bit In #116096, function ZSTs were made to have debuginfo that gives them an alignment of “1”. But because alignment in LLVM debuginfo is denoted in *bits*, not bytes, this resulted in an alignment specification of 1 bit instead of 1 byte. I don't know whether this has any practical consequences, but I noticed that a test started failing when I accidentally fixed the mistake while working on #136632, so I extracted the fix (and the test adjustment) to this PR.

Debuginfo for function ZSTs should have alignment of 8 bits, not 1 bit

2025-02-06T12:01:29+00:00

Auto merge of #136471 - safinaskar:parallel, r=SparrowLii

2025-02-06T10:50:05+00:00

tree-wide: parallel: Fully removed all `Lrc`, replaced with `Arc` tree-wide: parallel: Fully removed all `Lrc`, replaced with `Arc` This is continuation of https://github.com/rust-lang/rust/pull/132282 . I'm pretty sure I did everything right. In particular, I searched all occurrences of `Lrc` in submodules and made sure that they don't need replacement. There are other possibilities, through. We can define `enum Lrc { Rc(Rc), Arc(Arc) }`. Or we can make `Lrc` a union and on every clone we can read from special thread-local variable. Or we can add a generic parameter to `Lrc` and, yes, this parameter will be everywhere across all codebase. So, if you think we should take some alternative approach, then don't merge this PR. But if it is decided to stick with `Arc`, then, please, merge. cc "Parallel Rustc Front-end" ( https://github.com/rust-lang/rust/issues/113349 ) r? SparrowLii `@rustbot` label WG-compiler-parallel