debugger watch / tooltips are overly verbose / not tuned for Rust in general

[parthopdas]

need to author a nativis file https://learn.microsoft.com/en-us/visualstudio/debugger/create-custom-views-of-native-objects?view=vs-2022 the first draft should be pretty easy.

[tim-weis]

Forgive my ignorance here. I was under the impression that RFC 3191: debugger_visualizer has landed, with natvis visualizers deployed for (at least some of) the Standard Library types.

Running the following

src/main.rs

fn main() {
    let v = vec![42; 3];
    println!("{:#?}", &v);
}

Cargo.toml

[package]
name = "natvis-test"
version = "0.0.0"
edition = "2021"

gets me to this in Visual Studio's debugger:

Hovering over v, or adding a Watch yields the same output, so everything appears to work as intended.

Could you share a use case where things don't work as expected? I'll gladly have a look, since debugging support is (IMHO) the true killer feature of this Visual Studio Extension.

[parthopdas]

@tim-weis thank you for responding : )

i filed this based on a comment and then my investigations show the same results. however when i sucked in the nativis from rust-lang/rust they did not fix. so i left this issue as a tracking issue

it will be very nice if you can take a look.

[tim-weis]

Thanks for the details, @parthopdas!

I can confirm that Option's aren't displayed in an ideal way (the same is true for Result's).

Either one is an enum, and enums receive their debug visualizer support from intrinsic.natvis, straight out of the Rust compiler[^1]. Things get rather tricky from here:

For one, the visualizers should really be written by the developers that own the library code. They are the ones that control the innards of the types, and can arrange to keep the visualizers in lock-step with the implementation.

And then there's the technical challenge in convincing the debug engine to favor an (external) .natvis file over the PDB-provided visualizer description. In countless iterations over the .natvis' <Type Name="anything I could think of"> I didn't manage to, though I'm not nearly even an amateur in natvis infrastructure. I'll be all ears in case someone knows how to deterministically control the selection of visualizers (or knows where to find a description of the selection algorithm).

From a client's perspective, it would be great if debug visualizers lived up to what we have grown to expect. I'm not positive that this is something this extension can provide. Dropping a few unsolicited pings to folks that have contributed to Rust's natvis support, to validate my assumptions (@wesleywiser @sivadeilra @ridwanabdillahi).

---

Leaving a few notes, just because I know I will forget:

• Custom .natvis files can be placed under %USERPROFILE%\Documents\Visual Studio 2022\Visualizers for testing (see Natvis file locations)
• Make sure to turn on natvis diagnostics by going to Tools > Options > Debugging > Output Window, and setting Natvis diagnostic messages (C++ only) to Error, Warning, or Verbose. This will produce helpful diagnostics during visualizer evaluation. The option reads "C++ only", but it seems to mean "anything native".
• An easy way to verify whether a .natvis visualizer description is hit is to use a static <DisplayString>, e.g.

  <Type Name="...">
    <DisplayString>moose</DisplayString>
  </Type>

[^1]: The idea here is that debug visualizers are the responsibility of the implementer of a type.

[parthopdas]

thanks for the detailed investigation @tim-weis and the notes that will be helpful in the future.

i am wondering if you could file a bug in @rust to fix this. i agree with you that the lib developer should own the nativis