MIR debuginfo: Capture by value contains additional dereference with `--edition 2021`

[prusovak2]

I tried this code:

closure_test.rs

fn main() {
    let x = "hello world";

    foo(x);
}

#[inline(never)]
pub fn foo(x: &str) {
    bar(|z|
        if x.len() == 0 { Ok(()) } else { Ok(()) });
}

#[inline(never)]
fn bar(f: impl FnOnce(&mut dyn Debug) -> Result<(), ()>) {
    let mut x = 10i32;
    f(&mut x);
}

https://rust.godbolt.org/z/8ErnGbG9z

When compiled with --edition 2021, it produces invalid debug info for capture of variable x.

rustc --edition 2021 -g closure_test.rs -Copt-level=0
gdb ./closure_test
...
(gdb) b closure_test.rs:12
Breakpoint 1 at 0x69f7: file closure_test.rs, line 12.
(gdb) r
...
Breakpoint 1, closure_test::foo::{{closure}} (z=...) at closure_test.rs:12
12              if x.len() == 0 { Ok(()) } else { Ok(()) });
(gdb) p x
$1 = 104

When compiled with --edition 2018, debug info is valid:

$ rustc --edition 2018 -g closure_test.rs -Copt-level=0
$ gdb ./closure_test
...
(gdb) b closure_test.rs:12
Breakpoint 1 at 0x69f3: file closure_test.rs, line 12.
(gdb) r
...
Breakpoint 1, closure_test::foo::{{closure}} (z=...) at closure_test.rs:12
12              if x.len() == 0 { Ok(()) } else { Ok(()) });
(gdb) p x
$1 = "hello world"

Problem seems to be in an addition dereference in MIR debug info:

Meta

rustc --version --verbose:

<version>

Backtrace

<backtrace>

[compiler-errors]

@wesleywiser and I discussed this.

This is somewhat related to

rust/compiler/rustc_codegen_llvm/src/debuginfo/metadata.rs

Lines 379 to 415 in 2a5da7a

	/// Create debuginfo for `[T]` and `str`. These are unsized.
	///
	/// NOTE: We currently emit just emit the debuginfo for the element type here
	/// (i.e. `T` for slices and `u8` for `str`), so that we end up with
	/// `*const T` for the `data_ptr` field of the corresponding wide-pointer
	/// debuginfo of `&[T]`.
	///
	/// It would be preferable and more accurate if we emitted a DIArray of T
	/// without an upper bound instead. That is, LLVM already supports emitting
	/// debuginfo of arrays of unknown size. But GDB currently seems to end up
	/// in an infinite loop when confronted with such a type.
	///
	/// As a side effect of the current encoding every instance of a type like
	/// `struct Foo { unsized_field: [u8] }` will look like
	/// `struct Foo { unsized_field: u8 }` in debuginfo. If the length of the
	/// slice is zero, then accessing `unsized_field` in the debugger would
	/// result in an out-of-bounds access.
	fn build_slice_type_di_node<'ll, 'tcx>(
	cx: &CodegenCx<'ll, 'tcx>,
	slice_type: Ty<'tcx>,
	unique_type_id: UniqueTypeId<'tcx>,
	) -> DINodeCreationResult<'ll> {
	let element_type = match slice_type.kind() {
	ty::Slice(element_type) => *element_type,
	ty::Str => cx.tcx.types.u8,
	_ => {
	bug!(
	"Only ty::Slice is valid for build_slice_type_di_node(). Found {:?} instead.",
	slice_type
	)
	}
	};
	let element_type_di_node = type_di_node(cx, element_type);
	return_if_di_node_created_in_meantime!(cx, unique_type_id);
	DINodeCreationResult { di_node: element_type_di_node, already_stored_in_typemap: false }
	}

.

The problem is that we produce VarDebugInfos with places that point to unsized memory. In codegen time, we should probably be emitting debuginfo for references to that place, since it's kinda futile to emit debuginfo for unsized places.