Rollup of 6 pull requests #129022
Closed
Rollup of 6 pull requests #129022
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…gers. Line numbers of multiply-inlined functions were fixed in rust-lang#114643 by using a single DISubprogram. That, however, triggered assertions because parameters weren't deduplicated. The "solution" to that in rust-lang#115417 was to insert a DILexicalScope below the DISubprogram and parent all of the parameters to that scope. That fixed the assertion, but debuggers (including gdb and lldb) don't recognize variables that are not parented to the subprogram itself as parameters, even if they are emitted with DW_TAG_formal_parameter. Consider the program: use std::env; fn square(n: i32) -> i32 { n * n } fn square_no_inline(n: i32) -> i32 { n * n } fn main() { let x = square(env::vars().count() as i32); let y = square_no_inline(env::vars().count() as i32); println!("{x} == {y}"); } When making a release build with debug=2 and rustc 1.82.0-nightly (8b38707 2024-08-07) (gdb) r Starting program: /ephemeral/tmp/target/release/tmp [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Breakpoint 1, tmp::square () at src/main.rs:5 5 n * n (gdb) info args No arguments. (gdb) info locals n = 31 (gdb) c Continuing. Breakpoint 2, tmp::square_no_inline (n=31) at src/main.rs:10 10 n * n (gdb) info args n = 31 (gdb) info locals No locals. This issue is particularly annoying because it removes arguments from stack traces. The DWARF for the inlined function looks like this: < 2><0x00002132 GOFF=0x00002132> DW_TAG_subprogram DW_AT_linkage_name _ZN3tmp6square17hc507052ff3d2a488E DW_AT_name square DW_AT_decl_file 0x0000000f /ephemeral/tmp/src/main.rs DW_AT_decl_line 0x00000004 DW_AT_type 0x00001a56<.debug_info+0x00001a56> DW_AT_inline DW_INL_inlined < 3><0x00002142 GOFF=0x00002142> DW_TAG_lexical_block < 4><0x00002143 GOFF=0x00002143> DW_TAG_formal_parameter DW_AT_name n DW_AT_decl_file 0x0000000f /ephemeral/tmp/src/main.rs DW_AT_decl_line 0x00000004 DW_AT_type 0x00001a56<.debug_info+0x00001a56> < 4><0x0000214e GOFF=0x0000214e> DW_TAG_null < 3><0x0000214f GOFF=0x0000214f> DW_TAG_null That DW_TAG_lexical_block inhibits every debugger I've tested from recognizing 'n' as a parameter. This patch removes the additional lexical scope. Parameters can be easily deduplicated by a tuple of their scope and the argument index, at the trivial cost of taking a Hash + Eq bound on DIScope.
…, r=lcnr Normalize struct tail properly for `dyn` ptr-to-ptr casting in new solver Realized that the new solver didn't handle ptr-to-ptr casting correctly. r? lcnr Built on rust-lang#128694
…ginfo, r=wesleywiser Rework MIR inlining debuginfo so function parameters show up in debuggers. Line numbers of multiply-inlined functions were fixed in rust-lang#114643 by using a single DISubprogram. That, however, triggered assertions because parameters weren't deduplicated. The "solution" to that in rust-lang#115417 was to insert a DILexicalScope below the DISubprogram and parent all of the parameters to that scope. That fixed the assertion, but debuggers (including gdb and lldb) don't recognize variables that are not parented to the subprogram itself as parameters, even if they are emitted with DW_TAG_formal_parameter. Consider the program: ```rust use std::env; #[inline(always)] fn square(n: i32) -> i32 { n * n } #[inline(never)] fn square_no_inline(n: i32) -> i32 { n * n } fn main() { let x = square(env::vars().count() as i32); let y = square_no_inline(env::vars().count() as i32); println!("{x} == {y}"); } ``` When making a release build with debug=2 and rustc 1.82.0-nightly (8b38707 2024-08-07) ``` (gdb) r Starting program: /ephemeral/tmp/target/release/tmp [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Breakpoint 1, tmp::square () at src/main.rs:5 5 n * n (gdb) info args No arguments. (gdb) info locals n = 31 (gdb) c Continuing. Breakpoint 2, tmp::square_no_inline (n=31) at src/main.rs:10 10 n * n (gdb) info args n = 31 (gdb) info locals No locals. ``` This issue is particularly annoying because it removes arguments from stack traces. The DWARF for the inlined function looks like this: ``` < 2><0x00002132 GOFF=0x00002132> DW_TAG_subprogram DW_AT_linkage_name _ZN3tmp6square17hc507052ff3d2a488E DW_AT_name square DW_AT_decl_file 0x0000000f /ephemeral/tmp/src/main.rs DW_AT_decl_line 0x00000004 DW_AT_type 0x00001a56<.debug_info+0x00001a56> DW_AT_inline DW_INL_inlined < 3><0x00002142 GOFF=0x00002142> DW_TAG_lexical_block < 4><0x00002143 GOFF=0x00002143> DW_TAG_formal_parameter DW_AT_name n DW_AT_decl_file 0x0000000f /ephemeral/tmp/src/main.rs DW_AT_decl_line 0x00000004 DW_AT_type 0x00001a56<.debug_info+0x00001a56> < 4><0x0000214e GOFF=0x0000214e> DW_TAG_null < 3><0x0000214f GOFF=0x0000214f> DW_TAG_null ``` That DW_TAG_lexical_block inhibits every debugger I've tested from recognizing 'n' as a parameter. This patch removes the additional lexical scope. Parameters can be easily deduplicated by a tuple of their scope and the argument index, at the trivial cost of taking a Hash + Eq bound on DIScope.
…mpl, r=lcnr Store `do_not_recommend`-ness in impl header Alternative to rust-lang#128674 It's less flexible, but also less invasive. Hopefully it's also performant. I'd recommend we think separately about the design for how to gate arbitrary diagnostic attributes moving forward.
…nur-ozkan bootstrap: clear miri ui-test deps when miri sysroot gets rebuilt Second attempt after rust-lang#128683: seems like it's not the compiler changing that we care about, but the sysroot changing. I did some local testing with sysroot rebuilds and it works fine for at least those cases I checked. r? `@onur-ozkan`
…-file, r=jieyouxu Remove unused script from run-make tests Its last usage was removed in rust-lang#128636. Tracking issue: rust-lang#121876 r? jieyouxu
…=Noratrieb Replace `std::fmt:FormatterFn` with `std::fmt::from_fn` Modelled after the suggestion made in [this](rust-lang#117729 (comment)) comment, this should bring this functionality in line with the existing `array::from_fn` & `iter::from_fn`
rustbot
added
A-run-make
|
@bors r+ rollup=never p=6 |
bors
added
S-waiting-on-bors
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Aug 12, 2024
…iaskrgr Rollup of 6 pull requests Successful merges: - rust-lang#128712 (Normalize struct tail properly for `dyn` ptr-to-ptr casting in new solver) - rust-lang#128861 (Rework MIR inlining debuginfo so function parameters show up in debuggers.) - rust-lang#128912 (Store `do_not_recommend`-ness in impl header) - rust-lang#129000 (bootstrap: clear miri ui-test deps when miri sysroot gets rebuilt) - rust-lang#129013 (Remove unused script from run-make tests) - rust-lang#129017 (Replace `std::fmt:FormatterFn` with `std::fmt::from_fn`) Failed merges: - rust-lang#128935 (More work on `zstd` compression) r? `@ghost` `@rustbot` modify labels: rollup
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
dynptr-to-ptr casting in new solver #128712 (Normalize struct tail properly fordynptr-to-ptr casting in new solver)do_not_recommend-ness in impl header #128912 (Storedo_not_recommend-ness in impl header)std::fmt:FormatterFnwithstd::fmt::from_fn#129017 (Replacestd::fmt:FormatterFnwithstd::fmt::from_fn)Failed merges:
zstdcompression #128935 (More work onzstdcompression)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup