53 LLDB tests from `tests/debuginfo` fail on `windows-msvc`

[Walnut356]

I plan on cleaning these up whenever I get the chance. This is a blocker for enabling LLDB debuginfo tests in CI.

The test failures are:

• tests\debuginfo\associated-types.rs
• tests\debuginfo\basic-types-globals.rs#lto
• tests\debuginfo\basic-types-globals.rs#no-lto
• tests\debuginfo\borrowed-basic.rs
• tests\debuginfo\borrowed-tuple.rs
• tests\debuginfo\borrowed-unique-basic.rs
• tests\debuginfo\box.rs
• tests\debuginfo\boxed-struct.rs
• tests\debuginfo\by-value-self-argument-in-trait-impl.rs
• tests\debuginfo\c-style-enum-in-composite.rs
• tests\debuginfo\captured-fields-1.rs
• tests\debuginfo\captured-fields-2.rs
• tests\debuginfo\coroutine-locals.rs
• tests\debuginfo\cross-crate-spans.rs
• tests\debuginfo\destructured-fn-argument.rs
• tests\debuginfo\destructured-for-loop-variable.rs
• tests\debuginfo\destructured-local.rs
• tests\debuginfo\dummy_span.rs
• tests\debuginfo\evec-in-struct.rs
• tests\debuginfo\generic-struct.rs
• tests\debuginfo\issue-22656.rs
• tests\debuginfo\lexical-scope-in-for-loop.rs
• tests\debuginfo\lexical-scope-in-if-let.rs
• tests\debuginfo\lexical-scope-in-if.rs
• tests\debuginfo\lexical-scope-in-stack-closure.rs
• tests\debuginfo\lexical-scope-in-unconditional-loop.rs
• tests\debuginfo\lexical-scope-in-unique-closure.rs
• tests\debuginfo\lexical-scope-in-while.rs
• tests\debuginfo\lexical-scope-with-macro.rs
• tests\debuginfo\lexical-scopes-in-block-expression.rs
• tests\debuginfo\method-on-generic-struct.rs
• tests\debuginfo\name-shadowing-and-scope-nesting.rs
• tests\debuginfo\no_mangle-info.rs
• tests\debuginfo\packed-struct-with-destructor.rs
• tests\debuginfo\packed-struct.rs
• tests\debuginfo\pretty-slices.rs
• tests\debuginfo\pretty-std-collections.rs
• tests\debuginfo\reference-debuginfo.rs
• tests\debuginfo\shadowed-argument.rs
• tests\debuginfo\shadowed-variable.rs
• tests\debuginfo\simple-lexical-scope.rs
• tests\debuginfo\simple-struct.rs
• tests\debuginfo\simple-tuple.rs
• tests\debuginfo\strings-and-strs.rs
• tests\debuginfo\struct-in-struct.rs
• tests\debuginfo\struct-with-destructor.rs
• tests\debuginfo\thread-names.rs#win
• tests\debuginfo\tuple-in-tuple.rs
• tests\debuginfo\tuple-struct.rs
• tests\debuginfo\var-captured-in-nested-closure.rs
• tests\debuginfo\var-captured-in-sendable-closure.rs
• tests\debuginfo\var-captured-in-stack-closure.rs
• tests\debuginfo\vec-slices.rs

[Walnut356]

And here are the causes behind the failures (more or less)

UDT fields reordered (UDT defined in file, can work around with repr(c), but also resolves itself with lldb-repr). Additional digging shows that this is technically an LLDB problem. Their DWARF parser preserves the source/debuginfo ordering of fields, their PDB parser reorders them to offset-order:

• associated-types.rs
• boxed-struct.rs
• destructured-for-loop-variable.rs
• evec-in-struct.rs
• packed-struct.rs
• packed-struct-with-destructor.rs
• simple-struct.rs <--- this test lies (Structs aren't repr(c), so e.g. InternalPadding doesn't necessarily have internal padding, might end up identical to PaddingAtEnd)
• struct-with-destructor.rs
• struct-in-struct.rs

Tuples (summary provider needs lldb.eTypeOptionHideChildren):

• associated-types.rs
• box.rs
• borrowed-tuple.rs
• c-style-enum-in-composite.rs
• destructured-fn-argument.rs
• cross-crate-spans.rs
• destructured-for-loop-variable.rs
• destructured-local.rs
• simple-tuple.rs
• tuple-in-tuple.rs
• strings-and-strs.rs

Globals (need to investigate whether this is an LLDB or PDB issue):

• basic-types-globals.rs#no-lto
• basic-types-globals.rs#lto
• no_mangle-info.rs

i8/u8 formats to char instead of decimal:

• borrowed-unique-basic.rs
• destructured-for-loop-variable.rs

Type names included in output, different type name on different targets (fixes itself with lldb-repr):

• captured-fields-1.rs
• generic-struct.rs
• method-on-generic-struct.rs
• strings-and-strs.rs

<no location, value may have been optimized out> (possibly LLDB issue, possibly related to #151075):

• by-value-self-argument-in-trait-impl.rs
• captured-fields-2.rs
• coroutine-locals.rs
• lexical-scope-in-if-let.rs
• var-captured-in-nested-closure.rs
• var-captured-in-sendable-closure.rs
• var-captured-in-stack-closure.rs

Weird/wrong location information in general/Shadowing issues:

• dummy_span.rs
• lexical-scope-in-stack-closure.rs
• lexical-scope-in-unconditional-loop.rs
• lexical-scope-in-if.rs
• lexical-scope-with-macro.rs (error: Couldn't materialize: couldn't get the value of variable b: variable not available error: errored out in virtual lldb_private::LLVMUserExpression::DoExecute, couldn't PrepareToExecuteJITExpression)
• lexical-scope-in-unique-closure.rs
• lexical-scope-in-for-loop.rs
• lexical-scope-in-while.rs
• lexical-scopes-in-block-expression.rs
• name-shadowing-and-scope-nesting.rs
• shadowed-variable.rs
• shadowed-argument.rs
• simple-lexical-scope.rs

LLDB ignoring ZSTs? (I think this is built in to their PDB parsing but i need to double check. This isn't a huge issue since nothing is failing on LLDB's end, it's just an annoying target-specific difference, so it resolves itself with lldb-repr):

• issue-22656.rs

Gnu providers differ from MSVC (solves itself with lldb-repr, but we should try to unify as much as possible):

• pretty-slices.rs
• pretty-std-collections.rs
• vec-slices.rs (Also small broken visualizer for empty)

Broken visualizer:

• strings-and-strs.rs - Rc<str>, reads RcInner<str> wide ptr as cstring and reads oob memory until it hits a null byte. Fixed whenever I get around to writing the generic wideptr visualizer

Oh no:

• tuple-struct.rs - {0:-10008, 1:10009, 2:10010, 3:10011} reordered to {0:10011, 1:10010, 2:-10008, 3:10009} but notice how the field names are wrong relative to the source code definition of the struct 🫠

Other:

• thread-names.rs#win - might need to use a script command to poll for any thread with the proper name, since i don't think thread 2 is guaranteed to be the one we spawned