[Debuginfo] Add MSVC Synthetic and Summary providers to LLDB

[Walnut356]

Adds handling for tuple$<>, ref$<slice$2<>, ref$<str$> and enum2$<>.

Also fixes a bug in MSVC vec/string handling where the script was unable to determine the element's type due to LLDB ignoring template arg debug information

Sample code

pub enum Number {
    One = 57,
    Two = 99,
}

#[repr(u8)]
pub enum Container {
    First(u32),
    Second { val: u64, val2: i8 },
    Third,
}

...
    let u8_val = b'a';
    let float = 42.78000000000001;

    let tuple = (u8_val, float);

    let str_val = "eef";
    let mut string = "freef".to_owned();
    let mut_str = string.as_mut_str();
    let array: [u8; 4] = [1, 2, 3, 4];
    let ref_array = array.as_slice();
    let mut array2: [u32; 4] = [1, 2, 3, 4];
    let mut_array = array2.as_mut_slice();
    let enum_val = Number::One;
    let mut enum_val2 = Number::Two;
    let sum_val = Container::First(15);
    let sum_val_2 = Container::Second { val: 0, val2: 0 };
    let sum_val_3 = Container::Third;
    let non_zero = NonZeroU128::new(100).unwrap();
    let large_discr = NonZeroU128::new(255);

Before:

After:

[rustbot]

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[Walnut356]

Hmm, I was originally going to separate it out, but I think I can squeeze the HashMap and HashSet fix on here too. The fixes for those are much less involved than I thought they might be.

[Walnut356]

There we go =D

Type-name output isn't perfect, but that's going to require a PR of its own since it's a can of worms.

[jieyouxu]

(cc @wesleywiser: maybe you could take a look if you have the bandwidth and are willing?)

[Mark-Simulacrum]

Could we add a comment on this function (or maybe we have unit tests for this code?) that could check that this is doing what it wants to?

Checking locally, it looks like this is specifically getting the top-level generic (nit: maybe rename the function? Templates aren't really what Rust calls this) arguments.

print(get_template_args("Foo<Bar>")) # = ['Bar']
print(get_template_args("Foo<Bar<A, B>>")) # = ['Bar<A, B>']
print(get_template_args("Foo<Bar<A<A1, A2>, B>>")) # = ['Bar<A<A1, A2>, B>']
print(get_template_args("Foo<Bar<A<A1, A2>, B>, Baz1, Baz2>")) # ['Bar<A<A1, A2>, B>', 'Baz1', 'Baz2']

I think that's probably reasonable for what we need this function for -- it looks like we actually only ever look at the 0th argument -- but it's also at least IMO not intuitive from glancing at the code that this is the result, so seems like a comment would be worthwhile.

[Walnut356]

For sure. The rationale for the name mostly comes down to "that's what LLDB calls it", as it's ~a replacement for SBType.template_args (which always fails on MSVC for whatever reason. IIRC the information does exist in the PDB, LLDB just doesn't care. I'm sure it's fixable on their end, but afaik that's gonna be a lot of effort).

Returning a list will be useful for fixing up the type name output (once i get around to that), since it'll need to recursively format the generic args. Grabbing only the first level should mean I can look up the full type via target.FindFirstType() and call .GetDisplayTypeName() to leverage any existing SyntheticProvider.get_type_name().

[wesleywiser]

This is really nice work! Is it possible we can get some unit tests for the various providers in the PR so we can prevent them from breaking in the future?

[Walnut356]

These should be caught by the existing tests - e.g. the vec test expects lldb to output the elements, whereas without the synthetic it outputs a raw pointer to bytes. CI doesn't catch it right now because it only runs the tests for *-gnu and these fixes only matter for *-msvc

[wesleywiser]

Gotcha! I won't hold up merging this improvement for that then.

Thank you again!

@bors r+

[bors]

📌 Commit 0f12b8c has been approved by wesleywiser

It is now in the queue for this repository.

[matthiaskrgr]

@bors r-
guess this failed here ? #136673 (comment)

[Walnut356]

Ah, looks like on LLDB versions prior to 19.0(?), SBTypeStaticField did not exist. It failed to import lldb_providers due to that, meaning none of the Synthetic Providers were run at all. I'm not sure why the CI tests didn't fail since they use LLVM 18? Weird.

from __future__ import annotations prevents python from trying to resolve type annotations at runtime, which prevents errors when those types haven't been imported (lol). I also did my best to make things not catastrophically explode in the MSVCEnumSyntheticProvider when we can't call GetStaticFieldWithName, but there's no way to get any sort of equivalent output, since there's no way to inspect the static fields at all. CodeLLDB uses 19.1.0 though, so for a lot of people the fix should work fine.

In the future it might be worth using a static enum instead of a static u64 DI node to store the discriminant values, just like we do for the variant names. That way we can look up that enum type itself and use the SBTypeEnumMember api, which has existed at least as far back as LLDB 15, whenever the SBTypeStaticField api isn't available.

[Walnut356]

@rustbot review