What about the calling convention?

[bjorn3]

They are a mess and are highly architecture specific. In addition many parts of the calling convention can only be implemented as part of the actual codegen backend like LLVM. This includes register assignment. The Rust ABI builds on top of the native C calling convention, but only uses part of it's functionality. For example #[repr(C)] struct A(u32, u32) would be passed in a single register for the x86_64 System-V call conv, while Rust passes it in memory as pointer. If there is no #[repr(C)] it uses two registers. #[repr(C)] struct BigType([u8; 1024]) would be stored at a fixed stack offset for the x86_64 System-V call conv, while Rust passes a pointer to wherever it exists. Then there are special rules for mixing integers and floating points in a single struct. And another thing is that Rust currently forces vector types to be passed in memory in certain conditions as a workaround for bugs when mixing functions without simd enabled and with simd enabled.

[robinmoussu]

Just to add some oil on the fire:

https://github.com/rust-lang/rust-bindgen/issues/778

MakeFoo and MakeBar look very similar, however in C++ they use different ABIs, at least on Linux. Here's a quote from System V AMD64 ABI spec (page 20):

If a C++ object has either a non-trivial copy constructor or a non-trivial destructor, it is passed by invisible reference (the object is replaced in the parameter list by a pointer that has class POINTER)

[FranchuFranchu]

What about platforms where multiple return values are part of the "standard" ABI, like RISC-V's a0-a7 registers? When returning a tuple of <8 elements, do we push them to the stack or do we place each element in a different register?