I kind of hinted at this in my other comment but IMO, any sort of proposal to express ABI in code is a non-starter. There is an immense amount of complexity (see all the LLVM tablegen files related to ABI) and little reason not to do things in assembly.

There are certainly problems with handwritten assembly that could be improved if you are interested, but I think this is better framed as “how can we make it easier to integrate handwritten assembly (like trampolines) with normal code” rather than trying to, effectively, get rustc to emit a very specific assembly without writing it.

You simply cannot ergonomically describe an ABI in a single trait, because it is a matter of dire amounts of polymorphism.

Speaking from the general view, even if we consider "how to handle an ABI" as a sort of stack machine-ish thing with multiple stacks for each type of register (so the machine mostly is reducing the program-argument stack while picking which machine-argument stack to push values into, essentially), a programmer-visible ABI is not required to translate to what we would consider a single mechanical implementation of a calling convention. It may select a different mechanical calling convention after considering the total function signature, which can have different stack or register usage rules.

Often these rules are not easily described via simple constants, but instead must be modeled like executable code, e.g. some ABIs will insert "fake" arguments at various points, considering numerous small rules, to handle certain alignment constraints.

This is not necessarily described entirely by stack alignment as a constraint, because an ABI may wish to consider "register alignment", which is not the same as stack alignment, and not the same as type alignment, but comes up quite often in actual CPU ISAs.

This just isn't enough to represent anything more than trivial ABIs. Different types may have different stack alignment, different float/int sizes may get passed in different registers, values may be split across registers, ADTs need to be figured out, etc...

Yeah I also thought that could be a problem.

I'm not an expert on what an ABI really does, but there should be some possible way to allow for ABI defs in rust.

I'm going to try and gather a bit more information and adjust the implementation

Ok i have thought of a better way to do this, im going to say it here before changing the RFC:

We can have special "abi" crates (like proc-macro) that can only export ABI defs.

Example:

Cargo.toml

[lib]
abi = true
# proc-macro = true
# this fails

lib.rs:

extern crate abi;

use abi::{Alignment, AbiTable, BasicType}; // basic types are unsigned interger

#[abi(align_for /*, method specific options */)]
pub fn align_for(ty: BasicType) -> Alignment {
    match ty {
         // ... 
         BasicType::U8 => Alignment::One
    }
}

#[abi(table, name="custom_abi")]
pub const CUSTOM_ABI: AbiTable = AbiTable::new()
     .set_align_for(ty);

Usage:

use abi_crate::CUSTOM_ABI; // required import

extern "custom_abi" fn do_nothing() {}

This offers more functionality, while keeping familiar API to users of Rust

I want to state again that this may not be the best way, and that i am not an expert.

I'm not an expert on what an ABI really does

You should not be writing a proposal for a full ABI definition framework which is permanently stable and cannot be changed unless you know what an ABI is and what it does. This doesn't mean that the idea doesn't have merit, but as someone who also does not fully understand ABIs, I at least am past the Dunning-Kruger curve enough to realise that defining an ABI using a simple trait does not seem sufficient in the slightest.

Not even LLVM seems to even attempt to tackle this goal. What makes you think that Rust can and should?

Just take a brief look at the closest similar proposal, to add crABI, and see if your proposal covers 1% of the requirements or answers 1% of the questions left open: rust-lang/compiler-team#631