Better print ScalarPair when it is tuple or slice #144686
Conversation
|
|
rustbot
added
S-waiting-on-review
There was a problem hiding this comment.
Thanks for the PR! However, I am not sure this is a good idea -- we don't want to have a ton of pretty-printing code in the interpreter that's rarely ever used. Why do you even care about the internal debug output of ImmTy?
If anything, we should instead try to make better use of the existing pretty-printing code for MIR constants. But I don't know if we have any logic for ScalarPair there...
Also, ScalarPair is a very complicated representation, as demonstrated by your code not always treating it correctly.
Signed-off-by: xizheyin <[email protected]>
xizheyin
force-pushed
the
const-eval-print
branch
from
eb7b9cf to
2b5ce93
Compare
|
Thanks for the reply, I came across this FIXME while reading the code and wondered if I could fix it along the way. Since the tuple is so complex, I removed the code against the tuple. Of course, I will close this PR if it is not so necessary. ：） |
|
Oh, that FIXME was probably more of an off-the-cuff remark, and it is many years old.^^ It is always better to ask before just working on a random FIXME in the code. :) |
|
Yes, I noticed that it was submitted five years ago. I asked oli on zulip before submitting, thus I made this pr. 😊 |
| p(cx, b, tcx.types.usize) | ||
| })?; | ||
|
|
||
| write!(f, "&[{}; {}]: {}", ptr_str, len_str, ty)?; |
There was a problem hiding this comment.
Do you have an example of what this looks like in the end?
It seems like it'll print something like &[ptr; 128] which is confusing because it looks like a slice repeating the pointer 128 times, when actually it is a slice of that length starting at ptr.
I found (seemingly) no existing tests with it, so I comment it for internal debugging as you requested.
r? @oli-obk