Rust unstable features needed for the kernel

[ojeda]

Unstable features (including language, library, tools...) we currently use.

See as well:

• Rust 2025H2 project goals: language features, compiler features, field projections, in-place initialization, build-std.
• Rust 2025H1 flagship project goal: issue, document. In addition, build-std goal: issue, document.
• Rust 2024H2 flagship project goal: issue, document, blog post.
• Rust wanted features #354
• core wanted features & bugfixes #514
• alloc wanted features & bugfixes #408
• std wanted features & bugfixes #572
• rustc wanted features & bugfixes #355
• rustdoc wanted features & bugfixes #350
• rustfmt wanted features & bugfixes #398
• bindgen wanted features & bugfixes #353
• Clippy wanted features & bugfixes #349
• Miri wanted features & bugfixes #397
• rustup wanted features & bugfixes #396
• rust-analyzer wanted features & bugfixes #1051
• Rust CI wanted features & bugfixes #1080
• Rust website/docs wanted features & bugfixes #1011
• tc-build wanted features & bugfixes #1155
• Coccinelle for Rust wanted features & bugfixes #1097
• LLVM and Clang wanted features & bugfixes #1132
• rustc_codegen_gcc wanted features & bugfixes #1098
• GCC Rust wanted features & bugfixes #1099
• pahole wanted features & bugfixes #1096
• KernelCI wanted features & bugfixes #927
• Compiler Explorer wanted features & bugfixes #949
• Distributions wanted features & bugfixes #1127
• Zulip wanted features & bugfixes #1029

Required (we almost certainly want them)

