Repository navigation
Conversation
|
r? @chenyukang rustbot has assigned @chenyukang. Use Why was this reviewer chosen?The reviewer was selected based on:
|
|
@rustbot reroll |
|
(#163098 means i need to modify the tests again before this gets merged) |
8b131a4 to
7f38840
Compare
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
☔ The latest upstream changes (presumably #164216) made this pull request unmergeable. Please resolve the merge conflicts by rebasing. |
See: llvm/llvm-project#196812
TL;DR sidesteps a name collision issue that affects generics, e.g.
S<u64>andS<usize>resolving as the same type.This is accomplished by wrapping an existing primitive node in a
usize/isizetypedef instead.I'd love to output typedefs for all the primitive types too, so LLDB displays the type names rust-style, but I've got a couple worries with that. Firstly, GDB doesn't seem to like it w.r.t. enums? IIRC it's because of a small difference in how GDB treats typedefs compared to LLDB. I'm like 80% sure it's hard-coded in GDB itself, so it's not something I want to touch atm.
Secondly, I'm not entirely sure it's a good idea to have both a type and a typedef with the exact same name in the first place. I could easily imagine that causing some similar issues to the one we're trying to solve.
This also includes a small extention to the
Rctest to ensure we can read bothRc<u64>andRc<usize>. Without this change, the secondvcommand would fail to materialize any value: