Resolve typedefs in HashMap gdb/lldb pretty-printers
`GetTypedefedType` (LLDB) and `strip_typedefs` (GDB) calls are needed to resolve key and value types completely.
Without these calls, debugger doesn't show the actual type.
**Before** (without `GetTypedefedType`):
```
(lldb) frame variable hm[0]
(T) hm[0] = { ... }
```
**After** (with `GetTypedefedType`):
```
(lldb) frame variable hm[0]
((i32, alloc::string::String)) hm[0] = { ... }
```
Based on https://github.com/intellij-rust/intellij-rust/pull/6258
`GetTypedefedType` (LLDB) and `strip_typedefs` (GDB) calls are needed to resolve key and value types completely.
Without these calls, debugger doesn't show the actual type.
* Before (without `GetTypedefedType`):
(lldb) frame variable hm[0]
(T) hm[0] = { ... }
* After (with `GetTypedefedType`):
(lldb) frame variable hm[0]
((i32, alloc::string::String)) hm[0] = { ... }
BTreeMap: fix gdb provider on BTreeMap with ZST keys or values
Avoid error when gdb is asked to inspect a BTreeMap or BTreeSet with a zero-sized type as key or value. And clean up.
r? @Mark-Simulacrum
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>*`
debuginfo: Mangle tuples to be natvis friendly, typedef basic types
These changes are meant to unblock rust-lang/rust#70052 "Update hashbrown to 0.8.0" by allowing the use of `tuple<u64, u64>` as a .natvis expression in MSVC style debuggers (MSVC, WinDbg, CDB, etc.)
* f8eb81b does the actual mangling of `(u64, u64)` -> `tuple<u64, 64>`
* 24a728a allows `u64` to resolve (fixing `$T1` / `$T2` when used to visualize `HashMap<u64, u64, ...>`)
Fallback to xml.etree.ElementTree
The xml.etree.cElementTree has been deprecated since Python 3.3
and removed in Python 3.9 https://bugs.python.org/issue36543.
Remove legacy InnoSetup GUI installer
On Windows the InnoSetup `.exe` installer was superseded by the MSI installer long ago. It's no longer needed.
The `.exe` installer hasn't been linked from the [other installation methods](https://forge.rust-lang.org/infra/other-installation-methods.html#standalone) page in many years. As far as I can tell the intent was always to remove this installer once the MSI proved itself. Though admittedly both installers feel very "legacy" at this point.
Removing this would mean we only maintain one Windows GUI installer and would speed up the distribution phase.
As a result of removing InnoSetup, this closes#24397
Replace old GDB and LLDB pretty-printers with new ones
which were originally written for IntelliJ Rust.
New LLDB pretty-printers support synthetic children.
New GDB/LLDB pretty-printers support all Rust types
supported by old pretty-printers, and also support:
Rc, Arc, Cell, Ref, RefCell, RefMut, HashMap, HashSet.
Test and fix gdb pretty printing more
Over time I had oversimplified the test case for #68098: it does not have an internal node to print so it did not test what it pretended to test. And then I also realized not spotting the same mistake reviewing #70111, and more likely to occur in the wild. Now, both test cases fail if you put back the flawed python code.
r? @Mark-Simulacrum
