-
-
Notifications
You must be signed in to change notification settings - Fork 14.4k
support c-variadic functions in rustc_const_eval
#150601
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
base: main
Are you sure you want to change the base?
Conversation
This comment has been minimized.
This comment has been minimized.
d30044f to
5f98625
Compare
This comment has been minimized.
This comment has been minimized.
5f98625 to
3368321
Compare
This comment has been minimized.
This comment has been minimized.
3368321 to
41a34bc
Compare
This comment has been minimized.
This comment has been minimized.
41a34bc to
8608ba7
Compare
This comment has been minimized.
This comment has been minimized.
8608ba7 to
207b032
Compare
|
☔ The latest upstream changes made this pull request unmergeable. Please resolve the merge conflicts. |
207b032 to
1794556
Compare
This comment has been minimized.
This comment has been minimized.
b297adc to
c081ba3
Compare
This comment has been minimized.
This comment has been minimized.
c081ba3 to
293ba18
Compare
|
This PR changes rustc_public cc @oli-obk, @celinval, @ouz-a, @makai410 Some changes occurred to the CTFE machinery Some changes occurred in compiler/rustc_codegen_cranelift cc @bjorn3 Some changes occurred to the CTFE / Miri interpreter cc @rust-lang/miri Some changes occurred to the CTFE / Miri interpreter cc @rust-lang/miri, @RalfJung, @oli-obk, @lcnr The Miri subtree was changed cc @rust-lang/miri Some changes occurred to the intrinsics. Make sure the CTFE / Miri interpreter cc @rust-lang/miri, @RalfJung, @oli-obk, @lcnr Some changes occurred in compiler/rustc_codegen_gcc |
|
☔ The latest upstream changes (presumably #146923) made this pull request unmergeable. Please resolve the merge conflicts. |
a3a75ad to
19347f2
Compare
|
@rustbot author (I haven't yet had a chance to look at the code in detail, but given the larger structural issues it's probably better tog et those right before I do the detailed review.) |
|
Reminder, once the PR becomes ready for a review, use |
This comment has been minimized.
This comment has been minimized.
19347f2 to
83db12a
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
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 think I know why the provenance is being lost...
On x86, VaListInner is declared as starting with 8 integer bytes. We are storing pointer data there. When copying the VaListInner, that will drop the provenance.
What's less clear to me is where a VaList (and therefore its inner field) is being copied. But given that we expose this type to users I guess it is expected that they are allowed to copy it...
It seems like currently, all VaListInner types have a pointer field that we could use to store the pointer that the interpreter uses to represent the actual state. Not sure if that's a safe thing to bet on though...
| this.dedup_diagnostic(&DEDUP, |first| { | ||
| NonHaltingDiagnostic::Int2Ptr { details: first } | ||
| this.dedup_diagnostic(&DEDUP, |first| NonHaltingDiagnostic::Int2Ptr { | ||
| details: first, |
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.
Some odd reformatting happening here?
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, ./x fmt is happy with it though
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.
./x fmt skips Miri files. Miri has its own rustfmt.toml so if your editor is set up incorrectly then reformatting in the editor might end up using the rustc rustfmt.toml rather than Miri's config and thus result in spurious changes.
| self.deallocate_ptr(ptr, None, MemoryKind::Stack)?; | ||
|
|
||
| interp_ok(()) | ||
| } |
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.
The corresponding allocation code for this is super far away in a different file -- that's not great.
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.
True, though the allocation is just self.allocate. I could extract that into a method?
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.
We're getting somewhere, that deref suggestion was really helpful.
| this.dedup_diagnostic(&DEDUP, |first| { | ||
| NonHaltingDiagnostic::Int2Ptr { details: first } | ||
| this.dedup_diagnostic(&DEDUP, |first| NonHaltingDiagnostic::Int2Ptr { | ||
| details: first, |
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, ./x fmt is happy with it though
| self.deallocate_ptr(ptr, None, MemoryKind::Stack)?; | ||
|
|
||
| interp_ok(()) | ||
| } |
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.
True, though the allocation is just self.allocate. I could extract that into a method?
|
And I'm now looking up a pointer field in the |
tracking issue: #44930
The new
GlobalAlloc::VaListis used to create anAllocIdthat represents the variable argument list of a frame. The allocation itself does not store any data, all we need is the unique identifier.The actual variable argument list is stored in
Memory, and keyed by theAllocId. TheFramealso stores thisAllocId, so that when a frame is popped, it can deallocate the variable arguments.At "runtime" a
VaListvalue stores a pointer to the global allocation in its first bytes. The provenance on this pointer can be used to retrieve itsAllocId, and the offset of the pointer is used to store the index of the next argument to read from the variable argument list.Miri does not yet support
va_arg, but I think that can be done separetely?r? @RalfJung
cc @workingjubilee