Rust unstable features needed for the kernel

[ojeda]

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

See as well:

• Rust 2025H1 flagship project goal: issue, document. In addition, build-std goal: issue, document.
• Rust 2024H2 flagship project goal: issue, goal 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: [WIP] Forbid object lifetime changing pointer casts rust-lang/rust#136776.
  • Issue: Miri build preventing landing changes which require both lib and compiler work rust-lang/rust#138065.
  • 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.

• feature(asm_const) with support for raw pointers.

  • Tracking Issue: Support for pointers with asm_const rust-lang/rust#128464.
  • 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: implemented for LLVM backend, not GCC backend.
  • 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.

• 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: potential soundness issue found when used together with arbitrary_self_types (arbitrary_self_types + derive_coerce_pointee allows calling methods whose where clauses are violated rust-lang/rust#136702), stabilization PR (Stabilize derive(CoercePointee) rust-lang/rust#133820). The kernel will use 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: [WIP] Forbid object lifetime changing pointer casts rust-lang/rust#136776.
  • Issue: Confusing error when using CoercePointee rust-lang/rust#134846.
  • 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).
  • 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.

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

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

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

• -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 #[repr(align(...))] on function items (fn_align) rust-lang/rust#82232.
  • Used by: not yet, but in the C side 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: request for stabilization at -Cmin-function-alignment/-Calign-functions support in rustc rust-lang/rust#128830, stabilization report at Tracking Issue for #[repr(align(...))] on function items (fn_align) rust-lang/rust#82232 (comment), added as unstable in 1.86 (add -Zmin-function-alignment rust-lang/rust#134030).
  • PR: Stabilize fn_align: #[repr(align(N))] on functions and -Zmin-function-alignment rust-lang/rust#140261.
  • 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.

• -Zno-jump-tables.

  • 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: Unknown, but in principle it should be possible to stabilize.
  • 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).

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

• -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).
  • 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/.
  • @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: Tracking Issue for "jump to definition" 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: Tracking issue for rustdoc --output-format=doctest command-line flag rust-lang/rust#134529.
  • Used by: KUnit test generation.
  • Status: discussed on 2024-12-18 on the Rust/Rust for Linux meetings (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): "Consensus was that rustdoc having a json output for doctests would be a good thing that's wanted both by rfl and other rust devtools.". Alona may be able to review if implemented, and Guillaume may be able to implement it.
  • 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).
  • Cc: @GuillaumeGomez, @aDotInTheVoid.
  • Tracking Issue: rustdoc: Tracking issue for --no-run rust-lang/rust#87022.
  • Tracking Issue: Tracking Issue for rustdoc --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)) 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.

• Clippy's configuration.

  • Tracking Issue: ?
  • Used by: Kbuild.
  • Status: RFC-like HackMD posted (https://hackmd.io/@flip1995/By87NXIc1g). 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).
    • 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: https://hackmd.io/@flip1995/By87NXIc1g.
  • 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.
  • 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.

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

  • 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 appears to be the likely path forward. In cases where the flag would change the ABI, a "global target feature" concept (e.g. -Cglobal-target-feature=, target modifiers...) 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 combinations of targets instead of requiring a different for each combination. See -Cfixed-x18 discussion as well.
  • 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.
  • 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 build-std).

  • Tracking Issue: ?
  • Used by: Kbuild.
  • Status: in discussion.
  • 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.).
  • Rust 2025H1 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.)

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

  • Trixie may end up with Rust ~1.83, requested 1.85: https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2024-July/044870.html.
  • It would be reasonable to use that version as a minimum supported version in the kernel for a while.
  • Ideally we would be able to use Edition 2024 too.

• feature(asm_goto_with_outputs).

  • Tracking Issue: Tracking Issue for asm_goto 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.

• 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: Deprecated tracking issue for closed RFC 2632, impl const Trait for Ty and ~const (tilde 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: Tracking issue for #[doc(cfg(…))], #[doc(cfg_hide(…))] and doc_auto_cfg 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(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.

• -Zcrate-attr.

  • Tracking Issue: ? (there is a Add the -Zcrate-attr=foo unstable rustc option rust-lang/rust#52355).
  • Used by: all kernel modules. 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.
  • RFC: RFC: --crate-attr rust-lang/rfcs#3791.
  • Status: unlikely to get stabilized (although in the custom logo RFC it was discussed), but we only use it for convenience.

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

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

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

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

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