-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Implement Display for rustc_target::callconv::Conv
#135808
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: master
Are you sure you want to change the base?
Conversation
Some changes occurred to the CTFE machinery cc @rust-lang/wg-const-eval The Miri subtree was changed cc @rust-lang/miri Some changes occurred to the CTFE / Miri interpreter cc @rust-lang/miri |
It's miri related, and Ralf looks busy, so r? @oli-obk |
@bors r+ rollup has no test changes as for almost all cases the |
src/tools/miri/src/helpers.rs
Outdated
@@ -920,8 +920,7 @@ pub trait EvalContextExt<'tcx>: crate::MiriInterpCxExt<'tcx> { | |||
fn check_abi<'a>(&self, fn_abi: &FnAbi<'tcx, Ty<'tcx>>, exp_abi: Conv) -> InterpResult<'a, ()> { | |||
if fn_abi.conv != exp_abi { | |||
throw_ub_format!( | |||
"calling a function with ABI {:?} using caller ABI {:?}", | |||
exp_abi, | |||
"calling a function with ABI {exp_abi} using caller ABI {}", |
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.
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.
This isn't about ExternAbi
though, it is about the underlying calling convention.
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 hope it'd help by providing more context. Initially we indeed used ExternAbi
here for check_abi
, but after #133103 we passed FnAbi
instead of ExternAbi
, so we can check the number of fixed args like what is done in rust-lang/miri#4122.
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.
Also, this is how we allow e.g. calling a C
function through a C-unwind
fn 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.
This isn't about ExternAbi though, it is about the underlying calling convention.
The underlying calling convention is still mappable to one of the ExternAbi strings, and we can still express conflicts in terms of that. Dropping data randomly, like erasing "rust-cold" to "Cold", or "x86-interrupt" to "X86Intr", will mostly be confusing.
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.
Please implement Display by mapping Conv back to the matching ExternAbi variant (without unwind
). This will sometimes give a surprising result, but it will still be comprehensible. If this is properly tested, then I can elaborate on the error message in a followup that gives the rest of the information necessary to fix the problem.
Of course, if even this is considered impossible by my peers, then I can relent for now and simply make possible the impossible later.
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.
According to conv_from_spec_abi, the reverse mapping of Conv::Rust
can potentially be ExternAbi::RustIntrinsic / RustCall / Rust
. Similarly, Conv::C
can be mapped to ExternAbi::C / Unadjusted / Cdecl
.
Also, in adjust_abi, ExternAbi::StdCall / Thiscall / Fastcall / VectorCall
can occasionally get mapped to ExternAbi::C
. That means the reverse mapping of Conv::C
to ExternAbi
can possibly be any of them.
If I ignore all of the issues above, the simplest reverse mapping that I can think of is:
- Conv::Rust => ExternAbi::Rust
- Conv::PreserveMost => ExternAbi::RustCold
- Conv::X86Stdcall => ExternAbi::Stdcall
- Conv::X86Fastcall => ExternAbi::Fastcall
- Conv::X86VectorCall => ExternAbi::Vectorcall
- Conv::X86ThisCall => ExternAbi::Thiscall
- Conv::C => ExternAbi::C
- Conv::X86_64Win64 => ExternAbi::Win64
- Conv::X86_64SysV => ExternAbi::SysV64
- Conv::ArmAapcs => ExternAbi::Aapcs
- Conv::CCmseNonSecureCall => ExternAbi::CCmseNonSecureCall
- Conv::CCmseNonSecureEntry => ExternAbi::CCmseNonSecureEntry
- Conv::PtxKernel => ExternAbi::PtxKernel
- Conv::Msp430Intr => ExternAbi::Msp430Interrupt
- Conv::X86Intr => ExternAbi::X86Interrupt
- Conv::GpuKernel => ExternAbi::GpuKernel
- Conv::AvrInterrupt => ExternAbi::AvrInterrupt
- Conv::AvrNonBlockingInterrupt => ExternAbi::AvrNonBlockingInterrupt
- Conv::RiscvInterrupt { kind: RiscvInterruptKind::Machine } => ExternAbi::RiscvInterruptM
- Conv::RiscvInterrupt { kind: RiscvInterruptKind::Supervisor } => ExternAbi::RiscvInterruptS
- Conv::Cold and Conv::PreserveAll: Not sure how to deal with them, can we ignore them?
But I am not sure if this is still correct, so cc @workingjubilee for a vibe check :)
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. Please ignore Conv::Cold
and Conv::PreserveAll
, they are actually dead code. I am working through a refactor of some parts of the compiler that involve what is currently called Conv
and discovered they are dead on the way.
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.
Once I am done they will also make it possible to always recover the list of valid ExternAbi
names from the actually-used ABI.
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.
Nice! Since there is an ongoing refactor involving Conv
, would it be more convenient if I put this on hold and wait for that to finish? I don't mind working on this sooner or later.
EDIT: I went ahead and made the change anyway :)
@bors r- |
This comment has been minimized.
This comment has been minimized.
@tiif Thanks for your contribution. Are you able to address the code review? |
Yup, I have been planning to do this, but unfortunately I still have quite a bit of stuff on my queue, I'd convert this to draft for now. |
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 already have relevant test in miri, so I removed similar test in previous commit.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
473998c
to
e74fe7a
Compare
@rustbot ready |
Follow up of #133103 (comment)