Closed
Description
These two lines in src\etc\natvis\libstd.natvis
confuse both cdb
and GUI debugger available inside VS:
<Item Name="{static_cast<tuple<$T1, $T2>*>(base.table.ctrl.pointer)[-(i + 1)].__0}">static_cast<tuple<$T1, $T2>*>(base.table.ctrl.pointer)[-(i + 1)].__1</Item>
<Item>static_cast<$T1*>(map.base.table.ctrl.pointer)[-(i + 1)]</Item>
cdb
gives this error
Unable to find type 'tuple<u64,u64> *' for cast.
GUI debugger just skips the visualization and only shows raw representation.
It is possible to fix visualization inside VS GUI debugger by replacing static_cast
with C-style casts
<Item Name="{((tuple<$T1, $T2>*)base.table.ctrl.pointer)[-(i + 1)].__0}">((tuple<$T1, $T2>*)base.table.ctrl.pointer)[-(i + 1)].__1</Item>
<Item>(($T1*)map.base.table.ctrl.pointer)[-(i + 1)]</Item>
, but I haven't found a way to make cdb
eat this yet.
Tests for other debuggers can use requirement directives like
// min-gdb-version: 8.2
If cdb
from VS2017 toolchain is unable to perform computations required for visualizing hash set/map, then we need to introduce such requirements for cdb
as well.
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
MaulingMonkey commentedon Sep 5, 2020
I've seen similar errors if debug information for
(u64, u64)
/tuple<u64,u64>
was never emitted. Something's up, but I'm not entirely convinced it's an MSVC version issue. That said, please feel free to share your own version numbers! Investigating this myself, it's possible I'm running into a second, different error? Here's what I'm seeing for the visualizers working:ms-vscode.cpptools 0.29.0
It's worth noting that 1.46.0 already integrated my
tuple<...>
changes, so it looks like there's been a regression since then:Test Code
Versions
Debugging
.vscode/launch.json
.vscode/tasks.json
nightly + cdb logs
MaulingMonkey commentedon Sep 5, 2020
Okay, so, I believe there's two separate issues here:
static_cast was never legal, but worked when compiled with 1.46.0 - inside a natvis - for... reasons?
Your C-casts fix this for both VSC and VS, as would reinterpret_cast. They also work in my version of CDB. Feel free to submit a PR with those natvis changes - or I can do so if it's inconvenient for you (I already have a fork/checkouts).
static_cast
ingmap.base.table.ctrl.pointer
fromu8*
totuple<...>*
isn't legal - the types are unrelated. In retrospect, this should've never worked, and yet for some reason it does when:I'm slowly going mad trying to understand why this ever worked, or what changed.
hmap.base.table.ctrl
is acore::ptr::non_null::NonNull<u8>
, andhmap.base.table.ctrl.pointer
is aunsigned char*
as far as Visual Studio is concerned. This applies to both 1.46.0 and 1.47.0-nightly. I'm seeing no differences. I vaguely suspect some incredibly obscure edge case - perhaps some backwards compatability path that was accidentally being used then, which isn't being used now for some unknown reason...? Ultimately I suppose the exact reason doesn't matter...whatever cdb version you're using may not be able to handle C++ at all
CDB not liking it even with C-casts would make sense if CDB can't handle C++ types at all - types or casts (in which case it'd be pointless to wait to try and fix those casts for CDB too, as they'll never work for tuples with that version of CDB.) I'd love to know your cdb version/path/source to see if I can replicate this / test introducing a min-cdb-version. I believe I sourced mine from the Windows 10 SDK.
EDIT: Although, then how the heck does it get as far as trying to resolve tuple specifically? Hmm...
petrochenkov commentedon Sep 5, 2020
@MaulingMonkey
Here's the log
build\x86_64-pc-windows-msvc\test\debuginfo\pretty-std-collections-hash.cdb\pretty-std-collections-hash.out
that contains all the versions and paths used when running the test (with C-style cast applied) and the debugger output as well.Expand
MaulingMonkey commentedon Sep 5, 2020
Okay, things have clicked into place - the way I was overriding the stdlib natvis files worked in VS/VSC but not in CDB like I thought they were. And while 1.46.0 had my tuple changes (which worked), it did not have the natvis/hashbrown changes using 'em. VS/VSC have never liked static_cast when reinterpret_cast is required, and CDB before 10.0.18362.1 doesn't like the tuple casts at all (but at/after that version, CDB doesn't care what kind of cast is used at all.)
Rust changes to make:
// min-cdb-version: 10.0.18362.1
+ support to make older CDB happyAnd the testing I did:
Unable to find type 'tuple<u64,u64> *' for cast.
Unable to find type 'tuple<u64,u64> *' for cast.
Unable to find type 'tuple<u64,u64> *' for cast.
Unable to find type 'tuple<u64,u64> *' for cast.
Unable to find type 'tuple<u64,u64> *' for cast.
Expected ')' at '+ 1)].__1'
petrochenkov commentedon Sep 5, 2020
@MaulingMonkey
Thank you for investigating all this!
MaulingMonkey commentedon Sep 5, 2020
And thank you, @petrochenkov, for bringing this breakage to my attention - so it can get fixed before it lands in stable!
PRs should address everything (famous last words 🤞)
Rollup merge of rust-lang#76390 - MaulingMonkey:pr-min-cdb-version, r…
Auto merge of rust-lang#76390 - MaulingMonkey:pr-min-cdb-version, r=p…
Rollup merge of rust-lang#76389 - MaulingMonkey:pr-natvis-hashmap-vsc…
Rollup merge of rust-lang#76389 - MaulingMonkey:pr-natvis-hashmap-vsc…
petrochenkov commentedon Sep 29, 2020
This was fixed in #76389 and #76390.