[debugger visualizers] Add workaround to read Rc strong/weak counts

[Walnut356]

Implements a fix with the same goal as #162725 of removing the infinite loop. Since RcInner is #[repr(C)], we can just directly read the values from their known offsets. Worth noting that LLDB fails to even populate the fields and offsets when this bug occurs, so #[repr(C)] is a required invariant to retrieve the values from addresses like this:

(lldb) script lldb.frame.var("holder").GetNonSyntheticValue().GetChildAtIndex(0).GetChildAtIndex(0).GetChildAtIndex(0).GetType().GetPointeeType()

template<> struct RcInner<unsigned int> {
private:
    unsigned int value;
}

That RcInner should have a strong and weak field, but because LLDB can't read the type node, it omits them entirely. Thankfully, the value field is still read correctly and has an accurate offset.

This change has 1 small side effect, which is that the weak count is not decremented before it is displayed to the user. We can easily do that in the summary function, but imo it feels weird to lie about the value in memory? The weak count starts at 1 because the original Rc instance "holds" both a strong and a weak reference. It's mostly an artifact of Rc's implementation, but if you're debugging, that seems like something that might matter.

[rustbot]

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: @Mark-Simulacrum

[Mark-Simulacrum]

@bors r+

I agree that visualizing with a changed count makes little sense -- if we want that we should at least use a different field name. But I'm comfortable with this.

[rust-bors]

📌 Commit b799651 has been approved by Mark-Simulacrum

It is now in the queue for this repository.