https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=1.82.0 2024-08-31T09:29:02+00:00 2024-08-31T09:29:02+00:00 Ralf Jung post@ralfj.de 2024-08-31T09:29:02+00:00 urn:sha1:d0aedfbb900309bb633b3ba04bf008183cfdd9a7 2024-08-27T06:46:49+00:00 Trevor Gross t.gross35@gmail.com 2024-08-27T06:46:49+00:00 urn:sha1:9c26ebe32ed365a7ddb610236a2619ef52960da8 Implement `-Z embed-source` (DWARFv5 source code embedding extension) Implement https://github.com/rust-lang/compiler-team/issues/764 MCP which adds an unstable flag that exposes LLVM's [DWARFv5 source code embedding](https://dwarfstd.org/issues/180201.1.html) support. 2024-08-26T22:41:57+00:00 Matthias Krüger matthias.krueger@famsik.de 2024-08-26T22:41:57+00:00 urn:sha1:110c3df7fd48904bf714d02201bccb80695fc690 Add `#[warn(unreachable_pub)]` to a bunch of compiler crates By default `unreachable_pub` identifies things that need not be `pub` and tells you to make them `pub(crate)`. But sometimes those things don't need any kind of visibility. So they way I did these was to remove the visibility entirely for each thing the lint identifies, and then add `pub(crate)` back in everywhere the compiler said it was necessary. (Or occasionally `pub(super)` when context suggested that was appropriate.) Tedious, but results in more `pub` removal. There are plenty more crates to do but this seems like enough for a first PR. r? `@compiler-errors` 2024-08-21T16:15:04+00:00 Matthias Krüger matthias.krueger@famsik.de 2024-08-21T16:15:04+00:00 urn:sha1:e961d6b2048e097bc92cab91020ab884b333b043 Avoid extra `cast()`s after `CStr::as_ptr()` These used to be `&str` literals that did need a pointer cast, but that became a no-op after switching to `c""` literals in #118566. 2024-08-21T16:15:01+00:00 Matthias Krüger matthias.krueger@famsik.de 2024-08-21T16:15:01+00:00 urn:sha1:dea325e583adfcb9fec771da547dc304e79a5ee2 Special case DUMMY_SP to emit line 0/column 0 locations on DWARF platforms. Line 0 has a special meaning in DWARF. From the version 5 spec: The compiler may emit the value 0 in cases where an instruction cannot be attributed to any source line. DUMMY_SP spans cannot be attributed to any line. However, because rustc internally stores line numbers starting at zero, lookup_debug_loc() adjusts every line number by one. Special casing DUMMY_SP to actually emit line 0 ensures rustc communicates to the debugger that there's no meaningful source code for this instruction, rather than telling the debugger to jump to line 1 randomly. 2024-08-20T21:04:48+00:00 Josh Stone jistone@redhat.com 2024-08-20T21:04:48+00:00 urn:sha1:e424e7fcaacf1bd26584a2ecf50299c0058fbba5 These used to be `&str` literals that did need a pointer cast, but that became a no-op after switching to `c""` literals in #118566. 2024-08-20T00:13:30+00:00 Kyle Huey khuey@kylehuey.com 2024-08-20T00:13:30+00:00 urn:sha1:4e9725cd2f5327f65f881c59d6bcbae46308318e 2024-08-15T22:46:57+00:00 Nicholas Nethercote n.nethercote@gmail.com 2024-07-06T12:26:42+00:00 urn:sha1:61627438ebb72977c8480a2d8b573137cfecefb1 2024-08-15T11:42:15+00:00 bors bors@rust-lang.org 2024-08-15T11:42:15+00:00 urn:sha1:3139ff09e9d07f7700f8d15ed25a231e29c43627 Rework MIR inlining debuginfo so function parameters show up in debuggers. Line numbers of multiply-inlined functions were fixed in #114643 by using a single DISubprogram. That, however, triggered assertions because parameters weren't deduplicated. The "solution" to that in #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 (8b3870784 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. 2024-08-15T09:17:24+00:00 bors bors@rust-lang.org 2024-08-15T09:17:24+00:00 urn:sha1:026e9ed3f0c5b3ee6233fd23b5e497cb94cf6434 Use the `enum2$` Natvis visualiser for repr128 C-style enums Use the preexisting `enum2$` Natvis visualiser to allow PDB debuggers to display fieldless `#[repr(u128)]]`/`#[repr(i128)]]` enums correctly. Tracking issue: #56071 try-job: x86_64-msvc