STL.natvis: Simplify visualization for string by pps83 · Pull Request #5177 · microsoft/STL (original) (raw)

Thanks! 😻 I pushed a comment update and two simplifications for wildcards.

⚠️ I'm having trouble getting the VS IDE to pick up the updated natvis (I couldn't get it to display an added "taxicab" node), so I was unable to verify these changes, and I'm totally YOLOing them. Please double-check @CaseyCarter and @pps83 - I apologize if I messed up the PR.

For future reference, after code review begins, please avoid force-pushing changes as that makes it harder to incrementally review what changed.

Update: On Discord, Casey figured out why adding stl.natvis to my project didn't appear to be taking effect:

It looks like the debugger is preferring e.g. the more-specific std::basic_string<char,*> from the installed STL.natvis to our std::basic_string<*>. (Changing "Tools > Options > Debugging > Output Window > Natvis diagnostic messages" to "Verbose" is handy for debugging visualizer weirdness.) I do see other visualizers from the repo activating (Natvis: C:\STL\stl\debugger\STL.natvis(1041,6): Successfully parsed expression '_Mydata' in type context 'std::basic_string_view<char,std::char_traits<char> >'.) so it appears that https://learn.microsoft.com/en-us/visualstudio/debugger/create-custom-views-of-native-objects?view=vs-2022#BKMK_natvis_location is telling the truth about the search order for visualizers within natvis files.
It looks like we'll need to rename the installed STL.natvis with some other extension so it won't be loaded and we can cleanly test the incoming STL.natvis.

I didn't realize that all loaded visualizers were effectively being thrown into a giant pile, and the preference order for file fallbacks was being applied after "what visualizer is more specialized". I thought the file fallbacks were coarse-grained, but the actual behavior makes more sense, even if it's annoying for this development scenario.

This meant that we weren't actually testing anything, both before and after my changes (std::basic_string<*,*> was still less specific than the original std::basic_string<char,*>). Casey re-validated everything with no fallback so we're good now.