LLDB show a non existing variable at O1

[lucamassarelli]

LLDB show variable 'res' (when stepping at line 12) that does not exists in the code.

$ cat -n a.rs 
     1  // run-pass
     2  use std::ptr;
     3  use std::rc::Rc;
     4  use std::sync::Arc;
     5
     6  fn main() {
     7      let p: *const u8 = ptr::null();
     8      let rc = Rc::new(1usize);
     9      let arc = Arc::new(1usize);
    10      let b = Box::new("hi");
    11
    12      let _ = format!("{:p}{:p}{:p}",
    13                      rc, arc, b);
    14
    15      if cfg!(target_pointer_width = "32") {
    16          assert_eq!(format!("{:#p}", p),
    17                     "0x00000000");
    18      } else {
    19          assert_eq!(format!("{:#p}", p),
    20                     "0x0000000000000000");
    21      }
    22      assert_eq!(format!("{:p}", p),
    23                 "0x0");
    24  }

$ cat a.rs 
// run-pass
use std::ptr;
use std::rc::Rc;
use std::sync::Arc;
fn main() {
    let p: *const u8 = ptr::null();
    let rc = Rc::new(1usize);
    let arc = Arc::new(1usize);
    let b = Box::new("hi");
    let _ = format!("{:p}{:p}{:p}",
                    rc, arc, b);
    if cfg!(target_pointer_width = "32") {
        assert_eq!(format!("{:#p}", p),
                   "0x00000000");
    } else {
        assert_eq!(format!("{:#p}", p),
                   "0x0000000000000000");
    }
    assert_eq!(format!("{:p}", p),
               "0x0");
}

$ rustc --version
+rustc 1.46.0-nightly (3503f565e 2020-07-02)

$ lldb -v
lldb version 11.0.0
  clang revision ee26a31e7b02e124d71091d47f2ae624774e5e0a
  llvm revision ee26a31e7b02e124d71091d47f2ae624774e5e0a

$ rustc -g -C opt-level=1 -o opt a.rs

$ lldb opt
lldb opt 
(lldb) target create "opt"
Current executable set to 'opt' (x86_64).
(lldb) b -l 12
Breakpoint 1: 2 locations.
(lldb) r
Process 62 launched: 'opt' (x86_64)
Process 62 stopped
* thread #1, name = 'opt', stop reason = breakpoint 1.1
    frame #0: 0x00005555555590f6 opt`a::main::h1122ef72fcd4218b at a.rs:12:13
   9        let arc = Arc::new(1usize);
   10       let b = Box::new("hi");
   11  
-> 12       let _ = format!("{:p}{:p}{:p}",
   13                       rc, arc, b);
   14  
   15       if cfg!(target_pointer_width = "32") {
(lldb) frame var
(unsigned char *) p = <empty constant data>
(alloc::rc::Rc<unsigned long>) rc = <variable not available>
(alloc::sync::Arc<unsigned long>) arc = <variable not available>
(&str *) b = 0x000055555578fa80
(lldb) c
Process 62 resuming
Process 62 stopped
* thread #1, name = 'opt', stop reason = breakpoint 1.2
    frame #0: 0x000055555555918f opt`a::main::h1122ef72fcd4218b at a.rs:12:13
   9        let arc = Arc::new(1usize);
   10       let b = Box::new("hi");
   11  
-> 12       let _ = format!("{:p}{:p}{:p}",
   13                       rc, arc, b);
   14  
   15       if cfg!(target_pointer_width = "32") {
(lldb) frame var
(unsigned char *) p = <empty constant data>
(alloc::rc::Rc<unsigned long>) rc = <variable not available>
(alloc::sync::Arc<unsigned long>) arc = <variable not available>
(&str *) b = <variable not available>
(alloc::string::String) res = {
  vec = {
    buf = {
      ptr = (pointer = "0x55555578fa500x55555578fa700x55555578fa80\U00000002", _marker = core::marker::PhantomData<unsigned char> @ 0x00007fffffffe290)

[wesleywiser]

res is a variable introduced by the format!() macro which is why it shows at that line

rust/src/liballoc/macros.rs

Lines 105 to 110 in 0c03aee

	macro_rules! format {
	($($arg:tt)*) => {{
	let res = $crate::fmt::format($crate::__export::format_args!($($arg)*));
	res
	}}
	}

I'm not sure if this is a bug or not.

[wesleywiser]

Visited during wg-debugging tirage. I believe this is "working as intended". If we do not generate debuginfo for variables resulting from macro-expansion, then the user has not option to inspect them in the debugger. If we do, there could be extraneous variables shown but the user is always free to ignore them. Ideally we would be able to tag these as introduced by the macro but I'm not aware of any DWARF/CodeView features that would allow us to do that.

Retagging as E-needs-test so that we can lock this behavior in.

[Enselic]

Triage: Hmm what would a good test for this look like?

We could add a test that ensure there is a res variable if format!() is used. But that's an implementation detail that we should not test IMHO.

How about we simply close this as "works as designed"?

[wesleywiser]

I think we want to introduce a macro we control the definition of and then call it like:

macro_rules! my_macro {
    () => {
        let introduced_by_my_macro = String::from("inside macro");
    }
}


pub fn foo() {
    my_macro!();
    break_here();
}   

#[inline(never)]
fn break_here() { }