• cfg(no_fp_fmt_parse).

  • Tracking Issue: -.
  • Used by: Kbuild (core).
  • Status: added as unstable in 1.55 (core: add unstable no_fp_fmt_parse to disable float formatting code rust-lang/rust#86048).

• feature(arbitrary_self_types).

  • Tracking Issue: Tracking issue for RFC 3519: arbitrary_self_types rust-lang/rust#44874.
  • Used by: Arc.
  • Status: potential soundness issue found when used together with derive(CoercePointee) (arbitrary_self_types + derive_coerce_pointee allows calling methods whose where clauses are violated rust-lang/rust#136702), stabilization PR and report (Arbitrary self types v2: stabilize rust-lang/rust#135881), v2 implemented in 1.83 (Arbitrary self types v2: pointers feature gate. rust-lang/rust#129664), v1 introduced in 1.23.
  • Issue: arbitrary_self_types + derive_coerce_pointee allows calling methods whose where clauses are violated rust-lang/rust#136702.
  • RFC: Arbitrary self types v2 rust-lang/rfcs#3519.
  • PR: Fix ambiguous cases of multiple & in elided self lifetimes rust-lang/rust#117967 (1.81).
  • PR: Arbitrary self types v2: pointers feature gate. rust-lang/rust#129664 (1.83).
  • PR: Reject generic self types. rust-lang/rust#130098 (1.84).
  • PR: Rename Receiver -> LegacyReceiver rust-lang/rust#130225 (1.84).
  • PR: Arbitrary self types v2: (unused) Receiver trait rust-lang/rust#132144 (1.84).
  • PR: Arbitrary self types v2: main compiler changes rust-lang/rust#132961 (1.85).
  • PR: Arbitrary self types v2: adjust diagnostic. rust-lang/rust#134262 (1.85).
  • PR: Arbitrary self types v2: Weak & NonNull diagnostics rust-lang/rust#134264 (1.85).
  • PR: Arbitrary self types v2: better feature gate test rust-lang/rust#134271 (1.85).
  • PR: Arbitrary self types v2: niche deshadowing test rust-lang/rust#134509 (1.85).
  • PR: Arbitrary self types v2: roll loop. rust-lang/rust#134521 (1.85).
  • PR: Arbitrary self types v2: no deshadow pre feature. rust-lang/rust#134524 (1.85).
  • PR: Arbitrary self types v2: unstable doc updates. rust-lang/rust#134525 (1.85).
  • PR: Arbitrary self types v2: explain test. rust-lang/rust#136124 (1.86).
  • PR: Make ptr_cast_add_auto_to_object lint into hard error rust-lang/rust#136764 (1.87).
  • PR: Forbid freely casting lifetime bounds of dyn-types rust-lang/rust#136776.
  • PR: arbitrary_self_types: Split the Autoderef chain rust-lang/rust#146095.
  • Issue: Miri build preventing landing changes which require both lib and compiler work rust-lang/rust#138065.
  • Issue: Tracking Issue for breaking lifetime changing raw pointer casts of trait objects rust-lang/rust#141402.
  • derive(CoercePointee) builds on top of this.
  • HackMD: https://hackmd.io/z4n40072Tqy8MhQPZn0N-g.
  • Rust Zulip: https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/rust-for-linux.20custom.20arc.20unstable.20feature.20requirements.
  • Previously (before v6.12), we used feature(receiver_trait) instead.
  • May require supertrait auto-impl (auto impl): Supertrait Auto-impl rust-lang/rfcs#3851.

• feature(asm_const_ptr) (asm_const for raw pointers).

  • Tracking Issue: Tracking issue: Support for pointers with asm_const rust-lang/rust#128464.
  • Used by: tracepoint support / static keys / jump label patching in the future (https://lore.kernel.org/rust-for-linux/20240621-tracepoint-v3-1-9e44eeea2b85@google.com/, https://docs.kernel.org/staging/static-keys.html), since implementing support for static keys requires a long list of workarounds at the moment.
  • Status: implemented for LLVM backend, not GCC backend. RFC merged.
  • RFC: Pass pointers to const in assembly rust-lang/rfcs#3848.
  • Original experimental PR in the kernel side: Experimental tracepoint support #1084.
  • Issue: Allow pointers in inline assembly const expressions rust-lang/rust#132012.
  • Issue: ICE "Unexpected free regions in MIR" with asm_const, missing constant, async, and lifetime parameter rust-lang/rust#117877.
  • PR: Handle asm const similar to inline const rust-lang/rust#137686 (1.87).
  • PR: Support using const pointers in asm const operand rust-lang/rust#138618.
  • LLVM issue: large displacement gets silently truncated llvm/llvm-project#138905.
  • Zulip: https://rust-lang.zulipchat.com/#narrow/channel/425075-rust-for-linux/topic/asm-goto.20and.20const-embedded.20pointers.20.23128464/.

• feature(compiler_builtins) or, better, a way to disable/disallow certain intrinsics.

  • Tracking Issue: internal to the compiler.
  • Used by: Kbuild.

• feature(derive_coerce_pointee) (previously feature(derive_smart_pointer)), i.e. derive(CoercePointee) (previously derive(SmartPointer)).

  • Tracking Issue: Tracking issue for RFC 3621: derive(CoercePointee) rust-lang/rust#123430.
  • Tracking Issue: Tracking issue for release notes of #133820: Stabilize derive(CoercePointee) rust-lang/rust#134624.
  • Used by: Arc.
  • Status: to be stabilized (Stabilize derive(CoercePointee) rust-lang/rust#133820). The kernel uses CoercePointee since v6.14 (commit 47cb6bf ("rust: use derive(CoercePointee) on rustc >= 1.84.0")).
  • Issue: arbitrary_self_types + derive_coerce_pointee allows calling methods whose where clauses are violated rust-lang/rust#136702.
  • Stabilization concern: CoercePointee doesn't tightly enforce the restriction to #[repr(transparent)]-only wrappers, if other proc-macros are involved rust-lang/rust#135206.
  • Stabilization concern: CoerceUnsized builtin checks do not handle aliases rust-lang/rust#135214.
  • Stabilization concern: CoercePointee leaks unstable unsizing impls rust-lang/rust#135217.
  • Issue: DispatchFromDyn builtin checks are weaker than CoerceUnsized rust-lang/rust#135215.
  • It is an alternative ("hooks/customization points") to having to stabilize other unstable features that would be otherwise needed to implement our custom Arc.
  • Original implementation PR: WIP: PoC for derive(SmartPointer) rust-lang/rust#123472.
  • PR (feature(pin_coerce_unsized_trait), one of the solutions for the unsoundness issue in the main RFC): PinCoerceUnsized trait into core rust-lang/rust#125048 (1.82).
  • RFC: RFC: #[derive(SmartPointer)] rust-lang/rfcs#3621.
  • Cc: @wedsonaf, @Darksonn, @Veykril, @dingxiangfei2009.
  • Meeting/discussion document: https://hackmd.io/OCz8EfzrRXeogXEDcOrL2w.
  • Rust Zulip discussion: https://rust-lang.zulipchat.com/#narrow/stream/410673-t-lang.2Fmeetings/topic/RfL.20meeting.202024-03-06/near/431156003.
  • Rust Zulip discussion: https://rust-lang.zulipchat.com/#narrow/stream/425075-rust-for-linux/topic/meeting.202024-04-03/near/431148847.
  • Related: Add test for dynamic dispatch + Pin::new soundness rust-lang/rust#125072 (1.80).
  • PR: SmartPointer derive-macro rust-lang/rust#125575 (1.81).
  • PR: Reject SmartPointer constructions not serving the purpose rust-lang/rust#127283 (1.81).
  • PR: derive(SmartPointer): require pointee to be maybe sized rust-lang/rust#128452 (1.82).
  • PR: derive(SmartPointer): register helper attributes rust-lang/rust#128925 (1.82).
  • PR: Improve DispatchFromDyn and CoerceUnsized impl validation rust-lang/rust#135228 (1.86).
  • PR: Introduce CoercePointeeValidated for coherence checks at typeck stage rust-lang/rust#136107 (1.86).
  • PR: Add documentation for derive(CoercePointee) rust-lang/rust#136351 (1.86).
  • PR: Make ptr_cast_add_auto_to_object lint into hard error rust-lang/rust#136764 (1.87).
  • PR: Forbid freely casting lifetime bounds of dyn-types rust-lang/rust#136776.
  • Issue: Confusing error when using CoercePointee rust-lang/rust#134846.
  • Issue: Tracking Issue for breaking lifetime changing raw pointer casts of trait objects rust-lang/rust#141402.
  • PR: Redact CoercePointee target type rust-lang/rust#136796.
  • PR: Consolidate and improve error messaging for CoerceUnsized and DispatchFromDyn rust-lang/rust#137289 (1.87).
  • Issue: #[pointee] attribute can be applied to anything rust-lang/rust#128485.
  • Label: https://github.com/rust-lang/rust/labels/F-derive_smart_pointer.
  • Issue: Decide on name for derive(SmartPtr) rust-lang/rust#129104.
  • PR: Rename macro SmartPointer to CoercePointee rust-lang/rust#131284 (1.84).
  • Issue: The #[pointee] attribute is required even if there is only one generic parameter rust-lang/rust#129465.
  • PR: Remove unsizing coercions for tuples rust-lang/rust#137728 (1.87).
  • Issue: CoercePointee doesn't support trait bounds on the smart pointer rust-lang/rust#138172.
  • PR: Elaborate trait assumption in receiver_is_dispatchable rust-lang/rust#138174 (1.87).
  • Issue: Unsize-coercible type causes [SOME_CONST; 0] to execute Drop, but only if type is annotated. rust-lang/rust#143671.
  • PR: Do not materialise X in [X; 0] when X is unsizing a const rust-lang/rust#145277.
  • Issue: derive(CoercePointee) is unsound with user-defined attribute macros. rust-lang/rust#148899.
  • Related Issue (interaction with dispatch_from_dyn, which we stopped using in favor of derive_coerce_pointee): Unsoundness and ICE due to DispatchFromDyn allowing bogus impls on references. rust-lang/rust#148727.
  • RFC patch that uses it: https://lore.kernel.org/rust-for-linux/20240823-derive-smart-pointer-v1-1-53769cd37239@google.com/.
  • Kernel PR: Switch to CoercePointee macro, with examples #1130.
  • Lore: https://lore.kernel.org/rust-for-linux/20241202100948.2416372-1-dingxiangfei2009@gmail.com/.

• feature(register_tool).

  • Tracking Issue: Tracking issue for #![register_tool] rust-lang/rust#66079.
  • Used by: klint Experimental PR for introducing klint #958.
  • Status: waiting for RFC to clarify use cases.
  • RFC: #![register_{attribute,lint}_tool] rust-lang/rfcs#3808.

• feature(used_with_arg) (#[used(compiler)] in particular).

  • Tracking Issue: Tracking Issue for used_with_arg rust-lang/rust#93798.
  • Used by (likely): the module! macro, rusttest...
  • Status: ?.
  • Lore: https://lore.kernel.org/rust-for-linux/20250712160103.1244945-3-ojeda@kernel.org/.
  • Zulip (revert discussion): https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Reverting.20.60.23.5Bused.5D.60.20default.20change.3F/near/532010071.

• -Zbranch-protection.

  • Tracking Issue: Tracking Issue for stabilisation of -Z branch-protection rust-lang/rust#113369.
  • Used by: arm64's CONFIG_ARM64_BTI_KERNEL etc.
  • Status: Unknown, potentially to be merged with -Zcf-protection -- see https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/.60-Zbranch-protection.60.20stability/near/391152508.

• -Zcf-protection=branch (CET).

  • Tracking Issue: Tracking Issue for control-flow enforcement technology (CET) rust-lang/rust#93754.
  • Used by: x86_64's CONFIG_X86_KERNEL_IBT (https://lore.kernel.org/rust-for-linux/20231009224347.2076221-1-mmaurer@google.com/).
  • Status: implemented in 1.60 (Add support for control-flow protection rust-lang/rust#93439).

• -Zdebuginfo-compression (including zstd support in Rust binaries' bundled LLVM).

  • Tracking Issue: Tracking Issue for -Zdebuginfo-compression rust-lang/rust#120953.
  • Used by: Kbuild.
  • Status: added as unstable in 1.74 (debuginfo: add compiler option to allow compressed debuginfo sections rust-lang/rust#115358).
  • PR (support in bundled LLVM): Enable zstd for debug compression. rust-lang/rust#125642 (1.82).
  • The zstd support is used in Android, where it currently warns, see commit dbef181 ("kbuild: rust: use -Zdebuginfo-compression").

• -Zdirect-access-external-data={yes,no} (Clang's -fdirect-access-external-data).

  • Tracking Issue: Tracking Issue for -Zdirect-access-external-data rust-lang/rust#127488.
  • Used by: LoongArch (https://lore.kernel.org/rust-for-linux/20240703110624.1301830-1-wangrui@loongson.cn/).
  • Status: added as unstable in 1.78 (Add unstable -Z direct-access-external-data cmdline flag for rustc rust-lang/rust#119162).
  • MCP: Add -Z direct-access-external-data rust-lang/compiler-team#707.

• -Zindirect-branch-cs-prefix (GCC's and Clang's -mindirect-branch-cs-prefix).

  • Tracking Issue: Retpoline support in rustc (target features or dedicated flags) rust-lang/rust#116852.
  • Used by: x86_64's CONFIG_MITIGATION_RETPOLINE.
  • Status: added as unstable in 1.91 (Add -Zindirect-branch-cs-prefix rust-lang/rust#140740).
  • MCP: Flag -Zindirect-branch-cs-prefix (retpoline mitigation) rust-lang/compiler-team#899.

• -Zfixed-x18.

  • Tracking Issue: -.
  • Used by: arm64's shadow call stack (SCS) support.
  • Status: added as unstable in 1.80 Add -Zfixed-x18 rust-lang/rust#124655.
  • PR: Unconditionally allow shadow call-stack sanitizer for AArch64 rust-lang/rust#128348 (1.82).
  • PR (RV64IMAC and RV64GC): riscv64imac: allow shadow call stack sanitizer rust-lang/rust#129316 (1.82).
  • PR: Make -Zfixed-x18 into a target modifier rust-lang/rust#140661 (1.88).

• -Zfunction-return=thunk-extern.

  • Tracking Issue: Tracking Issue for -Zfunction-return rust-lang/rust#116853.
  • Used by: x86_64's CONFIG_MITIGATION_RETHUNK.
  • Status: added as unstable in 1.76 (Add -Zfunction-return={keep,thunk-extern} option rust-lang/rust#116892).
  • PR (fix for module flags): Add missing module flags for -Zfunction-return=thunk-extern rust-lang/rust#130824 (1.83).

• -Zinstrument-mcount.

  • Tracking Issue: ? Tracking issue for function attribute #[coverage] rust-lang/rust#84605 (#[no_coverage]).
  • Used by: ftrace, probably/eventually.
  • Status: Broken? (Instrumentation (-Zinstrument-mcount) broken due to missing LLVM-pass since LLVM13 update rust-lang/rust#92109). Perhaps related to the new pass manager? Closed PR: Add EntryExistInstrumenterPass for -Z instrument-mcount to the pipeline manually for LLVM >= 13. rust-lang/rust#96238.

• -Zmin-function-alignment=N.

  • Tracking Issue: Tracking Issue for #[align(...)] on function items (fn_align) rust-lang/rust#82232.
  • Used by: not yet, but in the C side essentially by all architectures (and by x86_32 as -falign-functions=0 only for a few CPUs). @fbq mentions function tracing requires it (at least for arm64 and RISC-V).
  • Status: stabilization PR (Stabilize -Cmin-function-alignment rust-lang/rust#142824), added as unstable in 1.86 (add -Zmin-function-alignment rust-lang/rust#134030). There is a listed concern on the interaction with function pointers.
  • PR: Stabilize fn_align: #[align(N)] on functions rust-lang/rust#140261.
  • PR: centralize -Zmin-function-alignment logic rust-lang/rust#142854 (1.89).
  • PR: make -Zmin-function-alignment a target modifier rust-lang/rust#143323.
  • Stabilization report: Tracking Issue for #[align(...)] on function items (fn_align) rust-lang/rust#82232 (comment).
  • Original Issue: -Cmin-function-alignment/-Calign-functions support in rustc rust-lang/rust#128830.
  • The behavior wanted is that of GCC's -fmin-function-alignment (GCC, Clang does not support it -- its -falign-functions already behaves like -fmin-function-alignment) and Clang's -falign-functions (GCC, Clang), i.e. align all functions, including cold functions.
  • RFC (related -- individual align): RFC: Add an attribute for raising the alignment of various items rust-lang/rfcs#3806.
  • Zulip: https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Stabilization.20of.20.60-Cmin-function-alignment.60.20.28.23140261.29/near/525017924.

• -Zpatchable-function-entry support (GCC's and Clang's -fpatchable-function-entry), as well as the patchable_function_entry function attribute.

  • Tracking Issue: Tracking Issue for RFC 3543 patchable-function-entry rust-lang/rust#123115.
  • Used by: x86 (https://lore.kernel.org/rust-for-linux/20231211150753.293883-1-mmaurer@google.com/).
  • Status: added as unstable in 1.81 (patchable-function-entry: Add unstable compiler flag and attribute rust-lang/rust#124741).
  • MCP: Support patchable-function-entry rust-lang/compiler-team#704 (just the flag).
  • RFC: RFC: patchable-function-entry rust-lang/rfcs#3543 (full support).
  • Candidate implementation: https://github.com/maurer/rust/tree/patchable-function-entries.

• -Zrandomize-layout (and -Zlayout-seed=<seed>).

  • Tracking Issue: Tracking issue for -Z randomize-layout rust-lang/rust#106764.
  • Used by: security, probably/eventually.
  • Status: unknown. The use case of the MCP was debugging (e.g. detecting invalid layout assumptions), rather than security (which the kernel uses under some configurations -- see CONFIG_RANDSTRUCT*).

• -Zregparm=3 (GCC's/Clang's -mregparm=3).

  • Tracking Issue: Tracking Issue for -Zregparm rust-lang/rust#131749.
  • Used by: x86 (i.e. 32-bit).
  • Status: added as unstable in 1.84 (rust_for_linux: -Zregparm=<N> commandline flag for X86 (#116972) rust-lang/rust#130432). See Support x86 (i.e. 32-bit) #78 (comment) as well for the flag not applying to builtins like memset as of 1.89.
  • Issue: -Zregparm does not work correctly for LLVM builtins rust-lang/rust#145271.
  • PR: Fix -Zregparm for LLVM builtins rust-lang/rust#145309 (1.91).
  • Issue: -Zregparm doesn't put 64-bit arguments in registers rust-lang/rust#145694.
  • PR: x86: Correctly pass larger structs/types in registers with -Zregparm rust-lang/rust#147628.
  • From: [BROKEN] 32-bit x86 (i386) support #966 (comment).
  • Commit: e852f31 ("[PATCH] Add CONFIG for -mregparm=3") (in history.git).
  • Old issue: -Zregparm=3 support in rustc rust-lang/rust#116972.
  • Old note: -Zregparm=3 could have been just a bit of plumbing in rustc, but it turns out Clang is the one that has the logic to decide the registers, which then get marked in LLVM IR, and thus rustc needs to duplicate the logic (or moving it into LLVM and then wait for a release).

• -Zreg-struct-return (GCC's/Clang's -freg-struct-return).

  • Tracking Issue: Tracking issue: -Zreg-struct-return support in rustc rust-lang/rust#116973.
  • Used by: x86 (i.e. 32-bit).
  • Status: added as unstable in 1.85 (rust_for_linux: -Zreg-struct-return commandline flag for X86 (#116973) rust-lang/rust#130777).
  • PR: Add assembly test for -Zreg-struct-return option rust-lang/rust#145382 (1.91).
  • Commit: 2516512 ("[PATCH] x86: add -freg-struct-return to CFLAGS").
  • Old note: -Zreg-struct-return can be skipped if a target.json is used (abi_return_struct_as_int in target spec).

• -Zretpoline and -Zretpoline-external-thunk (Clang's -mretpoline-external-thunk and GCC's -mindirect-branch=thunk-extern -mindirect-branch-register).

  • Tracking Issue: Retpoline support in rustc (target features or dedicated flags) rust-lang/rust#116852.
  • Used by: x86_64's CONFIG_MITIGATION_RETPOLINE.
  • Status: added as unstable in 1.89 (retpoline and retpoline-external-thunk flags (target modifiers) to enable retpoline-related target features rust-lang/rust#135927).
  • MCP: Flags for retpoline mitigation rust-lang/compiler-team#868.

• -Zsanitizer=kcfi & -Zsanitizer-cfi-normalize-integers (KCFI).

  • Tracking Issue (KCFI): Tracking Issue for Kernel Control Flow Integrity (KCFI) Support for Rust rust-lang/rust#123479.
  • Tracking Issue (CFI): Tracking Issue for LLVM Control Flow Integrity (CFI) Support for Rust rust-lang/rust#89653.
  • Tracking Issue (sanitizers in general): Tracking issue for sanitizer support rust-lang/rust#39699.
  • Tracking Issue (stabilizing sanitizers): Tracking Issue for stabilizing the sanitizers (e.g., AddressSanitizer, LeakSanitizer, MemorySanitizer, ThreadSanitizer) rust-lang/rust#123615.
  • Used by: arm32/arm64/RISC-V/x86_64's KCFI (CONFIG_CFI_CLANG).
  • Status: ready for use in 1.79 (https://lore.kernel.org/rust-for-linux/CAGSQo024u1gHJgzsO38Xg3c4or+JupoPABQx_+0BLEpPg0cOEA@mail.gmail.com/), implemented with some key differences vs. CFI -- benchmarks needed / report regressions (https://lore.kernel.org/rust-for-linux/CAOcBZOS2kPyH0Dm7Fuh4GC3=v7nZhyzBj_-dKu3PfAnrHZvaxg@mail.gmail.com/).
  • PR: sanitizers: Stabilize AddressSanitizer and LeakSanitizer for the Tier 1 targets rust-lang/rust#123617.
  • KCFI PRs: https://github.com/rust-lang/rust/pulls?q=is%3Apr+cfi+label%3APG-exploit-mitigations+-label%3Arollup (1.58..1.79).
  • KCFI will require -Cpanic=abort until LLVM's invoke supports KCFI bundles: CFI: Abstract Closures and Coroutines rust-lang/rust#123106 (comment).
  • KCFI Rust docs: https://doc.rust-lang.org/nightly/unstable-book/compiler-flags/sanitizer.html#kernelcontrolflowintegrity.
  • KCFI RFC: RFC: Improve C types for cross-language LLVM CFI support rust-lang/rfcs#3296.
  • KCFI PR on the kernel side: rust: Enable KCFI support #1034 (https://github.com/maurer/linux/commits/kcfi/).
  • PR (fix for module flags): Add missing module flags for CFI and KCFI sanitizers rust-lang/rust#129373 (1.82).
  • Related PR (remove #[no_sanitize]): Remove the #[no_sanitize] attribute in favor of #[sanitize(xyz = "on|off")] rust-lang/rust#142681.
  • LLVM (backport fix to LLVM 19): release/19.x: Fix KCFI types for generated functions with integer normalization (#104826) llvm/llvm-project#113938, https://lore.kernel.org/lkml/202410281414.c351044e-oliver.sang@intel.com/.
  • bindgen Issue: Support repr(C) for enums rust-lang/rust-bindgen#3263.
  • @maurer's design doc: Fixing CFI VTables.
  • Cc: @rcvalle @maurer.

• -Zsanitize-kcfi-arity (i.e. the equivalent of Clang's -fsanitize-kcfi-arity).

  • Tracking Issue: Tracking Issue for -Zsanitize-kcfi-arity rust-lang/rust#138311.
  • Tracking Issue (KCFI): Tracking Issue for Kernel Control Flow Integrity (KCFI) Support for Rust rust-lang/rust#123479.
  • Status: added as unstable in 1.88.
  • Required for the upcoming CONFIG_FINEIBT_BHI.
  • Lore: https://lore.kernel.org/lkml/20250224123703.843199044@infradead.org/.
  • See as well LLVM and Clang wanted features & bugfixes #1132.
  • PR: KCFI: Add KCFI arity indicator support rust-lang/rust#138368 (1.88).

• -Ztune-cpu=generic.

  • Tracking Issue: ?.
  • Used by: x86's Makefile.
  • Status: unknown (no tracking issue?).
  • Lore: https://lore.kernel.org/all/CAHk-=wji1sV93yKbc==Z7OSSHBiDE=LAdG_d5Y-zPBrnSs0k2A@mail.gmail.com/.

• -Zuse-sync-unwind=n.

  • Tracking Issue: ?.
  • Used by: arm64.
  • Status: added as unstable in 1.77 (Add -Zuse-sync-unwind rust-lang/rust#117744). We may not need it as long as n remains the default.
  • From: https://lore.kernel.org/rust-for-linux/CAH5fLgg0yGbuHnMbMB103Zssg4KSfXUR3kvhr0kuqTSah=6kWg@mail.gmail.com/

• rustdoc's --generate-link-to-definition (-Zunstable-options).

  • Tracking Issue: rustdoc: Tracking issue for generating links to definitions on source code pages rust-lang/rust#89095.
  • Used by: KUnit test generation.
  • Status: no recent update.
  • PR: Provide doc links at item definitions on source pages rust-lang/rust#89157 (a [references] link from doc/source view could be nice to get).
  • Draft RFC: RFC for rustdoc jump to definition GuillaumeGomez/rfcs#1.
  • Enabled at: https://rust.docs.kernel.org.
  • Cc: @GuillaumeGomez.

• rustdoc: a way to extract doctests (--output-format=doctest, currently using a hack via --test-builder + --no-run (-Zunstable-options)).

  • Tracking Issue: rustdoc: Tracking issue for command-line flag --output-format=doctest rust-lang/rust#134529.
  • Used by: KUnit test generation.
  • Status: discussed most recently on RustWeek 2025. Second iteration of the new --output-format=doctest implementation waiting for test on Rust for Linux side.
  • PR: [rustdoc] Add --output-format=doctest command-line flag rust-lang/rust#134531 (1.86).
  • PR: Fully qualify Result in generated doctest code rust-lang/rust#137807 (1.87).
  • PR: [rustdoc] Give more information into extracted doctest information rust-lang/rust#141399 (1.89).
  • Cc: @GuillaumeGomez, @aDotInTheVoid.
  • Tracking Issue (old hack: --no-run): rustdoc: Tracking issue for command-line flag --no-run rust-lang/rust#87022.
  • Tracking Issue (old hack: --test-builder): rustdoc: Tracking issue for command-line flag --test-builder rust-lang/rust#102981.
  • A better approach would be some kind of machine-readable output (e.g. JSON) with all the details of tests found (e.g. text/code, file/path and line/column, "properties" of the test such as ignore, etc.).
  • Related: the --runtool* flags (PR: Allow cross-compiling doctests rust-lang/rust#60387, Tracking Issue: Tracking Issue for Cross Compiling Doctests rust-lang/rust#64245, PR: Stabilize flags for doctest cross compilation rust-lang/rust#137096 (1.88)) allow to run tests under a particular tool, but it simply passes the path of the prebuilt binary to the tool, e.g. valgrind, thus it is not useful in our case.
  • See also doctests rust-lang/testing-devex-team#5 (there are mentions of unspecializing doctests, transforming them into #[test]s or manipulating them).
  • Zulip: https://rust-lang.zulipchat.com/#narrow/channel/425075-rust-for-linux/topic/what's.20the.20rustdoc.20hack.3F/near/482709684.
  • Zulip: https://rust-lang.zulipchat.com/#narrow/channel/266220-t-rustdoc/topic/rust-for-linux.20requirements/near/486171810.
  • Zulip: https://rust-lang.zulipchat.com/#narrow/channel/266220-t-rustdoc/topic/Interesting.20rust-for-linux.20thread.20on.20doctests.2E/near/483382641.
  • HackMD (2024-12-18 Rust <-> Rust for Linux minutes): https://hackmd.io/vcnuZEpqQaaVNVZZmTFyIA?view#rustdoc-a-way-to-extract-doctests.
  • Zulip: https://rust-lang.zulipchat.com/#narrow/channel/266220-t-rustdoc/topic/rust-for-linux.20requirements/near/489832318.

• Clippy's configuration.

  • Tracking Issue: ?
  • Used by: Kbuild.
  • Status: RFC (stable clippy.toml: Create RFC rust-lang/rust-clippy#15630). Both the file and the environment variable are currently unstable, according to the documentation at https://doc.rust-lang.org/clippy/configuration.html.
  • What we need is that Clippy does not break in the future when using it. For that, there are a few aspects:
    • The stability of each of the configuration keys and values (currently we use: msrv, check-private-items and disallowed-macros; we may soon use doc-valid-idents).
    • The stability of the .clippy.toml file (i.e. its existence). The kernel does not necessarily need that it is a file -- we could also use flags, for instance.
    • The stability of the CLIPPY_CONF_DIR environment variable. The kernel uses it since it supports builds outside the source tree and thus we need to point it to the source tree so that it finds .clippy.toml. If we were not to use the .clippy.toml, file, this would not be needed.
    • How to handle different compiler versions: for other tools (e.g. rustc), the kernel already handles passing different sets of flags depending on the compiler version. It would be easy for us to do the same for Clippy if the configuration options could be passed that way. Otherwise, if it is a file, there is the question of how to handle unknown keys/values. The kernel could also consider generating the configuration file on the fly, to avoid that issue.
  • HackMD (RFC-like): https://hackmd.io/@flip1995/By87NXIc1g.
  • RFC: stable clippy.toml: Create RFC rust-lang/rust-clippy#15630.
  • Zulip: https://rust-lang.zulipchat.com/#narrow/channel/257328-clippy/topic/stablization.20of.20clippy.2Etoml.20a.

• Remaining target features unknown to rustc.

  • Tracking Issue: Tracking issue for RFC 2045: improving #[target_feature] rust-lang/rust#44839 (split into roughly per-architecture ones now, e.g. Tracking Issue for aarch64_unstable_target_feature rust-lang/rust#150244, Tracking Issue for arm_target_feature rust-lang/rust#150246, Tracking Issue for loongarch_target_feature rust-lang/rust#150252, Tracking Issue for riscv_target_feature rust-lang/rust#150257).
  • Used by: Kbuild.
  • Status: unclear. Alternatively, we could use a way to suppress the warning for unknown features + get a promise that all features are disabled by default (so that we can enable the ones we need only). See c5eae3a, 9a9d6ee, Codegen features are no longer recognized by rustc rust-lang/rust#96472 and Direct users towards using Rust target feature names in CLI rust-lang/rust#87402 for context.
  • PR: split up tracking issue for target feature feature gates rust-lang/rust#150264.

• Command-line flags to eventually replace avoid target specification files (target.json), global target features, target modifiers...

  • Tracking Issue (target modifiers): Tracking Issue for target modifiers rust-lang/rust#136966.
  • Used by: Kbuild.
  • Status: the target specification file is fairly tied to LLVM, thus it is unclear if something like it can be ever stabilized. Stabilizing command-line flags appeared to be the likely path forward. In cases where the flag should generally be the same across the entire crate graph, a "global target feature" concept (e.g. -Cglobal-target-feature=) could be useful, i.e. a target feature that is required to be set the same way for all compilation units (without requiring a new target). In other words, using flags to create variations of targets instead of requiring a different for every possible combination (and considering some flags are not just booleans but accept integer values). Then, targets modifiers were introduced for the case where mixing them incorrectly would be unsound. Then, -Zmin-function-alignment used the target modifiers framework, which in the end made us go full circle back into the global target feature, even if not unsound.
  • Tracking Issue (in rust-embedded): Discussion issue for customizable targets rust-embedded/wg#792.
  • Tracking Issue (for all -C flags that may change ABI): Tracking issue for all the ways in which -C compiler flags can alter the ABI rust-lang/rust#131837.
  • RFC: [RFC] Target Modifiers rust-lang/rfcs#3716.
  • PR: Target modifiers (special marked options) are recorded in metainfo rust-lang/rust#133138 (1.86).
  • PR: Explicitly choose x86 softfloat/hardfloat ABI rust-lang/rust#136146 (1.86).
  • Issue: Some sanitizers should be target modifiers rust-lang/rust#138453.
  • PR: Target modifiers fix for bool flags without value rust-lang/rust#138483 (1.87).
  • PR: Sanitizers target modificators rust-lang/rust#138736 (1.91).
  • Cc: @FlyGoat (MIPS, https://lore.kernel.org/rust-for-linux/a6959bc0-f0bb-425b-b3b1-3123d3b809b5@app.fastmail.com/).
  • Zulip (on floating point availability changing and the interaction with target feature 1.1): https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/On.20the.20permanence.20of.20target.20feature.20availability/near/484097374.

• A way to build core with a stable compiler (possibly a subset of -Zbuild-std).

  • Tracking Issue (2025h1 goal): build-std rust-lang/rust-project-goals#274.
  • Used by: Kbuild.
  • Status: build-std context RFC proposed for merge.
  • We do not need to change the source files, and we always build the sysroot core (i.e. the one that comes with the compiler). We only do it because we cannot use the prebuilt builtin ones. Any way to build it (including the current one, i.e. just building it as-is) would be fine for us. There have been discussions about a potential -Zbuild-std flag for rustc, e.g. -Zbuild-std=core (that could also potentially automatically find the source code for the library in the sysroot etc.).
  • RFC (related, Rust for Linux use case mentioned): build-std: context rust-lang/rfcs#3873.
  • RFC (related, Rust for Linux use case mentioned): build-std: always rust-lang/rfcs#3874.
  • Rust 2025H2 project goal: 2025h2: SVE + build-std + rustc-perf-improvements rust-lang/rust-project-goals#331.
  • Rust 2025H1 project goal: Propose build-std as a 2025H1 goal rust-lang/rust-project-goals#158.
  • HackMD: https://hackmd.io/@adamgemmell/rybJRFvdJe.

Nice to have (not critical, we could workaround if needed, etc.)

• feature(asm_goto_with_outputs).

  • Tracking Issue: Tracking Issue for asm_goto_with_outputs rust-lang/rust#119364 (same as asm_goto).
  • PR: Break critical edges in inline asm before code generation rust-lang/rust#138073 (1.87).

• feature(associated_type_defaults).

  • Tracking Issue: Tracking issue for RFC 2532, "Associated type defaults" rust-lang/rust#29661.
  • Used by: TODO comment in the upcoming pci.rs (https://lore.kernel.org/rust-for-linux/20241022213221.2383-12-dakr@kernel.org/), as well as potentially other places (e.g. in the past, file_operations.rs to simplify boilerplate needed by drivers).
  • Status: there is no recent activity in the tracking issue, but we could add back the boilerplate.
  • Lore: https://lore.kernel.org/rust-for-linux/20241022213221.2383-12-dakr@kernel.org/.
  • Lore: https://lore.kernel.org/rust-for-linux/CAJ-ks9=8vm9Ggt2iJRr-QpTN+why5ZbNAzHYRmbDxiBXP4-b4Q@mail.gmail.com/.

• feature(bstr).

  • Tracking Issue: Tracking Issue for ByteStr/ByteString rust-lang/rust#134915.
  • Used by: replacement for our BStr type.
  • Status: added as unstable in 1.86 (Implement ByteStr and ByteString types rust-lang/rust#135073).
  • Rust for Linux issue: Replace kernel::str::BStr with core::bstr::ByteStr #1146.
  • Related PR: Implement Deref<Target=ByteStr> for CStr rust-lang/rust#138498.

• feature(const_trait_impl).

  • Tracking Issue: Tracking issue for closed RFC 2632, impl const Trait for Ty and [const] (conditionally const) syntax (const_trait_impl) rust-lang/rust#67792.
  • Used by: rust/kernel/driver.rs in the past (e.g. see _new_id_array!, define_id_array! and define_id_table! in https://lore.kernel.org/rust-for-linux/20240520172554.182094-3-dakr@redhat.com/).
  • Status: "This RFC has not yet been accepted. It is being implemented on a provisional basis to evaluate the potential fallout.". Moreover, the syntax is undecided/temporary.

• feature(doc_cfg).

  • Tracking Issue: rustdoc: Tracking issue for #[doc(cfg)] and automatically documented #[cfg]s rust-lang/rust#43781.
  • Used by: rust/kernel/lib.rs in our old rust branch.
  • Status: it looks like the feature will get stabilized, although there is still discussions around several bits, e.g. about automatically inferring doc(cfg(...)) from the cfg(...) (to avoid duplication) etc. See also Consider allowing to build docs for the current kernel config #447.

• feature(duration_constants).

  • Tracking Issue: Tracking issue for duration_constants rust-lang/rust#57391.
  • Used by: rust/kernel/delay.rs.
  • Status: the FCP stalled, and there was discussion around other alternatives (e.g. a TimeUnits to do things like 2.seconds()). We can always use our own constants.

• feature(macro_metavar_expr_concat) (modern alternative to the unstable concat_idents! macro).

  • Tracking Issue: Tracking Issue for macro_metavar_expr_concat rust-lang/rust#124225.
  • Used by: eventually, we can replace our own custom concat_idents! proc macro.
  • PR: Add a new concat metavar expr rust-lang/rust#118958 (1.81).

• feature(ptr_alignment_type) or, more generally, a power-of-two type.

  • Tracking Issue: Tracking Issue for ptr::Alignment type rust-lang/rust#102070.
  • Used by: we could potentially replace our potential PowerOfTwo<T> type.
  • Lore: https://lore.kernel.org/rust-for-linux/20250620-num-v1-1-7ec3d3fb06c9@nvidia.com/
  • PR: Add ptr::Alignment type rust-lang/rust#102072 (1.66).

• feature(ptr_metadata) (core::ptr::metadata and core::ptr::from_raw_parts_mut functions).

  • Tracking Issue: Tracking Issue for pointer metadata APIs rust-lang/rust#81513.
  • Used by: Arc in the past (before we switched to byte_sub, i.e. pointer_byte_offsets), and potentially by impl_zeroable! to include pointers to DSTs when their metadata is Zeroable via the Pointee trait.
  • Status: in discussion, design concerns.
  • Alternatives: Tracking Issue for pointer_bytes_offsets rust-lang/rust#96283 (1.75, which we will use soon -- patch at https://lore.kernel.org/rust-for-linux/20240215104601.1267763-1-aliceryhl@google.com/) and Restructure ptr_metadata to minimal support rust-lang/libs-team#111.

• -Zbinary_dep_depinfo=y.

  • Tracking Issue: Tracking issue for -Z binary-dep-depinfo rust-lang/rust#63012.
  • Used by: Kbuild.
  • Status: we could get around it by making the build system more complicated.

• -Zfunction-sections (in rustc, it applies to data too).

  • Tracking Issue: None (it comes from 2014, pre-1.0 rustc: rust-lang/rust@6b130e3).
  • Used by: Makefile (under CONFIG_LD_DEAD_CODE_DATA_ELIMINATION, which is experimental so far).
  • Status: unknown. It would be good to have, especially if the C side starts using it routinely.

• -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/).
  • Status: ?.

• -Zub-checks (cfg(ub_checks)).

  • Tracking Issue: Tracking Issue for feature(cfg_ub_checks) and -Zub-checks rust-lang/rust#123499.
  • Used by: Kbuild.
  • Status: added as unstable in 1.79 (Put checks that detect UB under their own flag below debug_assertions rust-lang/rust#123411). The checks can be enabled via -Cdebug-assertions, but not stabilizing this means one cannot enable/disable each of them independently.

• -Zunpretty=expanded.

  • Tracking Issue: Stabilize -Zunpretty=expanded rust-lang/rust#43364.
  • Used by: developers through Kbuild.
  • Status: no recent progress. It is a feature that should be in stable compilers, but it is not critical for building the kernel (we could use RUSTC_BOOTSTRAP=1 only for the target that uses it, if needed).

• --crate-attr (-Zcrate-attr).

  • Tracking Issue: Tracking Issue for -Z crate-attr rust-lang/rust#138287.
  • Used by: all kernel modules, currently in the -Zcrate-attr form. It could also be used to solve RFC: Custom logo/favicon command-line flags rust-lang/rfcs#3226 as long as the attributes handle the local file case.
  • Status: RFC approved.
  • RFC: RFC: --crate-attr rust-lang/rfcs#3791.
  • PR (-Zcrate-attr): Add the -Zcrate-attr=foo unstable rustc option rust-lang/rust#52355.

Low priority (we will likely not use them in the end)

• feature(pointer_is_aligned) (is_aligned_to).
  • Tracking Issue: Tracking Issue for pointer_is_aligned_to rust-lang/rust#96284.
  • Used by: eventually by FromBytes (VFS abstractions, Use is_aligned_to in FromBytes once it's available #1038).
  • Status: the first half (is_aligned()) got stabilized in 1.79 (stabilize ptr.is_aligned, move ptr.is_aligned_to to a new feature gate rust-lang/rust#121948). is_aligned_to() may be stabilized, but it needs to be justified.

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(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).
  • PR including our VTABLE test case (tests/ui/consts/const-ref-to-static-linux-vtable.rs): 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/.

• -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.