-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Deduplicate pretty printing of constants #67133
Conversation
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
@@ -1425,6 +1492,19 @@ impl<F: fmt::Write> PrettyPrinter<'tcx> for FmtPrinter<'_, 'tcx, F> { | |||
ty::ReClosureBound(_) => true, | |||
} | |||
} | |||
|
|||
fn pretty_print_const_pointer( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So is this used both for MIR dumps and something user-visible? Or why do we only sometimes print the AllocId?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, the pretty printer is used for both MIR dumps and error messages, and the "show alloc id" flag is only set by MIR dumps
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But there's also something it is not used for and that goes through the other pretty_print_const_pointer
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, the SymbolPrinter
and the AbsolutePathPrinter
. The latter is used for type_name
, which we probably don't want to make users see the alloc ids.
SymbolPrinter
... May actually need the ids. cc @eddyb
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SymbolPrinter
... May actually need the ids. cc @eddyb
Which one? legacy
symbols don't matter much, the hash contains all of the information, they should just be consistent across crates. You don't have to show the const's value if you can't do it consistently cross-crate.
v0
ones are trickier, and I feel like the push for #[structural_match]
in const
generics is going to force us to implement some sort of general ADT representation for constants in v0
symbols, sooner than later.
(it'd likely be similar to how all values of #[structural_match]
types can technically be turned into some sort of pattern)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For reference, the dedicated issue for the last comment is #61486.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I could set it to print just integer types for now and bug!
out for other types so we don't silently introduce bugs
src/librustc/ty/print/pretty.rs
Outdated
(Scalar::Raw { data: 0, .. }, ty::RawPtr(_)) => p!(write("{{null pointer}}")), | ||
// This is UB, but we still print it | ||
(Scalar::Raw { data: 0, ..}, ty::Ref(_, ty, _)) | ||
=> p!(write("{{null reference to "), print(ty), write("}}")), | ||
(Scalar::Raw { data, .. }, ty::Ref(..)) | | ||
(Scalar::Raw { data, .. }, ty::RawPtr(_)) => { | ||
let pointer_width = self.tcx().data_layout.pointer_size.bytes(); | ||
p!(write("0x{:01$x}", data, pointer_width as usize * 2)) | ||
}, | ||
(Scalar::Ptr(p), ty::Ref(..)) | | ||
(Scalar::Ptr(p), ty::RawPtr(_)) => self = self.pretty_print_const_pointer(p)?, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So here we (mostly) do not print types. I am fine with that, I think, but it seems somewhat inconsistent as we are otherwise so careful to have type information (e.g. with the integer types).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is inconsistent, it just seemed very noisy considering that there are no size differences that can be relevant like with the integer types.
This comment has been minimized.
This comment has been minimized.
aeeac8d
to
0e08b7f
Compare
This comment has been minimized.
This comment has been minimized.
0e08b7f
to
14f4f81
Compare
This comment has been minimized.
This comment has been minimized.
14f4f81
to
69f6301
Compare
44eec64
to
db9ddf1
Compare
I can't easily check old comments, but I think #67133 (comment) and #67133 (comment) are the only remaining ones, and after that you can r=me. |
@bors r=eddyb |
📌 Commit 6ca65bd has been approved by |
🌲 The tree is currently closed for pull requests below priority 1000, this pull request will be tested once the tree is reopened |
Add support for LLVM globals corresponding to miri allocations should be named alloc123 Adds support for this request from @eddyb in #69134: > That is, if -Zfewer-names is false (usually only because of --emit=llvm-ir), we should use the same name for LLVM globals we generate out of miri allocs as #67133 does in MIR output (allocN). > >This way, we can easily see the mapping between MIR and LLVM IR (and it shouldn't be any costlier for regular compilation, which would continue to use unnamed globals). r? @eddyb cc @oli-obk
☀️ Test successful - checks-azure |
Tested on commit rust-lang/rust@dd67187. Direct link to PR: <rust-lang/rust#67133> 💔 miri on windows: test-pass → test-fail (cc @oli-obk @eddyb @RalfJung). 💔 miri on linux: test-pass → test-fail (cc @oli-obk @eddyb @RalfJung).
r? @eddyb for the pretty printing logic
cc @RalfJung