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
• Third-party crates wanted features & bugfixes #1216
• 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
• Linux Kernel Performance tests wanted features & bugfixes #1221
• 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. There is as well feature(arbitrary_self_types_pointers) now (same tracking issue), but may be removed (2026-01-14).
  • 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 raw pointer casts of trait objects rust-lang/rust#141402.
  • derive(CoercePointee) builds on top of this.
  • HackMD: https://hackmd.io/z4n40072Tqy8MhQPZn0N-g.
  • HackMD: https://hackmd.io/-EoW-tn-SAKLfGgdQStPKQ.
  • 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) and a way to avoid certain intrinsics (f32, f64, i128, u128 and 64-bit divisions/modulos).

  • Tracking Issue: internal to the compiler.
  • Used by: Kbuild.
  • We use feature(compiler_builtins) to avoid a dependency.
  • At the moment, we need to define certain panicking intrinsics related to f32, f64, i128, u128 and 64-bit divisions/modulos to be able to link, but we would like to get rid of the workaround.
    • The intrinsics are not provided by the kernel because they are operations that are not supposed to be used (by neither C nor Rust).
    • Regarding the 64-bit divisions/modulos, in Linux, C code explicitly calls a function (rather than use the usual / operator) to perform them, because they are rarely needed and can be very expensive in certain architectures.
  • Ideally, we would have a way to build core (and the rest, if the compiler may still generate the intrinsic calls by itself) in a way that it does not require defining intrinsics.
    • For instance, by not building the code that needs them in core to begin with (e.g. a special flag or cfg that prevents using certain types and avoids generating code for them) or, for the 64-bit divisions/modulos, redirecting them to the custom functions.
    • If calls are redirected, then we would still need a way to prevent Rust code from using the types (e.g. u128) and/or the operators (e.g. /), possibly via a lint, e.g. 64-bit divisions rust-lang/rust-clippy#16509.
  • File: rust/compiler_builtins.rs.
  • File: lib/math/div64.c.
  • Commit: cb7d9de ("rust: compiler_builtins: make stubs non-global").
  • Lore (see patch message and thread): https://lore.kernel.org/all/20260204030507.8203-1-linkmauve@linkmauve.fr/.

• 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 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 (1.92).
  • Issue: derive(CoercePointee) is unsound with user-defined attribute macros. rust-lang/rust#148899.
  • PR: Skip PhantomData in Unsize checks rust-lang/rust#149968.
  • Issue: [ICE]: builtin: no entry found for key rust-lang/rust#153005.
  • 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(field_projections).

  • Tracking Issue: Tracking Issue for Field Projections rust-lang/rust#145383.
  • Used by: many abstractions in the future.
  • 2025H2 project goal: https://rust-lang.github.io/rust-project-goals/2025h2/field-projections.html (Design a language feature to solve Field Projections rust-lang/rust-project-goals#390, Propose goal: Field Projections rust-lang/rust-project-goals#329).
  • RFC: [RFC] field projections v2 rust-lang/rfcs#3735.
  • RFC: RFC: Field projection rust-lang/rfcs#3318.
  • PR: add field_of! macro and field representing types rust-lang/rust#118658.
  • PR: Add field representing types rust-lang/rust#146307.
  • PR: add field representing types rust-lang/rust#152730 (1.96).
  • PR: rustfmt: add test for field representing type builtin syntax rust-lang/rust#153229.
  • Design Meeting: https://hackmd.io/@rust-lang-team/S1I1aEc_lx (Design meeting: Field projections rust-lang/lang-team#335).
  • Field Projection Use Cases HackMD: https://hackmd.io/@BennoLossin/SkSB48hCR.
  • Pre-RFC v3 HackMD: https://hackmd.io/@BennoLossin/HkMBy6Hzlx.
  • Zulip: https://rust-lang.zulipchat.com/#narrow/channel/522311-t-lang.2Fcustom-refs
  • Zulip: https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Field.20Projections/near/474648059.

• 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").
  • PR: Stabilize -Zdebuginfo-compression as -Cdebuginfo-compression rust-lang/rust#150625.

• -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/) and possibly x86 with CONFIG_RELOCATABLE=y in the future (https://rust-for-linux.zulipchat.com/#narrow/channel/288089-General/topic/Builtin.20Rust.20components.20fail.20to.20build.20with.20small.20code.20model/near/565423029).
  • 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.
  • Zulip: https://rust-lang.zulipchat.com/#narrow/channel/425075-rust-for-linux/topic/New.20relocation.20model.20for.20relocatable.20code.20but.20static.20data/near/565584971.
  • PR: Fix dso_local for external statics with linkage rust-lang/rust#150494 (1.94).

• -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.
  • Stabilization PR and report (that triggered the following RFC instead): Stabilize -Zinstrument-mcount rust-lang/rust#152122.
  • RFC (compiler support for instrumenting functions, -Zinstrument-function, #[instrument_fn(entry = "off", exit = "off")]): RFC: Add compiler support for instrumenting functions rust-lang/rfcs#3917.

• -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.
  • Needed for livepatching as well.

• -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: Tracking Issue for target-spec-json (flexible target specifications) rust-lang/rust#151528.
  • Tracking Issue (old): Target specification? rust-lang/wg-cargo-std-aware#6.
  • Tracking Issue (target modifiers): Tracking Issue for target modifiers rust-lang/rust#136966.
  • 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.
  • 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.
  • 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).
  • Issue: De-stabilize target spec JSON  rust-lang/rust#71009.
  • PR: target: fix destabilising target-spec-json rust-lang/rust#151534 (1.95).
  • compiler-builtins PR: add -Zjson-target-spec to custom target workflows rust-lang/compiler-builtins#1071.
  • compiler-team Issue: Destabilise target-spec-json rust-lang/compiler-team#944.
  • Patch: (upcoming after PR).
  • 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(int_lowest_highest_one), i.e. {highest,lowest_one} ({first,last}_set_bit) for integer types.

  • Tracking Issue: Tracking Issue for int_lowest_highest_one rust-lang/rust#145203.
  • Used by: num soon.
  • PR: Implement feature int_lowest_highest_one for integer and NonZero types rust-lang/rust#145381 (1.91).
  • ACP (API Change Proposal): first_set_bit and last_set_bit for integer types rust-lang/libs-team#631.
  • Lore: https://lore.kernel.org/rust-for-linux/DAREXAUV51B6.7X7TPOJKK249@nvidia.com/.
  • Zulip: https://rust-for-linux.zulipchat.com/#narrow/channel/509436-Nova/topic/Work.20on.20numerical.20operations/near/576371467.
  • Cc: @Gnurou.

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

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

Moved to #1223 due to reaching GitHub's 64k character limit on issue text.