Tracking Issue for extern "rust-preserve-none" ABI (feature `rust_preserve_none_cc`)

[nagisa]

This is a tracking issue for the experimental rust_preserve_none_cc added without RFC process.
The feature gate for the issue is #![feature(rust_preserve_none_cc)].

This feature is relatively closely related to rust_cold_cc of which this is a conceptual inverse.

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Discussion comments will get marked as off-topic or deleted.
Repeated discussions on the tracking issue may lead to the tracking issue getting locked.

Steps

• Implement
• Adjust documentation (see instructions on rustc-dev-guide)
• Style updates for any new syntax (nightly-style-procedure)
  • Style team decision on new formatting
  • Formatting for new syntax has been added to the Style Guide
  • (non-blocking) Formatting has been implemented in rustfmt
• Stabilization PR (see instructions on rustc-dev-guide)

Unresolved Questions

• What guarantees should we provide? My initial suggestion is that this is entirely an optimization hint and it should be fine to fall-back to regular Rust calling convention for backends that do not support this calling convention.
• How can we make using this compatible with mixing codegen backends – particularly in the context of using an LLVM-compiled standard library with a cranelift-compiled binary or tests?

Implementation history

• abi: add a rust-preserve-none calling convention #151065

[workingjubilee]

How can we make using this compatible with mixing codegen backends – particularly in the context of using an LLVM-compiled standard library with a cranelift-compiled binary or tests?

...well, I would hope that simply assuming nothing is preserved and thus all arguments have to be saved to perform the initial call would be easier to implement in a codegen backend, even if it doesn't then perform the tail-call optimization correctly, but maybe I am grossly misunderstanding this.

[nagisa]

Possibly. I do have a couple of concerns here:

We do kinda have to have our register assignments be consistent. At the same time it might be desirable to use all the non-preserved registers for arguments and returns.

And then just plain ability for the backends to support this. Right now I only really implemented it for LLVM and LLVM itself doesn't implement it for every architecture it supports as far as I know. So various combinations of support matrices between rustc and the backends can yield… interesting results.