Rust wanted features

[ojeda]

Note: there is the "A-rust-for-linux" label in the rust repository: https://github.com/rust-lang/rust/labels/A-rust-for-linux.

Features that we would like to see

Required (we almost certainly want them, even if we may have a workaround in place)

• Support packed types to be aligned or to contain aligned members.

  • RFC: [RFC] Allow packed types to transitively contain aligned types rust-lang/rfcs#3718.
  • Issue: E0587 error on packed and aligned structures from C rust-lang/rust#59154.
  • Issue: #[repr(align(N))] fields not allowed in #[repr(packed(M>=N))] structs rust-lang/rust#100743.
  • And bindgen support for it: bindgen wanted features & bugfixes #353.

• pin-init / placement new / emplacement / in-place initialization / impl Init: better ergonomics than we get with our library solution, perhaps as a language feature.

  • https://rust-for-linux.com/pin-init.
  • https://rust-for-linux.com/the-safe-pinned-initialization-problem.
  • RFC: RFC: Placement by return rust-lang/rfcs#2884.
  • Tracking Issue ("pin ergonomics"): Tracking issue for pin ergonomics rust-lang/rust#130494.
  • Generalized proposal:
    • HackMD: https://hackmd.io/@aliceryhl/BJutRcPblx.
    • Design Meeting: Design meeting: In-place Initialization rust-lang/lang-team#332.
    • Experiment proposal: Experiment proposal: In-place initialization rust-lang/lang-team#336.
  • Via outptrs proposal (out: Uninit<'o, T> output parameters and -> InPlace<'o, T> return types):
    • HackMD: https://hackmd.io/awB-GOYJRlua9Cuc0a3G-Q.
    • Zulip: https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/In-place.20initialization.20via.20outptrs/near/527575530.
    • HackMD: https://hackmd.io/@rust-for-linux-/H11r2RXpgl.
  • Fundamental issue of effects and in-place initialization:
    • HackMD: https://hackmd.io/@BennoLossin/HkBO0_oxbe.
    • Zulip: https://rust-lang.zulipchat.com/#narrow/channel/528918-t-lang.2Fin-place-init/topic/Fundamental.20Issue.20of.20Effects.20and.20In-place-init/with/558268061.
  • Zulip: https://rust-lang.zulipchat.com/#narrow/channel/486433-all-hands-2025/topic/Placement.20new.20in.20Rust/near/518803523.
  • See "Field projections" as well.

• Field projections.

  • Tracking Issue: Tracking Issue for Field Projections rust-lang/rust#145383.
  • 2025H2 project goal: https://rust-lang.github.io/rust-project-goals/2025h2/field-projections.html (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.
  • 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/stream/213817-t-lang/topic/Field.20Projections/near/474648059.

