RACE: Semantic-linker approach to stable cross-crate ABI without runtime overhead

language design
1

This is a pre-RFC exploration. Presenting it to gather feedback before considering a formal RFC.

Problem

Rust currently has no stable ABI. This is a deliberate and reasonable decision — it allows the compiler to optimize freely. However, it creates a hard barrier in several real-world scenarios:

  • Bevy and other engines cannot distribute pre-compiled plugins as .so files
  • Rust for Linux is constrained to isolated drivers with no deeper integration
  • Any ecosystem requiring independently compiled binary modules hits this wall

The usual workaround is #[repr(C)], which is a lossy escape hatch — you lose Rust's type expressiveness and optimization potential.

Proposed concept: RACE (Rust Advanced Contract Enforcement)

Instead of freezing a fixed ABI at the language level, RACE proposes moving ABI resolution to link time via a semantic-aware linker.

1. .rcrate format Compiled crates emit an intermediate .rcrate file containing:

  • Polymorphic machine code
  • A Semantic Type & Effects Graph (STEG) — rich type metadata beyond what DWARF provides

2. Symbolic Layout Offsets Field offsets are not baked into instructions at compile time. Instead, the final linker resolves and patches them as computed constants — zero runtime cost, no temporary allocations.

3. vtable layout synthesis dyn Trait vtables are a core ABI concern — reordering methods breaks call sites. RACE proposes vtable remapping at link time: the linker matches methods by identity and type metadata, synthesizing an adapted vtable layout to satisfy the caller's expectations.

This moves ownership/lifetime/type contract validation entirely to compile+link time, producing a fully monolithic binary with no runtime abstraction layers — suitable for no_std and hard real-time environments.

What this would unlock

  • Distributable pre-compiled Bevy plugins
  • Deeper Rust integration in the Linux kernel
  • Stable plugin ecosystems without WASM overhead

Open questions

  • Is STEG expressible within or alongside existing MIR metadata?
  • Are there soundness barriers to vtable remapping that make this approach unsafe?
  • Has anything similar been explored — e.g. in Swift's ABI stability work?
2

since you can use field offsets in constant expressions which allow you to arbitrarily change types, your proposal essentially means delaying nearly all compilation work to link time. e.g.: Compiler Explorer

2 Likes
3

Good point. The concern is valid for cases where field offsets feed into constant expressions that influence control flow or type decisions. RACE would need to either restrict Symbolic Layout Offsets to non-const contexts, or define a subset of const expressions where layout independence is guaranteed. This is a real constraint worth scoping carefully - it doesn’t invalidate the approach but does narrow where SLO can safely apply

4

This sounds adjacent to the BPF work: [Pre-RFC] BTF relocations

Perhaps it could be done only for types explicitly marked as such?

2 Likes
5

The BTF parallel is apt - CO-RE (Compile Once, Run Everywhere) in BPF solves a similar relocation problem with type metadata, and it works well in practice. Explicit opt-in marking is a compelling constraint - it would directly address the const expression concern raised above, since only explicitly marked types would participate in layout deferral. This could be the right shape for a minimal first version