[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().

[Mark-Simulacrum]

I'm not sure why this can't use the get_template_args above. Is that because we're not getting a proper type here (e.g., other noise is mixed in)?

[Walnut356]

Whoops, that's a remnant from when it was the only place that needed a template args replacement