about summary refs log tree commit diff
path: root/src/etc/natvis/libstd.natvis
AgeCommit message (Collapse)AuthorLines
2022-04-14Update *.natvis files (CDB?) files to take into account `Unique<T>` changesEduardo Sánchez Muñoz-3/+3
2022-02-03Fix HashMap not displaying correctly in VS debuggerWesley Wiser-1/+1
The natvis to render HashMaps was not working correctly in Visual Studio because the type names for tuples changed from `tuple$<A, B>` to `tuple$<A,B>` (notice the missing space). WinDbg and cdb continued to parse this type name which is why no tests in CI broke. VS however is slightly more strict and this caused the visualizer to break. Since we cannot test the VS debugger in CI, I'm not checking in any test changes.
2021-07-09Respond to review feedbackWesley Wiser-0/+2
2021-07-08Add visualizer for OsString and fixup other string visualizersWesley Wiser-1/+15
2021-06-30Improve debug symbol names to avoid ambiguity and work better with MSVC's ↵Daniel Paoliello-1/+1
debugger There are several cases where names of types and functions in the debug info are either ambiguous, or not helpful, such as including ambiguous placeholders (e.g., `{{impl}}`, `{{closure}}` or `dyn _'`) or dropping qualifications (e.g., for dynamic types). Instead, each debug symbol name should be unique and useful: * Include disambiguators for anonymous `DefPathDataName` (closures and generators), and unify their formatting when used as a path-qualifier vs item being qualified. * Qualify the principal trait for dynamic types. * If there is no principal trait for a dynamic type, emit all other traits instead. * Respect the `qualified` argument when emitting ref and pointer types. * For implementations, emit the disambiguator. * Print const generics when emitting generic parameters or arguments. Additionally, when targeting MSVC, its debugger treats many command arguments as C++ expressions, even when the argument is defined to be a symbol name. As such names in the debug info need to be more C++-like to be parsed correctly: * Avoid characters with special meaning (`#`, `[`, `"`, `+`). * Never start a name with `<` or `{` as this is treated as an operator. * `>>` is always treated as a right-shift, even when parsing generic arguments (so add a space to avoid this). * Emit function declarations using C/C++ style syntax (e.g., leading return type). * Emit arrays as a synthetic `array$<type, size>` type. * Include a `$` in all synthetic types as this is a legal character for C++, but not Rust (thus we avoid collisions with user types).
2021-03-17Update HashSet natvisMarkus Westerlind-7/+7
2021-03-16feat: Update hashbrown to instantiate less llvm IRMarkus Westerlind-7/+7
Includes https://github.com/rust-lang/hashbrown/pull/204 and https://github.com/rust-lang/hashbrown/pull/205 (not yet merged) which both server to reduce the amount of IR generated for hashmaps. Inspired by the llvm-lines data gathered in https://github.com/rust-lang/rust/pull/76680
2021-03-01Add natvis for Result, NonNull, CString, CStr, and CowRyan Levick-0/+29
2020-12-28Improvements to NatVis supportArlie Davis-4/+4
NatVis files describe how to display types in some Windows debuggers, such as Visual Studio, WinDbg, and VS Code. This commit makes several improvements: * Adds visualizers for Rc<T>, Weak<T>, and Arc<T>. * Changes [size] to [len], for consistency with the Rust API. Visualizers often use [size] to mirror the size() method on C++ STL collections. * Several visualizers used the PVOID and ULONG typedefs. These are part of the Windows API; they are not guaranteed to always be defined in a pure Rust DLL/EXE. I converted PVOID to `void*` and `ULONG` to `unsigned long`. * Cosmetic change: Removed {} braces around the visualized display for `Option` types. They now display simply as `Some(value)` or `None`, which reflects what is written in source code. * The visualizer for `alloc::string::String` makes assumptions about the layout of `String` (it casts `String*` to another type), rather than using symbolic expressions. This commit changes the visualizer so that it simply uses symbolic expressions to access the string data and string length.
2020-09-08Implement HashSet in terms of hashbrown::HashSetMatt Brubeck-9/+9
2020-09-05Fix HashMap visualizers in Visual Studio (Code)MaulingMonkey-2/+2
CDB doesn't care that you're using static_cast between unrelated types. VS(C) does. These should've been reinterpret_cast or C casts. Cast is from e.g. `u8*` to `tuple<$T1, $T2>*`
2020-08-07Handle new HashMap layout in CDB, MSVC, WinDbg, etc.MaulingMonkey-31/+4
2019-11-20debuginfo: Support for std::collections::Hash* in windows debuggers.MaulingMonkey-0/+102