• likely/unlikely-like mechanism.

  • Tracking Issue (likely/unlikely): Tracking Issue for likely_unlikely and cold_path rust-lang/rust#136873.
  • Tracking Issue (meta): Meta tracking issue for branch hints (RFC 1131) rust-lang/rust#26179.
  • Used by: potentially many places (if \((|un)likely\(~23k matches).
  • Status: several candidates being considered: likely/unlikely, #[cold], std::hint::cold_path(), whether weights could be specified...
  • PR (fix for likely/unlikely): Likely unlikely fix rust-lang/rust#120370 (1.84).
  • PR (std::hint::{un,}likely): Reexport likely/unlikely in std::hint rust-lang/rust#133695 (1.86).
  • PR (improve cold_path()): improve cold_path() rust-lang/rust#133852 (1.87).
  • ACP (cold_path()): Export cold_path() in std::hint rust-lang/libs-team#510.

• "Custom prelude": A more general prelude_import feature that allows us to avoid writing boilerplate in every kernel module (i.e. in every crate), e.g. #![no_std], #![feature(...)], use kernel::prelude::*;, etc.

• static_assert.

  • Status: t-libs-api decided to add documentation to assert! on how to do a static assert, in a function and at item level.
  • RFC: Feature Request static asserts rust-lang/rfcs#2790.
  • RFC: Static asserts rust-lang/rfcs#1146.
  • Libs ACP: Add macro static_assert to perform compile-time assertion checking rust-lang/libs-team#325.
  • Related: Allow inline consts to reference generic params rust-lang/rust#96557 (1.62).
  • Related: Lang discussion: Item-level const {} blocks, and const { assert!(...) } rust-lang/lang-team#251.
  • See:

    linux/rust/kernel/static_assert.rs

    Lines 5 to 9 in cae4454

    	/// Static assert (i.e. compile-time assert).
    	///
    	/// Similar to C11 [`_Static_assert`] and C++11 [`static_assert`].
    	///
    	/// The feature may be added to Rust in the future: see [RFC 2790].

• build_assert.

  • Especially a way to improve the error messages, even if it requires compiler support somehow. @nbdd0121 suggests: "One option is to extract debug information (if compiled with that, that is) and to find the call-site".
  • Lore (on the confusing error): https://lore.kernel.org/rust-for-linux/g63h5f3zowy375yutftautqhurflahq3o5nmujbr274c5d7u7u@j5cbqi5aba6k/.
  • Zulip (on the confusing error): https://rust-for-linux.zulipchat.com/#narrow/channel/288089-General/topic/build.20checked.20IoMem.20access/near/501675170.
  • See:

    linux/rust/kernel/build_assert.rs

    Lines 28 to 34 in cae4454

    	/// Asserts that a boolean expression is `true` at compile time.
    	///
    	/// If the condition is evaluated to `false` in const context, `build_assert!`
    	/// will panic. If the compiler or optimizer cannot guarantee the condition will
    	/// be evaluated to `true`, a build error will be triggered.
    	///
    	/// [`static_assert!`] should be preferred to `build_assert!` whenever possible.

• Inline assembly: memory operands support.

  • Needed to write more efficient code, e.g. for reimplementing atomics in the Rust side.
  • See "Memory operands" section in the inline asm RFC: https://rust-lang.github.io/rfcs/2873-inline-asm.html#memory-operands.
  • Lore (status report from @fbq): https://lore.kernel.org/rust-for-linux/Zh6_d1T48qpANoCk@boqun-archlinux/
  • Lore: https://lore.kernel.org/rust-for-linux/ZWdv_jsaDFJxZk7G@Boquns-Mac-mini.home/.
  • Cc: @nbdd0121 @fbq.

• -Coverflow-checks=report (allowing to customize the handler).

  • A new mode that allows to "report and continue" (wrapping), like UBSan and similar tools.
  • It could be useful as an "intermediate" point between just wrapping or a panic.
  • "Reporting" should be customizable via a handler, e.g. the kernel could map it to WARN*() (which could still panic depending on panic_on_warn).
  • We should ideally be able to support ONCE variants, i.e. being able to warn once per call site.
  • Ideally we should be able to customize the behavior, e.g. choosing saturation instead of wrapping.
  • RFC (possible first step): [RFC] externally implementable functions rust-lang/rfcs#3632.
  • RFC (alternative possible first step): Externally implementable traits rust-lang/rfcs#3645.
  • 2025H1 project goal: Add project goal: Externally Implemtable Items (EII) rust-lang/rust-project-goals#198.
  • Cc: @m-ou-se.
  • Lore (ktime_t): https://lore.kernel.org/rust-for-linux/CANiq72nGHhgRjfMOhz=ss51q2egHYexPMVvWTr0RES9WAmMF=A@mail.gmail.com/. In particular, Thomas Gleixner says a warning may be appropriate, but not a panic.

• UnsafePinned (feature(unsafe_pinned)).

  • Used by: Opaque (currently !Unpin via PhantomPinned, which is what gives us the ability to have aliased mutable references to those), which in turn is used everywhere.
  • Tracking Issue: Tracking Issue for RFC 3467: UnsafePinned rust-lang/rust#125735.
  • RFC: UnsafePinned: allow aliasing of pinned mutable references rust-lang/rfcs#3467.
  • PR: Initial UnsafePinned implementation [Part 1: Libs] rust-lang/rust#137043 (1.88).
  • PR: Initial UnsafePinned implementation [Part 2: Lowering] rust-lang/rust#139896 (?).
  • PR (at least noalias): ... (?).

• Bitfield support, including whatever is needed to describe existing C ones in bindgen's output.

  • RFC: Add bitfields support rust-lang/rfcs#3113.

• unsafe macros.

  • Marking macros as unsafe explicitly, so that unsafe is required to call then, and so that Clippy and other tooling can lint based on that (e.g. requiring # Safety sections and // SAFETY: comments).
  • Note: this is not about treating all macros as unsafe (Rust wanted features #354 (comment)).
  • UCG issue: Safety/soundness of macros rust-lang/unsafe-code-guidelines#278.
  • Possibly via macros 2.0: Tracking issue: declarative macros 2.0 rust-lang/rust#39412.

• fn_cast!.

  • i.e. a function item transmute, but when KCFI is enabled, uses a trampoline that transmutes the arguments.
  • Issue: fn_cast! macro rust-lang/rust#140803.
  • Status: waiting on lang experiment.
  • Background: Can CFI be made compatible with type erasure schemes? rust-lang/rust#128728.

• Improving safety comments maintenance / Rust Safety Standard.

  • @y86-dev's approach ("Rust Safety Standard"):
    • Kangrejos: https://kangrejos.com/2024/Rust%20Safety%20Standard.pdf.
    • Lore: https://lore.kernel.org/rust-for-linux/20240717221133.459589-1-benno.lossin@proton.me/.
  • HackMD ("Automated checking of unsafe code requirements"): https://hackmd.io/@predrag/ByVBjIWlyx.
  • Zulip: https://rust-lang.zulipchat.com/#narrow/channel/486433-all-hands-2025/topic/Naming.20safety.20requirements.20.26.20invariants/near/518801980.
  • tag-std:
    • https://github.com/Artisan-Lab/tag-std.
    • Issue: Support safety attributes in Rust for Linux Artisan-Lab/tag-std#3.

• Equivalent of the upcoming Clang kcfi_salt C attribute.

  • Lore: https://lore.kernel.org/lkml/CABCJKufPphD3en91N89yekUam4Nv7+C7YPJMv7h2SmZcyhGhdA@mail.gmail.com/.
  • PR (LLVM): [Clang][attr] Add 'cfi_salt' attribute llvm/llvm-project#141846.

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

• A way to easily export in the prelude macros generated by macros.

  • Related: resolve: Modularize crate-local #[macro_export] macro_rules rust-lang/rust#52234.

• -masm= equivalent (i.e. the ability to configure the assembly syntax default).

  • The kernel uses the AT&T syntax and thus our asm! blocks will need options(att_syntax).
  • As a workaround, a macro that expands to asm! with the option set should be fairly straightforward (Experimental tracepoint support #1084 (comment)).
  • Users Forum: https://users.rust-lang.org/t/macro-for-att-syntax-asm/115675.
  • However, having a flag (or similar) that sets the default would be ideal (possibly allowing options(intel_syntax) in the other case).

• Support in asm! for several string literals.

  • i.e. allow core::arch::asm!("" "");.
  • We use some #defines to reuse assembly in both C and Rust (RSCPP Kbuild rule), and GCC/Clang allow e.g. asm("" "");, thus it is easiest if Rust's asm! allows it as well.
  • Our workaround is to wrap it with ::kernel::concat_literals!(...).
  • Comparison: https://godbolt.org/z/E8jsPT79Y.
  • Zulip: https://rust-lang.zulipchat.com/#narrow/stream/425075-rust-for-linux/topic/asm-goto.20stabilization/near/457365566.
    Amanieu says:

    We specifically designed asm! to work well with rustfmt, where each line can be comma-separated and appear on a different line after formatting. For concatenation within a line, we intentionally chose to make users use concat!.

    Which allows for things like this where you can add coments on individual lines of inline assembly code.

• #[may_dangle].

  • To give some of our types, like our custom Arc, the same abilities as the standard library's.
  • Tracking Issue: #[may_dangle], a refined dropck escape hatch (tracking issue for RFC 1327) rust-lang/rust#34761.

• Extern types (extern { type S; }).

  • Tracking Issue: Tracking issue for RFC 1861: Extern types rust-lang/rust#43467.
  • We could replace some uses of Opaque<T>: Opaque<T> carries a T (it is MaybeUninit + UnsafeCell + PhantomPinned), but in some use cases we just have them behind a pointer, and thus we would like just a pointer to an actually opaque type, which would prevent e.g. calling mem::swap on them.
  • bindgen could also use the functionality instead of the current recommended workaround in its generated code. In addition, bindgen could perhaps be passed a list of types that should be handled as extern types on purpose, rather than provide the full definition even if available.
  • RFC: extern types rust-lang/rfcs#1861.
  • Blocked on: extern type cannot support size_of_val and align_of_val rust-lang/rust#49708.
  • Related (requires extern types and provides a way to solve the blocker above): Hierarchy of Sized traits rust-lang/rfcs#3729.

• Support more than just integer literals (e.g. const) in attributes like repr(align(...)).

  • e.g. we get const PAGE_SIZE: usize = 4096; from bindgen, and ideally we would be able to do #[repr(align(PAGE_SIZE))] struct S;.
  • Lore: https://lore.kernel.org/rust-for-linux/20241119112408.779243-3-abdiel.janulgue@gmail.com/.

• Leveraging the same magic Box has.

  • The kernel has its own alloc module with our own KBox, KVec etc.
  • UCG: What are the uniqueness guarantees of Box and Vec? rust-lang/unsafe-code-guidelines#326.
  • RFC: RFC: No (opsem) Magic Boxes rust-lang/rfcs#3712.

• Pattern types (ranges, bounded integers, type constraints...).

  • Tracking Issue: Tracking Issue for pattern types rust-lang/rust#123646.
  • We often have cases where it would be nice to statically know/restrict/guarantee allowed set of values on integers, be it a range or other constraints like Alignment and generic PowerOfTwo.
  • Lore: https://lore.kernel.org/rust-for-linux/DD5D59FH4JTT.2G5WEXF3RBCQJ@nvidia.com/.

Discussion needed

• Will &mut T be always treated as *mut T for !Unpin types?

  • Currently this is the case: https://github.com/rust-lang/rust/blob/1c988cfa0b7f4d3bc5b1cb40dc5002f5adbfb9ad/compiler/rustc_middle/src/ty/layout.rs#L2497-L2500.
  • Issue: Resolve unsound interaction between noalias and self-referential data (incl. generators, async fn) rust-lang/rust#63818.
  • Used in: rust/kernel/kasync/net.rs.

• Some feature to help with partial borrowing, e.g. "view types".

• A way to prove blocks of code / functions do not panic / disabling panics locally (or in a TU) / linting / PANIC: enforced comments...

  • Potentially useful, depending on the details. The kernel is (currently) unconditionally -Cpanic=abort.
  • Issue: no-panic as a language feature rust-lang/project-error-handling#49.
  • Upstream Rust open to discussion and even a potential project goal for 2026H1: https://hackmd.io/BKtSH2Q_Q8ePDZ5-RJA7-A.
  • Related: "-Coverflow-checks=report (allowing to customize the handler)".
  • Lore (on overflow and no panics): https://lore.kernel.org/rust-for-linux/CANiq72=nGbziZCKt=AneE_vXw76i=+td0dSVfbOJ8kJ9eYHw9w@mail.gmail.com/
  • Lore (on unwrap Clippy lints): https://lore.kernel.org/rust-for-linux/CANiq72nJiJ4K6jy17x-YRYnJpjqTnohYWvoFrLkYQp0X4tLL=w@mail.gmail.com/
  • Lore (on panics from debug assertions triggered from user interaction being a CVE): https://lore.kernel.org/rust-for-linux/CANiq72nAagBBPhyU3XdETMKBuFPbMMRaSTStWPpyLnByYPP=+A@mail.gmail.com/

• Disabling particular unsafe precondition checks under -Cdebug-assertions=y.

  • The kernel is always compiled with high levels of optimizations (currently either -O2 or -Os) and we provide the option to enable debug assertions in Kconfig.

  • Since Toggle assert_unsafe_precondition in codegen instead of expansion rust-lang/rust#120594 (1.78), -Cdebug-assertions=y will always check all unsafe preconditions, without a way to opt-out for particular cases (e.g. previously one could write a unreachable_unchecked for a fallible API even if the unchecked version of the API had a debug_assert, but now that is always checked), which can have a fairly big impact in runtime (due to branches/calls, which in turn makes the compiler not be able to apply other optimizations too in certain cases currently).

  • Since Put checks that detect UB under their own flag below debug_assertions rust-lang/rust#123411 (1.79), there is a new flag, -Zub-checks (Tracking Issue for feature(cfg_ub_checks) and -Zub-checks rust-lang/rust#123499), which inherits the default from -Cdebug-assertions (similar to -Coverflow-checks). This helps, but there is still no way to selectively disable particular cases.

  • At the moment we are not aware of tests or use cases requiring particular performance targets for those builds in the Rust side, but it is possible that at some point they may come, or that we may need to optimize certain hot parts to keep the debug builds reasonably fast.

  • Thus it would be ideal to have a way to selectively disable certain checks per-call site (i.e. not just per check but for particular instances of a check), even if the vast majority of the checks remain in place.

  • Try enabling precondition checks on ptr::{read,write} rust-lang/rust#129498 introduces the #[rustc_no_ubchecks] attribute, @saethlin says in Disabling particular unsafe precondition checks under -Cdebug-assertions=y rust-lang/rust#120969 (comment):

    In #129498 I'm experimenting with ways to get the precondition checks for ptr::{read,write} enabled. One of the things I'm trying is inventing an attribute currently called #[rustc_no_ubchecks] which makes the MIR optimization pipeline delete checks that got inlined into the body of the indicated function. I don't think this idea is particularly good or possible to stabilize, but it is easy to implement. If it lands, it would be a thing for RFL to play around with, just in case you happen to find a use for it.

    This could probably be easily extended to (again) a crude general mechanism by putting the attribute on a closure to disable checks in a few lines of code instead of "a whole function". If the inliner cooperates.

  • Kept in this list since a solution could involve several aspects of Rust (compiler/language/library).

  • Issue: Disabling particular unsafe precondition checks under -Cdebug-assertions=y rust-lang/rust#120969.

  • Tracking Issue for "things to do after Toggle assert_unsafe_precondition in codegen instead of expansion rust-lang/rust#120594": Totally-not-a-tracking-issue for UB-detecting debug assertions in the standard library rust-lang/rust#120848.

• Communication between the Rust and C (LKMM) memory models.

  • Issue: Memory ordering model policy/plan #1067.
  • UCG Issue: Document the current recommendation when Rust is used to communicate with a different memory ordering model rust-lang/unsafe-code-guidelines#476 (comment).
  • UCG Issue: What about: mixed-size atomic accesses rust-lang/unsafe-code-guidelines#345.
  • UCG Issue: How can we allow read-read races between atomic and non-atomic accesses? rust-lang/unsafe-code-guidelines#483.
  • Zulip: https://rust-lang.zulipchat.com/#narrow/stream/136281-t-opsem/topic/.E2.9C.94.20Rust.20and.20the.20Linux.20Kernel.20Memory.20Model/near/422047924 (in turn from https://rust-lang.zulipchat.com/#narrow/stream/136281-t-opsem/topic/Volatile.20implies.20atomic.3F/near/418403842).
  • 2024-03-22 23:38 [WIP 0/3] Memory model and atomic API in Rust:
    • Lore: https://lore.kernel.org/rust-for-linux/20240322233838.868874-1-boqun.feng@gmail.com/
    • Rust Zulip: https://rust-lang.zulipchat.com/#narrow/stream/136281-t-opsem/topic/Memory.20model.20discussion.20on.20LKML/near/429590163
    • LWN: https://lwn.net/Articles/967049/
  • RFC: [RFC] AtomicPerByte (aka "atomic memcpy") rust-lang/rfcs#3301.
  • Lore: https://lore.kernel.org/rust-for-linux/ae8ac31f-c6ad-46ae-80dd-10ec081a16d1@ralfj.de/
  • Cc: @fbq @RalfJung.

• A solution for updating the kernel (e.g. fixing a bug in core) without forcing recompilation of loadable/out-of-tree Rust modules.

  • Likely useful for some downstream, out-of-tree users, but unclear how many cases could avoid recompilation.
  • Generics are the main issue. Could generics be "instantiated" for some well-known types, to reduce the cases where a recompilation may be needed?
  • #[inline] code as well, though that could be perhaps disabled (ideally still allowing inlining in-tree, but providing the symbol for out-of-tree modules).
  • An initial solution for non-generics could be RFC: #[export] (dynamically linked crates) rust-lang/rfcs#3435 together with Tracking Issue for the experimental crabi ABI rust-lang/rust#111423. See [2025H1] Research: How to achieve safety when linking separately compiled code rust-lang/rust-project-goals#155 as well.

• A solution for getting unique/stable function pointers to "generic callbacks" like devres_callback<T>().

  • Rust Zulip: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Linux.20kernel.3A.20duplicate.20function.20definition/near/438391087.
  • Zulip: https://rust-for-linux.zulipchat.com/#narrow/stream/415254-DRM/topic/Duplicate.20symbols/near/438026564.

• Improved C interop/support.

  • i.e. the ability to import and use C headers directly in Rust / integrated bindgen/cbindgen support, accepting GNU/Clang-like flags, etc.
  • These topics have been a recurrent topic of discussion in Rust for Linux over the years. Any improvement here would be helpful/welcome for the kernel integration.
  • Potential "2024 Rust project goal": https://rust-lang.github.io/rust-project-goals/2024h2/Seamless-C-Support.html (PR: Add two draft project goals: seamless C support, and relaxing the orphan rule rust-lang/rust-project-goals#3).

• Relaxing the orphan rule.

  • Tracking Issue: experiment with relaxing the orphan rule rust-lang/rust#136979.

  • In the kernel, internal APIs are not stable (https://docs.kernel.org/process/stable-api-nonsense.html): any changes are required to fix users/callers as needed. Out-of-tree modules are expected to follow and change as needed too. Therefore, it makes sense to relax the orphan rule within the kernel.

    [ I asked @bjorn3 about this idea in 2022, and he suggested introducing "coherence domains", which we then discussed later on with @nbdd0121 et al.: "One option would be to introduce a concept of coherence domains whereby all crates in a coherence domain are considered as a monolithic whole with respect to the coherence rules. The standard library could then have a coherence domain and the kernel code could have another coherence domain.". It could possibly be useful for other multi-crate/workspace projects as well. ]

  • Potential "2024 Rust project goal": https://rust-lang.github.io/rust-project-goals/2024h2/Relaxing-the-Orphan-Rule.html (PR: Add two draft project goals: seamless C support, and relaxing the orphan rule rust-lang/rust-project-goals#3).

  • Internals: https://internals.rust-lang.org/t/limited-opt-out-of-orphan-rule/21709.

  • Zulip: https://rust-lang.zulipchat.com/#narrow/channel/425075-rust-for-linux/topic/Relaxing.20the.20orphan.20rule/near/483578919.

  • Related: Tracking issue for fundamental feature rust-lang/rust#29635.

  • Internals: https://internals.rust-lang.org/t/pre-rfc-make-orphan-rule-stricter-for-trait/23561.

• Numerical comparisons in conditional compilation.

  • For instance: #[cfg(CONFIG_RUSTC_VERSION >= 107900)].
    • For some cases, #[cfg(version(...))] or #[cfg(accessible(...))] may be alternatives (cfg(version(...)) was finally decided to return true when matching against nightly (by default, i.e. unless -Zassume-incomplete-release is given), which is generally what we want, since we would expect developers to use the latest nightlies only).
    • Tracking Issue: Tracking issue for RFC 2523, #[cfg(version(..))] rust-lang/rust#64796.
    • Tracking Issue: Tracking issue for RFC 2523, #[cfg(accessible(::path::to::thing))] rust-lang/rust#64797.
    • Stabilization PR: Stabilize #[cfg(version(...))] rust-lang/rust#141137.
  • We can workaround it by defining cfgs on the fly for each condition/feature/etc. via Kconfig.
  • Internals: https://internals.rust-lang.org/t/conditional-compilation-const-ord/16191.

• A better way to handle cfg conditionals, such as the upcoming cfg_select! upstream.

  • Tracking Issue: Tracking issue for cfg_select (formerly cfg_match) rust-lang/rust#115585.
  • Issue: add if_cfg! macro #1183.

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

• A way to elegantly handle "noop conditional compilation wrappers".

  • Marking callers does not scale -- the C side uses these wrappers to restrict conditional compilation to headers/callees as much as possible.
  • See e.g. rust: kernel: support !CONFIG_PRINTK #669.

• quote as part of the freestanding standard library.

  • Tracking Issue: Tracking issue for the quote! macro in proc_macro rust-lang/rust#54722.

• syn as part of the freestanding standard library.

  • Even if it only covers a subset of the syntax, older versions of the syntax or uses "unknown" nodes.

• feature(min_specialization).

  • From: https://rust-for-linux.zulipchat.com/#narrow/stream/288089-General/topic/.60Arc.60.20and.20.60ARef.60.
  • Tracking Issue: Tracking issue for specialization (RFC 1210) rust-lang/rust#31844.
  • Used by: nothing yet (which is why it is in this list), but potentially in Arc.
  • Status: while full specialization is unsound, min_specialization may be sound. We would only want to allow it for Arc, rather than subsystems in general. Nevertheless, it is very tricky to use properly at the time ("even rustc devs mess up with min_specialization."). In addition, there are bugs remaining, e.g. just enabling min_specialization is currently unsound on its own (With min_specialization enabled, an incomplete impl for a non-static type will delegate method calls to a less-specific impl with a 'static bound rust-lang/rust#79457).

Done (stabilized, fixed, not needed anymore, etc.)

• Remove the need for defining __rust_* methods.

  • Issue: Investigate why no GlobalAlloc-related symbols are generated #68.
  • PR: Support #[global_allocator] without the allocator shim rust-lang/rust#86844 (1.71).

• feature(let_else).

  • Moved into the main list, since it got implemented, we started to use it, and it got stabilized.

• feature(const_refs_to_static) & feature(const_refs_to_static).

  • Moved into the main list since our use case was implemented.

• feature(lint_reasons).

  • Moved to the main lint, since it was stabilized and we started using it since v6.13.

• Inline assembly: asm goto support (feature(asm_goto)).

  • Moved into the main list since it got implemented.

• Allow #[repr(Rust)].

  • Useful to be explicit about particular cases that would normally need e.g. the C representation, such as silencing Lint against #[no_mangle] for non-repr(C) pub statics rust-lang/rust-clippy#11219 (see Clippy's list).
  • PR: Allow explicit #[repr(Rust)] rust-lang/rust#114201 (1.74).

• assume-like mechanism (core::hint::assert_unchecked).

  • Tracking Issue: Tracking Issue for hint::assert_unchecked rust-lang/rust#119131.
  • Status: getting stabilized Stabilize hint::assert_unchecked rust-lang/rust#123588 (1.81).

• Make unsafe_op_in_unsafe_fn the default dialect in a future edition.

  • Issue: Tracking Issue for "unsafe blocks in unsafe fn" (RFC #2585) rust-lang/rust#71668.
  • Our feedback: Tracking Issue for "unsafe blocks in unsafe fn" (RFC #2585) rust-lang/rust#71668 (comment).
  • FCP for warn-by-default in 2024: Tracking Issue for "unsafe blocks in unsafe fn" (RFC #2585) rust-lang/rust#71668 (comment).
  • PR: Change unsafe_op_in_unsafe_fn to be warn-by-default from edition 2024 rust-lang/rust#112038.
  • PR: Add MVP suggestion for unsafe_op_in_unsafe_fn rust-lang/rust#112017.

• Naked functions.

  • Tracking Issue: Tracking Issue for RFC #2972: Constrained Naked Functions  rust-lang/rust#90957.
  • PR: Stabilize naked_functions rust-lang/rust#134213 (1.88).

[nbdd0121]

Unicode support is baked into str (which is a primitive type), so it's pretty hard if not impossible to disable them.

As for Futures, there is a skeleton there, and there is no need to disable it (it doesn't depend on compiler intrinsics anyway). We might possibly even want to use Future in the future (no pun intended) for networking etc.

I think we probably only need an option to disable fp support libraries and maybe 128-bit integer types.

[bjorn3]

Unicode support is baked into str (which is a primitive type), so it's pretty hard if not impossible to disable them.

You can still remove all methods on &str or only those needing unicode tables.

[alex]

Now that static_assert! is const _: () = assert!(...); should we consider static assertions to be done?

[wrenger]

It depends on whether we want the full debug format functionality used by assert_eq! and their like (1.57.0#panic-in-const-contexts).