You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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: 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.
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.
Used by: in the future, potentially many places (if \((|un)likely\(~23k matches).
Status: stabilized (std::hint::cold_path()) in 1.95. Several other proposals being considered: likely/unlikely, #[cold], whether weights could be specified...
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).
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).
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.
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
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.
This is the "Done" section from #2, moved here due to reaching GitHub's 64k character limit on issue text.
Done (stabilized, not needed anymore, etc.)
As many required bits done in the Rust version of the upcoming Debian Stable (Trixie).
--check-cfg.--check-cfgoption rust-lang/rust#123501).cfgs): Limit the number of names and values in check-cfg diagnostics rust-lang/rust#121202 (1.78).CARGO_CRATE_NAMEinstead ofCARGOas a better heuristic for Cargo diagnostics): Use better heuristic for printing Cargo specific diagnostics rust-lang/rust#121237 (1.78).--extern force:.--extern forcerust-lang/rust#111302.allocextern to allow "empty" Rust files")), but not anymore since v6.13 due to the allocator series landing (commit 392e34b ("kbuild: rust: remove thealloccrate andGlobalAlloc")).new_uninitis dropped. There may be other workarounds. Added as unstable in 1.71 (Addforceoption for--externflag rust-lang/rust#109421).cfg(no_global_oom_handling).alloc) in the past, but not anymore since v6.13 due to the allocator series landing.cfg(no_rc).alloc) in the past, but not anymore since v6.13 due to the allocator series landing.alloc: add unstable cfg featuresno_rcandno_syncrust-lang/rust#89891).cfg(no_sync).alloc) in the past, but not anymore since v6.13 due to the allocator series landing.alloc: add unstable cfg featuresno_rcandno_syncrust-lang/rust#89891).feature(allocator_api).alloccrate anymore: in Linux v6.13, Linux started using its ownallocmodule instead of the Rust standard libraryalloccrate; and in Linux v6.10, Linux removed its custom fork of the Rust standard libraryalloccrate.feature(alloc_error_handler).no_global_oom_handling.feature(asm_const).asm_construst-lang/rust#128570).asm_construst-lang/rust#128464.feature(asm_goto).asm_gotofeature gate rust-lang/rust#133870).asm!rust-lang/rust#119365 (1.78).asmgoto should default to safe rust-lang/rust#132078.feature(asm_goto_with_outputs)in order to stabilizefeature(asm_goto)sooner): Fix asm goto with outputs and move it to a separate feature gate rust-lang/rust#131523 (1.85).-O0llvm/llvm-project#110251.asm_gotofeature gate rust-lang/rust#134860.feature(bench_black_box).std::hint::black_boxrust-lang/rust#64102.samples/rust/rust_stack_probing.rs.feature(box_uninit_write).box_uninit_writerust-lang/rust#129397.unsafeblock inBox<T>::new()(BoxExt), but not anymore since v6.13 due to the allocator series landing.feature(c_size_t)# rust-lang/rust#88345.rust/kernel/file.rsin our oldrustbranch (so far, but could be anywhere in the abstractions).core_ffi_cgot stabilized in 1.64 (Stabilizecore::ffi:c_*and re-export instd::ffirust-lang/rust#98315) andc_{s,}size_tare now incore::ffisince 1.61 (Provide C FFI types via core::ffi, not just in std rust-lang/rust#94503).feature(coerce_unsized)&feature(unsize)(core::ops::CoerceUnsizedandcore::marker::Unsizetraits).Arc.feature(derive_smart_pointer)instead to avoid depending onArc's needed features; otherwise: "theCoerceUnsizedtrait is unstable and we wish to revisit its design before stabilizing, so for now only stdlib types can be unsized" + there are unsoundness issues, seePinis unsound due to transitive effects ofCoerceUnsizedrust-lang/rust#68015 and APinunsoundness involving animpl DerefMut for Pin<&dyn LocalTrait>rust-lang/rust#85099. See https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/rust-for-linux.20custom.20arc.20unstable.20feature.20requirements.feature(cold_path).core::hint::{cold_path}): Tracking Issue forcold_pathrust-lang/rust#136873.core::hint::{likely, unlikely}): Tracking Issue forlikely_unlikelyrust-lang/rust#151619.if \((|un)likely\(~23k matches).std::hint::cold_path()) in 1.95. Several other proposals being considered:likely/unlikely,#[cold], whether weights could be specified...likely/unlikely): Likely unlikely fix rust-lang/rust#120370 (1.84).std::hint::{un,}likely): Reexport likely/unlikely in std::hint rust-lang/rust#133695 (1.86).cold_path()): improve cold_path() rust-lang/rust#133852 (1.87).cold_path()): Stabilizecore::hint::cold_pathrust-lang/rust#151576 (1.95).cold_path,likely, andunlikelyrust-lang/rust#151612 (1.95).cold_path()): Export cold_path() in std::hint rust-lang/libs-team#510.feature(concat_idents).concat_identsrust-lang/rust#29599.drivers/android/defs.rsin the past, nothing now.pastecrate is an alternative (or, in general, generating code). We ended up using a proc macro on our side Re-implement concat_idents! in libmacros #826. It was removed in 1.90 (Remove the deprecated unstableconcat_idents!macro rust-lang/rust#142704).feature(const_fn_transmute).rust/kernel/str.rs.const_fn_transmute,const_fn_unionrust-lang/rust#85769). It is one of the subfeatures ofconst_fn.feature(const_fn_trait_bound).const fnrust-lang/rust#57563.rust/kernel/file_operations.rsandrust/kernel/module_param.rs.const_fn.feature(const_maybe_uninit_as_mut_ptr).rust/kernel/device_id.rs. https://lore.kernel.org/rust-for-linux/20241022213221.2383-6-dakr@kernel.org/#iZ31rust:kernel:lib.rsMaybeUninit::as_mut_ptrrust-lang/rust#130542).feature(const_maybe_uninit_zeroed).const_maybe_uninit_zeroedrust-lang/rust#91850.const_maybe_uninit_zeroedandconst_mem_zeroedrust-lang/rust#116218).feature(const_mut_refs)&feature(const_refs_to_static).&mut Tin const contexts (const_mut_refs) rust-lang/rust#57349 and Tracking Issue for const_refs_to_static rust-lang/rust#119618.const TABLEs (settingownerfield toTHIS_MODULE), as well asrust/kernel/module_param.rs(in therustbranch).const_mut_refsstabilized 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_staticstabilized in 1.82 (Stabilizeconst_refs_to_staticrust-lang/rust#129759). It is one of the subfeatures ofconst_fn.linux-vtabletest case upstream: https://github.com/rust-lang/rust/blob/main/tests/ui/consts/const-ref-to-static-linux-vtable.rs. PR adding it: const_mut_refs: allow mutable pointers to statics rust-lang/rust#120932 (1.78).feature(const_panic).rust/kernel/print.rs.const_panicrust-lang/rust#89508). It is one of the subfeatures ofconst_fn.feature(const_ptr_offset_from).rust/kernel/driver.rs.const_ptr_offset_from. rust-lang/rust#96240).feature(const_ptr_write).rust/kernel/device_id.rs. https://lore.kernel.org/rust-for-linux/20241022213221.2383-6-dakr@kernel.org/#iZ31rust:kernel:lib.rsptr::write*andmem::replacerust-lang/rust#130954).feature(const_raw_ptr_deref)rust/kernel/str.rs.const_fn_transmutesince that was getting stabilized sooner.feature(const_refs_to_cell).const_refs_to_cellrust-lang/rust#80384.rust/kernel/driver.rs,offset_of!(iffeature(offset_of)does not pan out).&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).unreachable_uncheckedrust-lang/rust#53188.rust/kernel/str.rs.unreachable_uncheckedasconst fnrust-lang/rust#89509). It is one of the subfeatures ofconst_fn.feature(core_ffi_c)module!, etc.core::ffi:c_*and re-export instd::ffirust-lang/rust#98315).feature(core_panic).rust/build_assert.rs.panic!("{}", msg)(2021 edition, allowed in const context since Allowpanic!("{}", computed_str)in const fn. rust-lang/rust#88954).feature(dispatch_from_dyn)(core::ops::DispatchFromDyntrait).Arc.feature(derive_smart_pointer)instead to avoid depending onArc's needed features; otherwise: see https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/rust-for-linux.20custom.20arc.20unstable.20feature.20requirements.DispatchFromDynrules allowing non-PhantomDataZSTs in additional fields is unsound rust-lang/rust#135220.feature(explicit_generic_args_with_impl_trait)explicit_generic_args_with_impl_traitrust-lang/rust#83701.pinned-init.feature(exposed_provenance).feature(strict_provenance)).feature(strict_provenance)as well.feature(extract_if).rust/macros/kunit.rs.feature(drain_filter)in 1.72 (Don't drain-on-drop in DrainFilter impls of various collections. rust-lang/rust#104455).feature(file_with_nul)(C string equivalents (nul-terminated) forcore::panic::Location(or a flag to ensure there is a\0after thestrs)).#[track_caller]rust-lang/rust#141727.kernel::file_from_location(https://lore.kernel.org/rust-for-linux/20250619151007.61767-2-boqun.feng@gmail.com/) for#[track_caller]s likekernel::task::might_sleep().std::panic::Location::file_as_c_strrust-lang/rust#145664), added as unstable in 1.89 (Add Location::file_with_nul rust-lang/rust#135054).core::panic::Location::filerust-lang/libs-team#466 (accepted).core::panic::Locationfile strings rust-lang/rust#117431.#[track_caller]rust-lang/rust#142579.Location::file_with_nultofile_as_c_strrust-lang/rust#145928 (1.91).std::panic::Location::file_as_c_strrust-lang/rust#145664 (1.92).feature(generic_associated_types).rust/kernel/types.rs(PointerWrapper),rust/kernel/file_operations.rs(IoctlHandler).feature(global_asm).rust/module.rsproc macro.module.rs, use codegen instead #77.feature(impl_trait_in_assoc_type).rnullin the past (https://lore.kernel.org/rust-for-linux/20240313110515.70088-5-nmi@metaspace.dk/), but not anymore.feature(inline_const).rust/kernel/lib.rs.feature(int_lowest_highest_one), i.e.{highest,lowest_one}({first,last}_set_bit) for integer types.int_lowest_highest_onerust-lang/rust#145203.numsoon.int_lowest_highest_onerust-lang/rust#155147), added as unstable in 1.91 (Implement featureint_lowest_highest_onefor integer and NonZero types rust-lang/rust#145381).int_lowest_highest_onefor integer and NonZero types rust-lang/rust#145381 (1.91).int_lowest_highest_onerust-lang/rust#155147 (1.97).first_set_bitandlast_set_bitfor integer types rust-lang/libs-team#631.feature(let_else).let_elsehelps naturally with that (when applicable).rust/macros/paste.rsand potentially everywhere.let elserust-lang/rust#93628).feature(lint_reasons).#[expect]attribute. This feature already helped to discover that-Wclippy::dbg_macrowas not being applied in the kernel, which triggered Customdbg!macros fordbg_macrolint rust-lang/rust-clippy#11303.#[expect(...)]attribute").#[expect]some lints: Stabilizelint_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 thedead_codelint 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.#[expect]attribute andreasonsparameter (RFC 2383) rust-lang/reference#1237.feature(maybe_uninit_extra).#![feature(maybe_uninit_extra,const_maybe_uninit_write)]rust-lang/rust#63567.rust/kernel/miscdev.rs.maybe_uninit_extrarust-lang/rust#92768) (non-const only, which is the only part we need).feature(more_fallible_allocation_methods).more_fallible_allocation_methodsrust-lang/rust#86942.allocin the past, but not anymore.feature(new_uninit).pin-initAPI in the past, but not anymore since v6.13 due to the allocator series landing.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 anunsafeblock, but it was replaced for the time being) andnew_zeroed_alloc.feature(non_null_convenience).NonNullrust-lang/rust#117691.rust/kernel/alloc/allocator/iter.rs.non_null_conveniencerust-lang/rust#124498).non_null_conveniencerust-lang/rust#124498 (1.80).feature(offset_of)(single-field, i.e. noenum, no nested).#![feature(offset_of)]rust-lang/rust#106655.rust/kernel/workqueue.rsandkernel/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).feature(offset_of_nested).feature(pin_macro).core::pin::pin!rust-lang/rust#93178.stack_pin_init!andstack_try_pin_init!.::{core,std}::pin::pin!rust-lang/rust#103800).feature(proc_macro_span_file)(i.e. onlyproc_macro::Span::{file, local_file}fromfeature(proc_macro_span)).proc_macro::Spaninspection APIs rust-lang/rust#54725.#[test]s (likely in v6.15+).feature(raw_ref_op).&raw [mut | const] $place(raw_ref_op) rust-lang/rust#64490.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::Receivertrait).Arc.feature(arbitrary_self_types)in v6.12.feature(slice_flatten).slice_flattenrust-lang/rust#95629.slice_flattenrust-lang/rust#125561) -- already stable when we started, but we still support 1.78.feature(slice_ptr_len).feature(split_at_checked).rust/kernel/transmute.rs(but we started after bumping the minimum, even if we could have used it before).split_at_checkedrust-lang/rust#124678), added as unstable in 1.77 (core: introduce split_at{,_mut}_checked rust-lang/rust#118578).split_at_checkedrust-lang/rust#124678 (1.80).feature(strict_provenance).feature(exposed_provenance)as well.feature(try_reserve).try_reserve: RFC 2116 fallible collection allocation rust-lang/rust#48043.rust/kernel/lib.rs.feature(unsigned_is_multiple_of).unsigned_is_multiple_ofrust-lang/rust#128101.rust/kernel/io.rs.unsigned_is_multiple_ofrust-lang/rust#137383), added as unstable in 1.82 (addis_multiple_offor unsigned integer types rust-lang/rust#128103).is_multiple_offor unsigned integer types rust-lang/rust#128103 (1.82).unsigned_is_multiple_ofrust-lang/rust#137383 (1.87).-Zallow-features.-Zbuild-std.rusttesttarget, back when we had a customalloc).allocanmore. The actual progress is not clear. Seestdwanted features & bugfixes #572.-Zdwarf-version.-Zdwarf-versionrust-lang/rust#103057.-Zdwarf-versionas-Cdwarf-versionrust-lang/rust#136926), added as unstable in 1.64 (Implement support for DWARF version 5. rust-lang/rust#98350).-Zdwarf-versionas-Cdwarf-versionrust-lang/rust#136926.-Zdwarf-versionas-Cdwarf-versionrust-lang/rust#139747.-Zno-jump-tables(-Cjump-tables=n).no-jump-tablesrust-lang/rust#116592.CONFIG_X86_KERNEL_IBT(https://lore.kernel.org/rust-for-linux/20231009224347.2076221-1-mmaurer@google.com/).-Cjump-tables=n.-Zno-jump-tablesrust-lang/rust#105812 (1.68).-Zremap-path-scope(i.e. fine-grained--remap-path-prefix).-Zremap-path-scoperust-lang/rust#147611), working properly since 1.94 (Overhaul filename handling for cross-compiler consistency rust-lang/rust#149709, https://lore.kernel.org/rust-for-linux/DG93P7TMCWCH.3ACJU31B2HELW@garyguo.net/), added in 1.75 (Implement rustc part of RFC 3127 trim-paths rust-lang/rust#115214).std::panic::Location::caller().file()uses absolute path when monomorphized in a different crate. rust-lang/rust#148328.-Zremap-path-scoperust-lang/rust#147611 (1.95).-Zsplit-dwarf-kind=split.splitstops being the default.splitis the default, we will not need it.-Zsymbol-mangling-version=v0.rust/exports.c.rustdoc's--remap-path-prefix.--remap-path-prefixin rustdoc rust-lang/rust#155307), added as unstable in 1.81 (rustdoc: Add support for --remap-path-prefix rust-lang/rust#107099). The equivalent flag inrustcis already stable.documentationremapping path scope for rustdoc usage rust-lang/rust#151589 (1.95).--remap-path-prefixin rustdoc rust-lang/rust#155307 (1.97).--remap-path-prefixforrustc&rustdocrust-lang/rust#155485 (1.97).__rust_no_alloc_shim_is_unstable.rust/kernel/allocator.rsin 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: