Change:
# HashSet wraps either std HashMap or hashbrown::HashSet, which both # wrap hashbrown::HashMap, so either way we "unwrap" twice. hashbrown_hashmap = self.valobj.GetChildAtIndex(0).GetChildAtIndex(0) <del> return hashbrown_hashmap.GetChildMemberWithName("table").GetChildMemberWithName("table") </del> <ins> return hashbrown_hashmap.GetChildMemberWithName("table") </ins> def has_children(self): # type: () -> bool

Discussion:
I tried this code: I expected to see this happen: successful test suite run Instead, this happened: debuginfo test failure for pretty-std-, saying that an expecting output from the debugger was not found. The specific line it seemed be this one: <details<summaryClick to see transcript that includes the full stdout/stderr output as reported by + </summary</details
Incidentally, when I tried to run the test by hand (which admittedly I might have messed up in some way), I saw this: <details<summaryClick to see some details about my attempt to run on a binary.</summary</summary</detailsIt seems pretty suspicious that lldb was reporting for the hashset and hashmap in these cases, when the unit 8test expects both their sizes to be 4. (But that also doesn't actually seem to be the behavior that x.py is observing, so that might be user error, or a separate bug entirely.)
I'm not sure if you've seen , but the lldb tests only run on macOS on CI. It looks like you are maybe using linux, so this is exercising untested code. In particular, pretty-std-collections is disabled on macOS, so it is not tested anywhere. It's not too surprising that it may have bitrotted. I'm also curious, are you using lldb installed on your system? Is it the same version of LLVM that rustc was built with?
Yeah I knew the debugger test suite i only enabled in certain contexts, but I couldn't remember the details. My runs of are using the wrapper from 1.50 stable. Of course that's just a wrapper over what's in my PATH ( in this case), right? lldb version 11.0.0 in this case. I should probably see if things change if I set in my . (In any case, I'd say it remains a suboptimal developer experience to have x.py test fail in this manner.)
was removed from rustbuild a long while back, so this shouldn't have any impact. Agreed, I ran into a similar problem (). As long as the test is disabled in CI, it'll probably keep breaking unfortunately. I'm pretty certain I tested locally, and it worked, so somehow it broke again. Maybe has some insight?
I can bisect, thanks for the link !

I checked the latest changes briefly and it looks like broke LLDB pretty-printing on Rust 1.51. Note that should be used only on the newest versions of . I'll open a PR to fix this soon.
Thanks that was quick! And please don't feel obligated to investigate when I ping. It was just a wild guess if you might know what was up.
No problem, please feel free to mention me in case of any debugger pretty-printers problems! I'm working on the debugging support in IntelliJ Rust and I'm interested in fixing issues like this ASAP.
I investigated the problem with a clear mind and found out that LLDB pretty-printer was updated improperly in (although GDB pretty-printer is OK). Please check the new PR. It would be so great to have LLDB pretty-printers tests on CI. In IntelliJ Rust, we on Linux. We Python package from CLion distribution but I suppose the system package can be linked and used instead (see ).