# Rust proposes cross-crate forward declarations for safer kernel code

> **Key takeaway:** Jana Dönszelmann has proposed a new Rust language feature that provides a type-safe alternative to C weak symbols, with a concrete application to cleaning up integer overflow handling in the Linux kernel's Rust code.

**Published:** 2026-10-19T13:50:49+00:00 
**Source:** Linux Weekly News (LWN.net) 
**Category:** kernel-os 
**Canonical URL:** https://fosswire.org/news/rust-proposes-cross-crate-forward-declarations-for-safer-ker.html 

## Summary
A new Rust language feature called cross-crate forward declarations would let crates declare functions they need without defining them, with the compiler verifying that exactly one implementation exists at link time. This generalizes existing ad-hoc mechanisms like custom panic handlers and allocators. At Kangrejos 2026, Dönszelmann proposed applying this to the kernel's Rust integer overflow handling, which currently relies on a less clean workaround.

## How forward declarations would replace weak symbols
- **Current problem**: Rust's standard library uses multiple one-off mechanisms (panic_handler, global_allocator) for user code to inject behavior; the kernel's Rust integer overflow handling similarly needs a hook but lacks a clean abstraction
- **Proposed solution**: A `forward fn` declaration in one crate, with exactly one `impl fn` required in the dependency graph; the compiler checks this at link time rather than leaving it to the linker
- **Safety improvement**: Unlike C weak symbols, mismatches are caught at compile or link time rather than silently failing or linking incorrectly
- **Kernel application**: Would replace the current workaround for Rust's `overflow-checks` in kernel code, where integer overflow panics need to be redirected to kernel-specific handling instead of aborting

## Why it matters
If accepted, this would become a foundational Rust language feature that kernel and embedded developers could rely on for safe, late-bound configuration without unsafe code or linker-dependent behavior. It would also establish a pattern for future standard library extension points.