This is the "Done" section from #2, moved here due to reaching GitHub's 64k character limit on issue text.

Done (stabilized, not needed anymore, etc.)

• As many required bits done in the Rust version of the upcoming Debian Stable (Trixie).

  • Trixie ended up with the requested 1.85 (which should allow us to use Edition 2024): https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2024-July/044870.html.
  • We are planning to move to that version as the new minimum supported version.

• --check-cfg.

  • Tracking Issue: Tracking Issue for RFC 3013: Checking conditional compilation at compile time rust-lang/rust#82450.
  • Used by: Kbuild.
  • Status: stabilized in 1.79 (Stabilize checking of cfgs at compile-time: --check-cfg option rust-lang/rust#123501).
  • Tested for the kernel in 1.77, feedback at: Tracking Issue for RFC 3013: Checking conditional compilation at compile time rust-lang/rust#82450 (comment).
  • PR from feedback (avoid printing all the possible cfgs): Limit the number of names and values in check-cfg diagnostics rust-lang/rust#121202 (1.78).
  • PR from feedback (use CARGO_CRATE_NAME instead of CARGO as a better heuristic for Cargo diagnostics): Use better heuristic for printing Cargo specific diagnostics rust-lang/rust#121237 (1.78).

• --extern force:.

  • Tracking Issue: Tracking Issue for --extern force rust-lang/rust#111302.
  • Used by: Kbuild in the past (as a workaround for "empty" Rust files, see commit ded103c ("kbuild: rust: force alloc extern to allow "empty" Rust files")), but not anymore since v6.13 due to the allocator series landing (commit 392e34b ("kbuild: rust: remove the alloc crate and GlobalAlloc")).
  • Status: it can be dropped when (at least) new_uninit is dropped. There may be other workarounds. Added as unstable in 1.71 (Add force option for --extern flag rust-lang/rust#109421).

• cfg(no_global_oom_handling).

  • Tracking Issue: -.
  • Used by: Kbuild (alloc) in the past, but not anymore since v6.13 due to the allocator series landing.
  • Status: added as unstable in 1.54 (alloc: Add unstable Cfg feature `no_global_oom_handling rust-lang/rust#84266).

• cfg(no_rc).

  • Tracking Issue: -.
  • Used by: Kbuild (alloc) in the past, but not anymore since v6.13 due to the allocator series landing.
  • Status: added as unstable in 1.66 (alloc: add unstable cfg features no_rc and no_sync rust-lang/rust#89891).

• cfg(no_sync).

  • Tracking Issue: -.
  • Used by: Kbuild (alloc) in the past, but not anymore since v6.13 due to the allocator series landing.
  • Status: added as unstable in 1.66 (alloc: add unstable cfg features no_rc and no_sync rust-lang/rust#89891).

• feature(allocator_api).

  • Tracking Issue: Allocator traits and std::heap rust-lang/rust#32838.
  • Used by: almost all modules.
  • Status: Linux does not use the alloc crate anymore: in Linux v6.13, Linux started using its own alloc module instead of the Rust standard library alloc crate; and in Linux v6.10, Linux removed its custom fork of the Rust standard library alloc crate.

• feature(alloc_error_handler).

  • Tracking Issue: Tracking issue for the #[alloc_error_handler] attribute (for no_std + liballoc) rust-lang/rust#51540.
  • Used by: -.
  • Status: marked as done since we use no_global_oom_handling.

• feature(asm_const).

  • Tracking Issue: Tracking Issue for asm_const rust-lang/rust#93332.
  • Used by: tracepoint support / static keys / jump label patching (https://lore.kernel.org/rust-for-linux/20240621-tracepoint-v3-1-9e44eeea2b85@google.com/, https://docs.kernel.org/staging/static-keys.html).
  • Status: stabilized in 1.82 (Stabilize asm_const rust-lang/rust#128570).
  • Original experimental PR in the kernel side: Experimental tracepoint support #1084.
  • Issue: Tracking issue: Support for pointers with asm_const rust-lang/rust#128464.
  • FCP passed (Tracking Issue for asm_const rust-lang/rust#93332 (comment)).

• feature(asm_goto).

  • Tracking Issue: Tracking Issue for asm_goto_with_outputs rust-lang/rust#119364.
  • Used by: nothing yet in-tree, but it is needed for e.g. reimplementing jump label support (https://docs.kernel.org/staging/static-keys.html, Experimental tracepoint support #1084). See as well @nbdd0121's HackMD document: Advanced inline assembly usage in Linux kernel.
  • Status: stabillized in 1.87 (Stabilize asm_goto feature gate rust-lang/rust#133870).
  • LKML: https://lore.kernel.org/rust-for-linux/ZWipTZysC2YL7qsq@Boquns-Mac-mini.home/
  • RFC: https://github.com/rust-lang/rfcs/blob/master/text/2873-inline-asm.md#asm-goto.
  • PR: Add asm goto support to asm! rust-lang/rust#119365 (1.78).
  • Labeled blocks are safe by default: Decide whether blocks inside asm goto should default to safe rust-lang/rust#132078.
  • PR (adds feature(asm_goto_with_outputs) in order to stabilize feature(asm_goto) sooner): Fix asm goto with outputs and move it to a separate feature gate rust-lang/rust#131523 (1.85).
  • PR: Make asm label blocks safe context rust-lang/rust#131544 (1.84).
  • LLVM Issue: asm goto miscompilation llvm/llvm-project#74483.
  • LLVM Issue: asm goto wrong output at -O0 llvm/llvm-project#110251.
  • PR: [RegAllocFast] Ensure live-in vregs get reloaded after INLINEASM_BR spills llvm/llvm-project#131350 (21?).
  • Reference PR: Add reference for asm-goto rust-lang/reference#1693.
  • Release notes: Tracking issue for release notes of #133870: Stabilize asm_goto feature gate rust-lang/rust#134860.
  • Zulip: https://rust-lang.zulipchat.com/#narrow/stream/425075-rust-for-linux/topic/asm-goto.20stabilization/near/447335751.

• feature(bench_black_box).

  • Tracking Issue: Tracking issue for std::hint::black_box rust-lang/rust#64102.
  • Used by: samples/rust/rust_stack_probing.rs.
  • Status: stabilized in 1.66 (Stabilize bench_black_box rust-lang/rust#102232).

• feature(box_uninit_write).

  • Tracking Issue: Tracking Issue for box_uninit_write rust-lang/rust#129397.
  • Used by: if it was stable, then we could have removed an unsafe block in Box<T>::new() (BoxExt), but not anymore since v6.13 due to the allocator series landing.
  • Status: unknown.

• feature(c_size_t)

  • Tracking Issue: Tracking Issue for #![feature(c_size_t)] (std::os::raw::c_size_t/std::os::raw::c_ssize_t) rust-lang/rust#88345.
  • Used by: rust/kernel/file.rs in our old rust branch (so far, but could be anywhere in the abstractions).
  • Status: unknown, but core_ffi_c got stabilized in 1.64 (Stabilize core::ffi:c_* and re-export in std::ffi rust-lang/rust#98315) and c_{s,}size_t are now in core::ffi since 1.61 (Provide C FFI types via core::ffi, not just in std rust-lang/rust#94503).

• feature(coerce_unsized) & feature(unsize) (core::ops::CoerceUnsized and core::marker::Unsize traits).

  • Tracking Issue: DST/custom coercions rust-lang/rust#18598.
  • Used by: Arc.
  • Status: we may use feature(derive_smart_pointer) instead to avoid depending on Arc's needed features; otherwise: "the CoerceUnsized trait is unstable and we wish to revisit its design before stabilizing, so for now only stdlib types can be unsized" + there are unsoundness issues, see Pin is unsound due to transitive effects of CoerceUnsized rust-lang/rust#68015 and A Pin unsoundness involving an impl DerefMut for Pin<&dyn LocalTrait> rust-lang/rust#85099. See https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/rust-for-linux.20custom.20arc.20unstable.20feature.20requirements.

• feature(cold_path).

  • Tracking Issue (core::hint::{cold_path}): Tracking Issue for cold_path rust-lang/rust#136873.
  • Tracking Issue (core::hint::{likely, unlikely}): Tracking Issue for likely_unlikely rust-lang/rust#151619.
  • Tracking Issue (meta): Meta tracking issue for branch hints (RFC 1131) rust-lang/rust#26179.
  • Used by: in the future, potentially many places (if \((|un)likely\(~23k matches).
  • Status: stabilized (std::hint::cold_path()) in 1.95. Several other proposals being considered: likely/unlikely, #[cold], whether weights could be specified...
  • PR (fix for likely/unlikely): Likely unlikely fix rust-lang/rust#120370 (1.84).
  • PR (std::hint::{un,}likely): Reexport likely/unlikely in std::hint rust-lang/rust#133695 (1.86).
  • PR (improve cold_path()): improve cold_path() rust-lang/rust#133852 (1.87).
  • PR (stabilization for cold_path()): Stabilize core::hint::cold_path rust-lang/rust#151576 (1.95).
  • PR: Update documentation for cold_path, likely, and unlikely rust-lang/rust#151612 (1.95).
  • ACP (cold_path()): Export cold_path() in std::hint rust-lang/libs-team#510.
  • Cc: @tgross35.

• feature(concat_idents).

  • Tracking Issue: Tracking issue for concat_idents rust-lang/rust#29599.
  • Used by: drivers/android/defs.rs in the past, nothing now.
  • Status: no plan to stabilize, using the paste crate is an alternative (or, in general, generating code). We ended up using a proc macro on our side Re-implement concat_idents! in libmacros #826. It was removed in 1.90 (Remove the deprecated unstable concat_idents! macro rust-lang/rust#142704).

• feature(const_fn_transmute).

  • Tracking Issue: Tracking Issue for using std::mem::transmute() in const fn (const_fn_transmute) rust-lang/rust#53605.
  • Used by: rust/kernel/str.rs.
  • Status: stabilized in 1.56 (Stabilize const_fn_transmute, const_fn_union rust-lang/rust#85769). It is one of the subfeatures of const_fn.

• feature(const_fn_trait_bound).

  • Tracking Issue: Meta tracking issue for const fn rust-lang/rust#57563.
  • Used by: rust/kernel/file_operations.rs and rust/kernel/module_param.rs.
  • Status: stabilized in 1.61 (Stabilize const_fn_fn_ptr_basics, const_fn_trait_bound, and const_impl_trait rust-lang/rust#93827). No tracking issue of its own. It is one of the subfeatures of const_fn.

• feature(const_maybe_uninit_as_mut_ptr).

  • Tracking Issue: Tracking Issue for const MaybeUninit::as(_mut)_ptr (feature: const_maybe_uninit_as_ptr) rust-lang/rust#75251.
  • Used by: rust/kernel/device_id.rs. https://lore.kernel.org/rust-for-linux/20241022213221.2383-6-dakr@kernel.org/#iZ31rust:kernel:lib.rs
  • Status: stabilized in 1.83 (Stabilize const MaybeUninit::as_mut_ptr rust-lang/rust#130542).

• feature(const_maybe_uninit_zeroed).

  • Tracking Issue: Tracking Issue for const_maybe_uninit_zeroed rust-lang/rust#91850.
  • Used by: PHY (https://lore.kernel.org/rust-for-linux/20231017113014.3492773-2-fujita.tomonori@gmail.com/).
  • Status: stabilized in 1.75 (Stabilize const_maybe_uninit_zeroed and const_mem_zeroed rust-lang/rust#116218).

• feature(const_mut_refs) & feature(const_refs_to_static).

  • Tracking Issue: Tracking issue for &mut T in const contexts (const_mut_refs) rust-lang/rust#57349 and Tracking Issue for const_refs_to_static rust-lang/rust#119618.
  • Used by: VFS, block layer... in order to fill const TABLEs (setting owner field to THIS_MODULE), as well as rust/kernel/module_param.rs (in the rust branch).
  • Status: const_mut_refs stabilized in 1.83 (Stabilize &mut (and *mut) as well as &Cell (and *const Cell) in const rust-lang/rust#129195; reference: const_eval: update for const_mut_refs and const_refs_to_cell stabilization rust-lang/reference#1590); const_refs_to_static stabilized in 1.82 (Stabilize const_refs_to_static rust-lang/rust#129759). It is one of the subfeatures of const_fn.
  • Ralf's comment at Tracking Issue for const_refs_to_static rust-lang/rust#119618 (comment).
  • Reduced example: https://godbolt.org/z/r58jP6YM4.
  • PR: unstably allow constants to refer to statics and read from immutable statics rust-lang/rust#119614 (1.78).
  • linux-vtable test case upstream: https://github.com/rust-lang/rust/blob/main/tests/ui/consts/const-ref-to-static-linux-vtable.rs. PR adding it: const_mut_refs: allow mutable pointers to statics rust-lang/rust#120932 (1.78).
  • Earlier (using static) Issue: const checker confuses "pointer to static mut" with "local mutable variable that escapes this scope" rust-lang/rust#118447.
  • Earlier (using static) Related PR: compile-time evaluation: detect writes through immutable pointers rust-lang/rust#118324 (1.76) (if merged, and then other follow-up work Ralf has planned also lands, then the restriction could be relaxed).
  • Rust Zulip discussion: https://rust-lang.zulipchat.com/#narrow/stream/146212-t-compiler.2Fconst-eval/topic/Consts.20pointing.20to.20mutable.20statics/near/404605842

• feature(const_panic).

  • Tracking Issue: Tracking issue for RFC 2345, "Allow panicking in constants" (const_panic) rust-lang/rust#51999.
  • Used by: rust/kernel/print.rs.
  • Status: stabilized in 1.57 (Stabilize const_panic rust-lang/rust#89508). It is one of the subfeatures of const_fn.

• feature(const_ptr_offset_from).

  • Tracking Issue: Tracking Issue for const offset_from (const_ptr_offset_from) rust-lang/rust#92980.
  • Used by: rust/kernel/driver.rs.
  • Status: stabilized in 1.65 (Stabilize const_ptr_offset_from. rust-lang/rust#96240).

• feature(const_ptr_write).

  • Tracking Issue: Tracking Issue for const_ptr_write rust-lang/rust#86302.
  • Used by: rust/kernel/device_id.rs. https://lore.kernel.org/rust-for-linux/20241022213221.2383-6-dakr@kernel.org/#iZ31rust:kernel:lib.rs
  • Status: stabilized in 1.83 (Stabilize const ptr::write* and mem::replace rust-lang/rust#130954).

• feature(const_raw_ptr_deref)

  • Tracking issue: [tracking issue] dereferencing raw pointers inside constants (const_raw_ptr_deref) rust-lang/rust#51911.
  • Used by: rust/kernel/str.rs.
  • Status: replaced on our side with const_fn_transmute since that was getting stabilized sooner.

• feature(const_refs_to_cell).

  • Tracking Issue: Tracking Issue for const_refs_to_cell rust-lang/rust#80384.
  • Used by: rust/kernel/driver.rs, offset_of! (if feature(offset_of) does not pan out).
  • Status: stabilized in 1.83 (Stabilize &mut (and *mut) as well as &Cell (and *const Cell) in const rust-lang/rust#129195, reference: const_eval: update for const_mut_refs and const_refs_to_cell stabilization rust-lang/reference#1590).

• feature(const_unreachable_unchecked).

  • Tracking Issue: Tracking Issue for const unreachable_unchecked rust-lang/rust#53188.
  • Used by: rust/kernel/str.rs.
  • Status: stabilized in 1.57 (Stabilize unreachable_unchecked as const fn rust-lang/rust#89509). It is one of the subfeatures of const_fn.

• feature(core_ffi_c)

  • Tracking Issue: Tracking Issue for core_ffi_c rust-lang/rust#94501.
  • Used by: bindings, module!, etc.
  • Status: stabilized in 1.64 (Stabilize core::ffi:c_* and re-export in std::ffi rust-lang/rust#98315).

• feature(core_panic).

  • Tracking Issue: None (internal to the compiler).
  • Used by: rust/build_assert.rs.
  • Status: not used anymore; replaced with panic!("{}", msg) (2021 edition, allowed in const context since Allow panic!("{}", computed_str) in const fn. rust-lang/rust#88954).

• feature(dispatch_from_dyn) (core::ops::DispatchFromDyn trait).

  • Tracking Issue: None (internal to the compiler).
  • Used by: Arc.
  • Status: we may use feature(derive_smart_pointer) instead to avoid depending on Arc's needed features; otherwise: see https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/rust-for-linux.20custom.20arc.20unstable.20feature.20requirements.
  • Issue: DispatchFromDyn rules allowing non-PhantomData ZSTs in additional fields is unsound rust-lang/rust#135220.

• feature(explicit_generic_args_with_impl_trait)

  • Tracking Issue: Tracking issue for explicit_generic_args_with_impl_trait rust-lang/rust#83701.
  • Used by: pinned-init.
  • Status: stabilized in 1.63 (Stabilize explicit_generic_args_with_impl_trait rust-lang/rust#96868).

• feature(file_with_nul) (C string equivalents (nul-terminated) for core::panic::Location (or a flag to ensure there is a \0 after the strs)).

  • Tracking Issue: Tracking Issue for NUL-terminated file names with #[track_caller] rust-lang/rust#141727.
  • Used by:kernel::file_from_location (https://lore.kernel.org/rust-for-linux/20250619151007.61767-2-boqun.feng@gmail.com/) for #[track_caller]s like kernel::task::might_sleep().
  • Status: stabilized in 1.92 (Stabilize std::panic::Location::file_as_c_str rust-lang/rust#145664), added as unstable in 1.89 (Add Location::file_with_nul rust-lang/rust#135054).
  • ACP: ACP: Add nul-terminated version of core::panic::Location::file rust-lang/libs-team#466 (accepted).
  • Rust Zulip: https://rust-lang.zulipchat.com/#narrow/stream/425075-rust-for-linux/topic/Caller.20location.20with.20nul-terminated.20filename/near/477164522.
  • PR: Add unstable option to nul-terminate location strings rust-lang/rust#135240.
  • PR: Add nul-terminated filename for #[track_caller] rust-lang/rust#131828.
  • PR: Null terminate core::panic::Location file strings rust-lang/rust#117431.
  • PR: Use raw pointer for NUL-terminated file location with #[track_caller] rust-lang/rust#142579.
  • PR: Rename Location::file_with_nul to file_as_c_str rust-lang/rust#145928 (1.91).
  • PR: Stabilize std::panic::Location::file_as_c_str rust-lang/rust#145664 (1.92).

• feature(generic_associated_types).

  • Tracking Issue: 🔬 Tracking issue for generic associated types (GAT) rust-lang/rust#44265.
  • Used by: rust/kernel/types.rs (PointerWrapper), rust/kernel/file_operations.rs (IoctlHandler).
  • Status: stabilized in 1.65 (Stabilize generic associated types rust-lang/rust#96709).

• feature(global_asm).

  • Tracking Issue: Tracking issue for global-asm support (RFC 1548) rust-lang/rust#35119.
  • Used by: all modules, due to code generated by the rust/module.rs proc macro.
  • Status: stabilized in 1.59 (Stabilize asm! and global_asm! rust-lang/rust#91728) -- we may want to avoid doing things this way anyway. See Consider removing the initcall logic from module.rs, use codegen instead #77.

• feature(impl_trait_in_assoc_type).

  • Tracking Issue: Tracking issue for RFC 2515, "Permit impl Trait in type aliases" rust-lang/rust#63063 (the tracking issue is the original one before it got split from that one in Split out a separate feature gate for impl trait in associated types rust-lang/rust#110237).
  • Used by: rnull in the past (https://lore.kernel.org/rust-for-linux/20240313110515.70088-5-nmi@metaspace.dk/), but not anymore.
  • Status: ?.

• feature(inline_const).

  • Tracking Issue: Tracking Issue for inline const patterns (RFC 2920) rust-lang/rust#76001.
  • Used by: rust/kernel/lib.rs.
  • Status: stabilized in 1.79 (Stabilise inline_const rust-lang/rust#104087), i.e. just before we started to use it, but our minimum (1.78) still requires it.

• feature(let_else).

  • The kernel's coding style avoids nesting/identation where possible, i.e. keeping the success path as the main path. let_else helps naturally with that (when applicable).
  • Tracking Issue: Tracking Issue for RFC 3137: let-else statements rust-lang/rust#87335.
  • Used by: rust/macros/paste.rs and potentially everywhere.
  • Status: stabilized in 1.65 (Stabilize let else rust-lang/rust#93628).

• feature(lint_reasons).

  • In particular, the #[expect] attribute. This feature already helped to discover that -Wclippy::dbg_macro was not being applied in the kernel, which triggered Custom dbg! macros for dbg_macro lint rust-lang/rust-clippy#11303.
  • Tracking Issue: Tracking issue for RFC 2383, "Lint Reasons RFC" rust-lang/rust#54503.
  • Used by: everywhere since v6.13 -- see commit 1f9ed17 ("rust: start using the #[expect(...)] attribute").
  • Status: stabilized in 1.81 (Let's #[expect] some lints: Stabilize lint_reasons (RFC 2383)  rust-lang/rust#120924) and issues are getting actively fixed, e.g. we found #[expect(dead_code)] does not behave identically to #[allow(dead_code)] rust-lang/rust#114557 while testing the feature for the kernel and it was fixed already in Respect #[expect] the same way #[allow] is with the dead_code lint rust-lang/rust#114710. The precise semantics (three possibilities: 1, 2a, 2b) are under discussion at Decision: semantics of the #[expect] attribute rust-lang/rust#115980.
  • Reference PR: Document new #[expect] attribute and reasons parameter (RFC 2383) rust-lang/reference#1237.

• feature(maybe_uninit_extra).

  • Tracking Issue: Tracking issue for #![feature(maybe_uninit_extra,const_maybe_uninit_write)] rust-lang/rust#63567.
  • Used by: rust/kernel/miscdev.rs.
  • Status: stabilized in 1.60 (Partially stabilize maybe_uninit_extra rust-lang/rust#92768) (non-const only, which is the only part we need).

• feature(more_fallible_allocation_methods).

  • Tracking Issue: Tracking Issue for more_fallible_allocation_methods rust-lang/rust#86942.
  • Used by: alloc in the past, but not anymore.
  • Status: unknown.

• feature(new_uninit).

  • Tracking Issue: Tracking issue for uninitialized constructors for Box, Rc, Arc rust-lang/rust#63291.
  • Used by: the pin-init API in the past, but not anymore since v6.13 due to the allocator series landing.
  • Status: partial stabilization PR (Partially stabilize feature(new_uninit) rust-lang/rust#129401). The feature was split during stabilization, with a couple new features were created for things not to be stabilized yet: box_uninit_write (which we could use to avoid an unsafe block, but it was replaced for the time being) and new_zeroed_alloc.
  • @tgross35 said:

    Last I heard the libs team was looking for a way to have something like a builder pattern rather than all the permutations of new, new_uninit, new_uninit_zeroed, try_new, etc. I proposed an incomplete API somewhere (libs team repo?) but it didn’t go anywhere

  • Alternative (proposed by Benno): https://rust-for-linux.zulipchat.com/#narrow/stream/288089-General/topic/dropping.20the.20.60new_uninit.60.20feature/near/435522549.

• feature(offset_of) (single-field, i.e. no enum, no nested).

  • Tracking Issue: Tracking Issue for #![feature(offset_of)] rust-lang/rust#106655.
  • Used by: rust/kernel/workqueue.rs and kernel/kasync/executor/workqueue.rs (https://git.kernel.org/pub/scm/linux/kernel/git/tj/wq.git/commit/?h=for-6.7-rust-bindings&id=7324b88975c525a013ae0db747df97924ce80675).
  • Status: stabilized in 1.77 (Stabilize single-field offset_of rust-lang/rust#118799).

• feature(offset_of_nested).

  • Tracking Issue: Tracking Issue for nested field access in offset_of rust-lang/rust#120140.
  • Used by: Binder (in one place: https://lore.kernel.org/rust-for-linux/CAH5fLgjP98pS1wsP=YXP5Yr79Y62VF7XPKjbj+G75B3SOFt80g@mail.gmail.com/) and possibly elsewhere in the future.
  • Status: stabilized in 1.82 (Stabilize offset_of_nested rust-lang/rust#128284).

• feature(pin_macro).

  • Tracking Issue: Tracking Issue for core::pin::pin! rust-lang/rust#93178.
  • Used by: stack_pin_init! and stack_try_pin_init!.
  • Status: stabilized in 1.68 (Stabilize ::{core,std}::pin::pin! rust-lang/rust#103800).

• feature(proc_macro_span_file) (i.e. only proc_macro::Span::{file, local_file} from feature(proc_macro_span)).

  • Tracking Issue: Tracking issue for proc_macro::Span inspection APIs rust-lang/rust#54725.
  • Used by: KUnit #[test]s (likely in v6.15+).
  • Status: stabilized in 1.88.
  • PR: Stabilize proc_macro::Span::{file, local_file}. rust-lang/rust#140514 (1.88).
  • Lore: https://lore.kernel.org/rust-for-linux/20250502215133.1923676-2-ojeda@kernel.org/.

• feature(raw_ref_op).

  • Tracking Issue: Tracking issue for RFC 2582, &raw [mut | const] $place (raw_ref_op) rust-lang/rust#64490.
  • Used by: everywhere starting in Linux v6.15-rc1.
  • Status: stabilized in 1.82 (Stabilize raw_ref_op (RFC 2582) rust-lang/rust#127679) -- already stable when we started, but we still support 1.78.

• feature(receiver_trait) (core::ops::Receiver trait).

  • Tracking Issue: None (internal to the compiler).
  • Used by: Arc.
  • Status: we moved to feature(arbitrary_self_types) in v6.12.

• feature(slice_flatten).

  • Tracking Issue: Tracking Issue for slice_flatten rust-lang/rust#95629.
  • Used by: Nova.
  • Status: stabilized in 1.80 (Stabilize slice_flatten rust-lang/rust#125561) -- already stable when we started, but we still support 1.78.
  • Lore: https://lore.kernel.org/rust-for-linux/20251101-b4-as-flattened-v1-1-860f2ebeedfd@nvidia.com/.

• feature(try_reserve).

  • Tracking Issue: Tracking issue for try_reserve: RFC 2116 fallible collection allocation rust-lang/rust#48043.
  • Used by: rust/kernel/lib.rs.
  • Status: stabilized in 1.57 (Stabilize try_reserve rust-lang/rust#87993).

• -Zallow-features.

  • Cargo reference: https://doc.rust-lang.org/cargo/reference/unstable.html#allow-features.
  • Used by: Kbuild.
  • Status: although it will never get stabilized, we will not need it as soon as all other features we need get stabilized, thus we mark it as done.

• -Zbuild-std.

  • Cargo reference: https://doc.rust-lang.org/cargo/reference/unstable.html#build-std.
  • WG: https://github.com/rust-lang/wg-cargo-std-aware.
  • Used by: Kbuild (only for the rusttest target, back when we had a custom alloc).
  • Status: marked as done since we do not have a custom alloc anmore. The actual progress is not clear. See std wanted features & bugfixes #572.

• -Zdwarf-version.

  • Tracking Issue: Tracking issue for -Zdwarf-version rust-lang/rust#103057.
  • Used by: Kbuild.
  • Status: stabilized in 1.88 (Stabilize -Zdwarf-version as -Cdwarf-version rust-lang/rust#136926), added as unstable in 1.64 (Implement support for DWARF version 5. rust-lang/rust#98350).
  • PR: Implement support for DWARF version 5. rust-lang/rust#98350.
  • PR: Stabilize -Zdwarf-version as -Cdwarf-version rust-lang/rust#136926.
  • Release notes: Tracking issue for release notes of #136926: Stabilize -Zdwarf-version as -Cdwarf-version rust-lang/rust#139747.

• -Zno-jump-tables (-Cjump-tables=n).

  • Tracking Issue: Tracking Issue for no-jump-tables rust-lang/rust#116592.
  • Used by: x86_64's CONFIG_X86_KERNEL_IBT (https://lore.kernel.org/rust-for-linux/20231009224347.2076221-1-mmaurer@google.com/).
  • Status: stabilized in 1.93 (Stabilize -Zno-jump-tables into -Cjump-tables=bool rust-lang/rust#145974) as -Cjump-tables=n.
  • PR: Add -Zno-jump-tables rust-lang/rust#105812 (1.68).
  • PR: Add unstable book page for the no-jump-tables codegen option rust-lang/rust#116593 (1.75).
  • PR: Stabilize -Zno-jump-tables into -Cjump-tables=bool rust-lang/rust#145974 (1.93).
  • Lore: https://lore.kernel.org/rust-for-linux/20251101094011.1024534-1-ojeda@kernel.org/.

• -Zremap-path-scope (i.e. fine-grained --remap-path-prefix).

  • Tracking Issue: Tracking Issue for trim-paths RFC 3127 rust-lang/rust#111540.
  • Used by: Kbuild (potentially -- please see: https://lore.kernel.org/rust-for-linux/CANiq72mcpVL1YXyDFi-PrbQ2Uh0WUA_VNqLZaOeqQnpY5HnX8Q@mail.gmail.com/ and https://lore.kernel.org/rust-for-linux/DG93P7TMCWCH.3ACJU31B2HELW@garyguo.net/).
  • Status: stabilized in 1.95 (Stabilize -Zremap-path-scope rust-lang/rust#147611), working properly since 1.94 (Overhaul filename handling for cross-compiler consistency rust-lang/rust#149709, https://lore.kernel.org/rust-for-linux/DG93P7TMCWCH.3ACJU31B2HELW@garyguo.net/), added in 1.75 (Implement rustc part of RFC 3127 trim-paths rust-lang/rust#115214).
  • PR: Implement rustc part of RFC 3127 trim-paths rust-lang/rust#115214 (1.75).
  • Issue: std::panic::Location::caller().file() uses absolute path when monomorphized in a different crate. rust-lang/rust#148328.
  • PR: Overhaul filename handling for cross-compiler consistency rust-lang/rust#149709 (1.94).
  • PR: Stabilize -Zremap-path-scope rust-lang/rust#147611 (1.95).
  • Lore: https://lore.kernel.org/rust-for-linux/CANiq72mcpVL1YXyDFi-PrbQ2Uh0WUA_VNqLZaOeqQnpY5HnX8Q@mail.gmail.com/.
  • Lore: https://lore.kernel.org/rust-for-linux/DG93P7TMCWCH.3ACJU31B2HELW@garyguo.net/.

• -Zsplit-dwarf-kind=split.

  • Tracking Issue: ?.
  • Used by: potentially Kbuild, but only if split stops being the default.
  • Status: added as unstable in 1.59 (cg: split dwarf for crate dependencies rust-lang/rust#89819). As long as split is the default, we will not need it.

• -Zsymbol-mangling-version=v0.

  • Tracking Issue: Tracking issue for RFC 2603, "Rust Symbol Mangling (v0)" rust-lang/rust#60705.
  • Used by: rust/exports.c.
  • Status: stabilized in 1.59 (Stabilize -Z symbol-mangling-version=v0 as -C symbol-mangling-version=v0 rust-lang/rust#90128). It will also be the new default, so this is a no-brainer (sess: default to v0 symbol mangling on nightly rust-lang/rust#89917).

• __rust_no_alloc_shim_is_unstable.

  • Tracking Issue: Tracking Issue for __rust_no_alloc_shim_is_unstable rust-lang/rust#123015.
  • Used by: rust/kernel/allocator.rs in the past, but not anymore since v6.13 due to the allocator series landing: https://lore.kernel.org/rust-for-linux/6HIL4hSg3hOCh5IDDOtdEaEy89ZksSJmSLNiKrSvpu2Q78wA5KdrCCrcPSD_p4jB7IlmVRyVBnvBllU4irzuYgpQJOBtwUInAKdOibtRjVc=@protonmail.com/, Björn says:

    This can be removed too. liballoc needed it for us to acknowledge that we were linking liballoc in a way that isn't guaranteed to be stable, but now that we are removing liballoc entirely, this static is no longer necessary.

  • Status: added as unstable in 1.71 (Support #[global_allocator] without the allocator shim rust-lang/rust#86844); see Formal support for linking rlibs using a non-Rust linker rust-lang/rust#73632 as well.