debuginfo/issue-22656.rs fails with LLVM/clang Assertion `Prior->FD->hasAttr<NoUniqueAddressAttr>() && "should not have reused this field's tail padding"' failed.

[eddyb]

I haven't been running debuginfo tests locally for a long while due to a variety of issues, but I was surprised to get only 1 failure, src/test/debuginfo/issue-22656.rs with LLDB:

python2.7: /home/eddy/Projects/rust-2/src/llvm-project/clang/lib/CodeGen/CGRecordLayoutBuilder.cpp:603:
  void (anonymous namespace)::CGRecordLowering::clipTailPadding():
  Assertion `Prior->FD->hasAttr<NoUniqueAddressAttr>() &&
    "should not have reused this field's tail padding"' failed.

If I had to guess, LLDB was trying to compile something as C++, and probably ran into something that's different in Rust (is it synthesizing C++ struct/union definitions from DWARF?).

cc @michaelwoerister

EDIT: this is the test, and, well, this looks like a regression?

rust/src/test/debuginfo/issue-22656.rs

Lines 1 to 49 in bea0372

	// This test makes sure that the LLDB pretty printer does not throw an exception
	// when trying to handle a Vec<> or anything else that contains zero-sized
	// fields.
	// min-lldb-version: 310
	// ignore-gdb
	// ignore-tidy-linelength
	// compile-flags:-g
	// === LLDB TESTS ==================================================================================
	// lldb-command:run
	// lldb-command:print v
	// lldbg-check:[...]$0 = vec![1, 2, 3]
	// lldbr-check:(alloc::vec::Vec<i32>) v = vec![1, 2, 3]
	// lldb-command:print zs
	// lldbg-check:[...]$1 = StructWithZeroSizedField { x: ZeroSizedStruct, y: 123, z: ZeroSizedStruct, w: 456 }
	// lldbr-check:(issue_22656::StructWithZeroSizedField) zs = StructWithZeroSizedField { x: ZeroSizedStruct { }, y: 123, z: ZeroSizedStruct { }, w: 456 }
	// lldbr-command:continue
	#![allow(unused_variables)]
	#![allow(dead_code)]
	#![feature(omit_gdb_pretty_printer_section)]
	#![omit_gdb_pretty_printer_section]
	struct ZeroSizedStruct;
	struct StructWithZeroSizedField {
	x: ZeroSizedStruct,
	y: u32,
	z: ZeroSizedStruct,
	w: u64
	}
	fn main() {
	let v = vec![1,2,3];
	let zs = StructWithZeroSizedField {
	x: ZeroSizedStruct,
	y: 123,
	z: ZeroSizedStruct,
	w: 456
	};
	zzz(); // #break
	}
	fn zzz() { () }

[michaelwoerister]

(is it synthesizing C++ struct/union definitions from DWARF?)

AFAIK, yes. @philipc might be able to confirm this.

[pnkfelix]

Visiting for wg-debugging triage...

Just a heads up for people reading this in the future: We infer that you will only be able to observe this issue as written if you are using an assertions-enabled build of lldb

[pnkfelix]

There is also a broader question of whether we can actually hope to become (and remain) lldb assertion-clean, given that lldb is interpreting DWARF that we emit based on a somewhat loose specification, which may have mismatches.

At the very least, trying to become and remain lldb assert clean may be a fool's errand until we have some CI testing of an assertion-enabled lldb.

[pnkfelix]

(you can see triage discussion here)

@rustbot label: +P-medium

[pnkfelix]

@wesleywiser convinced me to go with P-low instead, from this:

Counter-point: without evidence this actually impacts anyone other than rustc devs, it seems hard to justify more than P-low to me

(I'm taking the fact the test has been running successfully in CI for the last 3 years as evidence this is not a real problem for assertion-less builds)

@rustbot label: +P-low -P-medium