Skip to content

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

Open
wants to merge 9 commits into
base: master
Choose a base branch
from

Conversation

tiif
Copy link
Contributor

@tiif tiif commented Jan 21, 2025

Follow up of #133103 (comment)

@rustbot
Copy link
Collaborator

rustbot commented Jan 21, 2025

r? @fmease

rustbot has assigned @fmease.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jan 21, 2025
@rustbot
Copy link
Collaborator

rustbot commented Jan 21, 2025

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

@tiif
Copy link
Contributor Author

tiif commented Jan 21, 2025

It's miri related, and Ralf looks busy, so r? @oli-obk

@rustbot rustbot assigned oli-obk and unassigned fmease Jan 21, 2025
@oli-obk
Copy link
Contributor

oli-obk commented Jan 21, 2025

@bors r+ rollup

has no test changes as for almost all cases the Debug impl has the same output as the Display impl, adding a new test just for risc doesn't really bring much value imo, so shipping as is

@bors
Copy link
Collaborator

bors commented Jan 21, 2025

📌 Commit bbde683 has been approved by oli-obk

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 21, 2025
@@ -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 {}",
Copy link
Member

@workingjubilee workingjubilee Jan 21, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@oli-obk This error is user-facing, correct?

If so, the proposed formatting is not desirable, it should be using ExternAbi's formatting instead.

Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Member

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.

Copy link
Member

@workingjubilee workingjubilee Jan 21, 2025

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.

Copy link
Member

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.

Copy link
Contributor Author

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 ExternAbican 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 :)

Copy link
Member

@workingjubilee workingjubilee Mar 9, 2025

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.

Copy link
Member

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.

Copy link
Contributor Author

@tiif tiif Mar 10, 2025

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 :)

@oli-obk
Copy link
Contributor

oli-obk commented Jan 21, 2025

@bors r-

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jan 21, 2025
@rust-log-analyzer

This comment has been minimized.

@LFS6502
Copy link
Contributor

LFS6502 commented Mar 1, 2025

@tiif Thanks for your contribution. Are you able to address the code review?

@tiif
Copy link
Contributor Author

tiif commented Mar 1, 2025

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.

@tiif tiif marked this pull request as draft March 1, 2025 14:11
Copy link
Contributor Author

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.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@oli-obk oli-obk assigned workingjubilee and unassigned oli-obk Mar 12, 2025
@tiif tiif marked this pull request as ready for review March 12, 2025 17:16
@tiif
Copy link
Contributor Author

tiif commented Mar 13, 2025

@rustbot ready

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Mar 13, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants