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
feature(compiler_builtins) and a way to avoid certain intrinsics (f32, f64, i128, u128 and 64-bit divisions/modulos).
Tracking Issue: internal to the compiler.
Used by: Kbuild.
We use feature(compiler_builtins) to avoid a dependency.
At the moment, we need to define certain panicking intrinsics related to f32, f64, i128, u128 and 64-bit divisions/modulos to be able to link, but we would like to get rid of the workaround.
The intrinsics are not provided by the kernel because they are operations that are not supposed to be used (by neither C nor Rust).
Regarding the 64-bit divisions/modulos, in Linux, C code explicitly calls a function (rather than use the usual / operator) to perform them, because they are rarely needed and can be very expensive in certain architectures.
Ideally, we would have a way to build core (and the rest, if the compiler may still generate the intrinsic calls by itself) in a way that it does not require defining intrinsics.
For instance, by not building the code that needs them in core to begin with (e.g. a special flag or cfg that prevents using certain types and avoids generating code for them) or, for the 64-bit divisions/modulos, redirecting them to the custom functions.
If calls are redirected, then we would still need a way to prevent Rust code from using the types (e.g. u128) and/or the operators (e.g. /), possibly via a lint, e.g. 64-bit divisions rust-lang/rust-clippy#16509.
It is an alternative ("hooks/customization points") to having to stabilize other unstable features that would be otherwise needed to implement our custom Arc.
Used by: not yet, but in the C side essentially by all architectures (and by x86_32 as -falign-functions=0 only for a few CPUs). @fbq mentions function tracing requires it (at least for arm64 and RISC-V).
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.
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*).
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).
Status: discussed most recently on RustWeek 2025. Second iteration of the new --output-format=doctest implementation waiting for test on Rust for Linux side.
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.).
Support for --emit=dep-info? The doctests can already be extracted without having built the crate (in both the old hack and with --outpuf-format=doctest), so if we have proper dependency information we could perhaps remove the dependency on the object file: feat(rustdoc): stabilize --emit flag rust-lang/rust#146220 (comment).
What we need is that Clippy does not break in the future when using it. For that, there are a few aspects:
The stability of each of the configuration keys and values (currently we use: msrv, check-private-items and disallowed-macros; we may soon use doc-valid-idents).
The stability of the .clippy.toml file (i.e. its existence). The kernel does not necessarily need that it is a file -- we could also use flags, for instance.
The stability of the CLIPPY_CONF_DIR environment variable. The kernel uses it since it supports builds outside the source tree and thus we need to point it to the source tree so that it finds .clippy.toml. If we were not to use the .clippy.toml, file, this would not be needed.
How to handle different compiler versions: for other tools (e.g. rustc), the kernel already handles passing different sets of flags depending on the compiler version. It would be easy for us to do the same for Clippy if the configuration options could be passed that way. Otherwise, if it is a file, there is the question of how to handle unknown keys/values. The kernel could also consider generating the configuration file on the fly, to avoid that issue.
Status: the target specification file is fairly tied to LLVM, thus it is unclear if something like it can be ever stabilized. Stabilizing command-line flags appeared to be the likely path forward. In cases where the flag should generally be the same across the entire crate graph, a "global target feature" concept (e.g. -Cglobal-target-feature=) could be useful, i.e. a target feature that is required to be set the same way for all compilation units (without requiring a new target). In other words, using flags to create variations of targets instead of requiring a different for every possible combination (and considering some flags are not just booleans but accept integer values). Then, targets modifiers were introduced for the case where mixing them incorrectly would be unsound. Then, -Zmin-function-alignment used the target modifiers framework, which in the end made us go full circle back into the global target feature, even if not unsound. Finally, -Zllvm-target-feature was proposed, which would allow to set unstable LLVM target features (instead of -Ctarget-feature which gives a warning for LLVM ones) and thus should allow us to drop the JSON target specification file.
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.).
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.
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.
Status: the FCP stalled, and there was discussion around other alternatives (e.g. a TimeUnits to do things like 2.seconds()). We can always use our own constants.
feature(macro_metavar_expr_concat) (modern alternative to the unstable concat_idents! macro).
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: 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).
Unstable features (including language, library, tools...) we currently use.
See as well:
build-std.build-stdgoal: issue, document.corewanted features & bugfixes #514allocwanted features & bugfixes #408stdwanted features & bugfixes #572rustcwanted features & bugfixes #355rustdocwanted features & bugfixes #350rustfmtwanted features & bugfixes #398bindgenwanted features & bugfixes #353rustupwanted features & bugfixes #396proc_macro2/quote/synwanted features & bugfixes #1216zerocopywanted features & bugfixes #1239rustc_codegen_gccwanted features & bugfixes #1098paholewanted features & bugfixes #1096Required (we almost certainly want them)
cfg(no_fp_fmt_parse).core).feature(arbitrary_self_types).arbitrary_self_typesrust-lang/rust#44874.Arc.derive(CoercePointee)(arbitrary_self_types + derive_coerce_pointee allows calling methods whose where clauses are violated rust-lang/rust#136702), stabilization PR and report (Arbitrary self types v2: stabilize rust-lang/rust#135881), v2 implemented in 1.83 (Arbitrary self types v2: pointers feature gate. rust-lang/rust#129664), v1 introduced in 1.23. There is as wellfeature(arbitrary_self_types_pointers)now (same tracking issue), but may be removed (2026-01-14).ptr_cast_add_auto_to_objectlint into hard error rust-lang/rust#136764 (1.87).derive(CoercePointee)builds on top of this.feature(receiver_trait)instead.auto impl): Supertrait Auto-impl rust-lang/rfcs#3851.feature(asm_const_ptr)(asm_constfor raw pointers).asm_construst-lang/rust#128464.constoperand rust-lang/rust#138618) with support for both LLVM and GCC backends.constin assembly rust-lang/rfcs#3848.constexpressions rust-lang/rust#132012.constoperand rust-lang/rust#138618 (1.99).feature(atomic_volatile).atomic_volatile) rust-lang/rust#158947.Atomic*types rust-lang/libs-team#801.feature(cfi_encoding).bindingsanduapicrates.feature(compiler_builtins)and a way to avoid certain intrinsics (f32,f64,i128,u128and 64-bit divisions/modulos).feature(compiler_builtins)to avoid a dependency.f32,f64,i128,u128and 64-bit divisions/modulos to be able to link, but we would like to get rid of the workaround./operator) to perform them, because they are rarely needed and can be very expensive in certain architectures.core(and the rest, if the compiler may still generate the intrinsic calls by itself) in a way that it does not require defining intrinsics.coreto begin with (e.g. a special flag orcfgthat prevents using certain types and avoids generating code for them) or, for the 64-bit divisions/modulos, redirecting them to the custom functions.u128) and/or the operators (e.g./), possibly via a lint, e.g. 64-bit divisions rust-lang/rust-clippy#16509.rust/compiler_builtins.rs.lib/math/div64.c.feature(derive_coerce_pointee)(previouslyfeature(derive_smart_pointer)), i.e.derive(CoercePointee)(previouslyderive(SmartPointer)).derive(CoercePointee)rust-lang/rust#123430.derive(CoercePointee)rust-lang/rust#134624.Arc.derive(CoercePointee)rust-lang/rust#133820). The kernel usesCoercePointeesince v6.14 (commit 47cb6bf ("rust: use derive(CoercePointee) on rustc >= 1.84.0")).CoercePointeedoesn't tightly enforce the restriction to#[repr(transparent)]-only wrappers, if other proc-macros are involved rust-lang/rust#135206.CoerceUnsizedbuiltin checks do not handle aliases rust-lang/rust#135214.Arc.derive(SmartPointer)rust-lang/rust#123472.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).DispatchFromDynandCoerceUnsizedimpl validation rust-lang/rust#135228 (1.86).ptr_cast_add_auto_to_objectlint into hard error rust-lang/rust#136764 (1.87).CoerceUnsizedandDispatchFromDynrust-lang/rust#137289 (1.87).derive(SmartPtr)rust-lang/rust#129104.SmartPointertoCoercePointeerust-lang/rust#131284 (1.84).#[pointee]attribute is required even if there is only one generic parameter rust-lang/rust#129465.receiver_is_dispatchablerust-lang/rust#138174 (1.87).[SOME_CONST; 0]to executeDrop, but only if type is annotated. rust-lang/rust#143671.derive(CoercePointee)is unsound with user-defined attribute macros. rust-lang/rust#148899.no entry found for keyrust-lang/rust#153005.dispatch_from_dyn, which we stopped using in favor ofderive_coerce_pointee): Unsoundness and ICE due toDispatchFromDynallowing bogus impls on references. rust-lang/rust#148727.feature(field_projections).field_of!macro and field representing types rust-lang/rust#118658.rustdoc): custom inner attributes remove source view for module rust-lang/rust#158768.feature(register_tool).#![register_tool]rust-lang/rust#66079.klintExperimental PR for introducing klint #958.#![register_{attribute,lint}_tool]rust-lang/rfcs#3808.feature(used_with_arg)(#[used(compiler)]in particular).used_with_argrust-lang/rust#93798.module!macro,rusttest...-Zallow-partial-mitigations(mitigation enforcement).-Z allow-partial-mitigations(RFC 3855) rust-lang/rust#149357).#![feature(mitigation_enforcement)]in the RFC, but not used like that.-Z allow-partial-mitigations(RFC 3855) rust-lang/rust#149357 (1.97).-Zbranch-protection.-Z branch-protectionrust-lang/rust#113369.CONFIG_ARM64_BTI_KERNELetc.-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).CONFIG_X86_KERNEL_IBT(https://lore.kernel.org/rust-for-linux/20231009224347.2076221-1-mmaurer@google.com/).-Zdebuginfo-compression(includingzstdsupport in Rust binaries' bundled LLVM).-Zdebuginfo-compressionrust-lang/rust#120953.zstdsupport is used in Android, where it currently warns, see commit dbef181 ("kbuild: rust: use-Zdebuginfo-compression").-Zdebuginfo-compressionas-Cdebuginfo-compressionrust-lang/rust#150625.-Zdirect-access-external-data={yes,no}(Clang's-fdirect-access-external-data).-Zdirect-access-external-datarust-lang/rust#127488.CONFIG_RELOCATABLE=yin the future (https://rust-for-linux.zulipchat.com/#narrow/channel/288089-General/topic/Builtin.20Rust.20components.20fail.20to.20build.20with.20small.20code.20model/near/565423029).-Z direct-access-external-datacmdline flag forrustcrust-lang/rust#119162).-Zindirect-branch-cs-prefix(GCC's and Clang's-mindirect-branch-cs-prefix).rustc(target features or dedicated flags) rust-lang/rust#116852.CONFIG_MITIGATION_RETPOLINE.-Zindirect-branch-cs-prefixrust-lang/rust#140740).-Zindirect-branch-cs-prefix(retpoline mitigation) rust-lang/compiler-team#899.-Zfixed-x18.-Zfixed-x18rust-lang/rust#124655.-Zfixed-x18into a target modifier rust-lang/rust#140661 (1.88).-Zfunction-return=thunk-extern.-Zfunction-returnrust-lang/rust#116853.CONFIG_MITIGATION_RETHUNK.-Zfunction-return={keep,thunk-extern}option rust-lang/rust#116892).-Zfunction-return=thunk-externrust-lang/rust#130824 (1.83).-Zinstrument-mcount.#[coverage]rust-lang/rust#84605 (#[no_coverage]).-Zinstrument-function,#[instrument_fn(entry = "off", exit = "off")]): RFC: Add compiler support for instrumenting functions rust-lang/rfcs#3917.-Zinstrument-function,#[instrument_fn="off"|"on"]): Implement RFC 3917 for instrumented functions rust-lang/rust#153742.-Zmerge-functions=disabled.-Zmin-function-alignment=N.#[align(...)]on function items (fn_align) rust-lang/rust#82232.-falign-functions=0only for a few CPUs). @fbq mentions function tracing requires it (at least for arm64 and RISC-V).-Cmin-function-alignmentrust-lang/rust#142824), added as unstable in 1.86 (add-Zmin-function-alignmentrust-lang/rust#134030). There is a listed concern on the interaction with function pointers.fn_align:#[align(N)]on functions rust-lang/rust#140261.-Zmin-function-alignmentlogic rust-lang/rust#142854 (1.89).-Zmin-function-alignmenta target modifier rust-lang/rust#143323.#[align(...)]on function items (fn_align) rust-lang/rust#82232 (comment).-Cmin-function-alignment/-Calign-functionssupport inrustcrust-lang/rust#128830.-fmin-function-alignment(GCC, Clang does not support it -- its-falign-functionsalready behaves like-fmin-function-alignment) and Clang's-falign-functions(GCC, Clang), i.e. align all functions, including cold functions.align): RFC: Add an attribute for raising the alignment of various items rust-lang/rfcs#3806.-Zpacked-stack.-Zpacked-stackrust-lang/rust#156724.soft-floatandpacked-stackrust-lang/rust#150766.-Zpatchable-function-entrysupport (GCC's and Clang's-fpatchable-function-entry), as well as thepatchable_function_entryfunction attribute.-Zpatchable-function-entry=total_nops,prefix_nops,record_sectionand#[patchable_function_entry(section = "..")]): Allow section override when using patchable-function-entries rust-lang/rust#157445 (1.98).-Zprofile-sample-useand-Zdebuginfo-for-profiling(formerly-Zdebug-info-for-profiling; Clang's-fdebug-info-for-profiling), i.e. AutoFDO (Automatic Feedback-Directed Optimization) support.profile-sample-useanddebug-info-for-profilingrust-lang/rust#155668.-Cprofile-sample-usestabilized in 1.100 (Stabilize-Zprofile-sample-userust-lang/rust#155942); added as unstable in 1.57 (Enable AutoFDO. rust-lang/rust#87918).-Zprofile-sample-userust-lang/rust#155942 (1.100).-Zdebuginfo-for-profilingswitch rust-lang/rust#156887 (1.98).-Zrandomize-layout(and-Zlayout-seed=<seed>).-Z randomize-layoutrust-lang/rust#106764.CONFIG_RANDSTRUCT*).-Zregparm=3(GCC's/Clang's-mregparm=3).-Zregparmrust-lang/rust#131749.memsetas of 1.89.-Zregparmdoes not work correctly for LLVM builtins rust-lang/rust#145271.-Zregparmfor LLVM builtins rust-lang/rust#145309 (1.91).-Zregparmdoesn't put 64-bit arguments in registers rust-lang/rust#145694.history.git).-Zregparm=3support inrustcrust-lang/rust#116972.-Zregparm=3could have been just a bit of plumbing inrustc, but it turns out Clang is the one that has the logic to decide the registers, which then get marked in LLVM IR, and thusrustcneeds 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).-Zreg-struct-returnsupport inrustcrust-lang/rust#116973.-Zreg-struct-returnoption rust-lang/rust#145382 (1.91).-Zreg-struct-returncan be skipped if atarget.jsonis used (abi_return_struct_as_intin target spec).-Zretpolineand-Zretpoline-external-thunk(Clang's-mretpoline-external-thunkand GCC's-mindirect-branch=thunk-extern -mindirect-branch-register).rustc(target features or dedicated flags) rust-lang/rust#116852.CONFIG_MITIGATION_RETPOLINE.-Zsanitizer=kcfi&-Zsanitizer-cfi-normalize-integers(KCFI).CONFIG_CFI_CLANG).-Cpanic=abortuntil LLVM'sinvokesupports KCFI bundles: CFI: Abstract Closures and Coroutines rust-lang/rust#123106 (comment).#[no_sanitize]): Remove the#[no_sanitize]attribute in favor of#[sanitize(xyz = "on|off")]rust-lang/rust#142681.bindgenIssue: Supportrepr(C)for enums rust-lang/rust-bindgen#3263.-Zsanitize-kcfi-arity(i.e. the equivalent of Clang's-fsanitize-kcfi-arity).-Zsanitize-kcfi-arityrust-lang/rust#138311.CONFIG_FINEIBT_BHI.-Ztune-cpu=generic.Makefile.-Zuse-sync-unwind=n.nremains the default.rustdoc's--generate-link-to-definition.[references]link from doc/source view could be nice to get).rustdoc's--remap-path-scope.--remap-path-scopein rustdoc rust-lang/rust#155451.--remap-path-scopeas unstable in rustdoc rust-lang/rust#155357). The equivalent flag inrustcis already stable.--remap-path-scopeas unstable in rustdoc rust-lang/rust#155357 (1.97).rustdoc: a way to extract doctests (--output-format=doctest, currently using a hack via--test-builder+--no-run(-Zunstable-options)).--output-format=doctestrust-lang/rust#134529.--output-format=doctestimplementation waiting for test on Rust for Linux side.--output-format=doctestcommand-line flag rust-lang/rust#134531 (1.86).Resultin generated doctest code rust-lang/rust#137807 (1.87).--no-run): rustdoc: Tracking issue for command-line flag--no-runrust-lang/rust#87022.--test-builder): rustdoc: Tracking issue for command-line flag--test-builderrust-lang/rust#102981.ignore, etc.).--runtool*flags (PR: Allow cross-compiling doctests rust-lang/rust#60387, Tracking Issue: Tracking Issue for Cross Compiling Doctests rust-lang/rust#64245, PR: Stabilize flags for doctest cross compilation rust-lang/rust#137096 (1.88)) allow to run tests under a particular tool, but it simply passes the path of the prebuilt binary to the tool, e.g.valgrind, thus it is not useful in our case.#[test]s or manipulating them).--emit=dep-info? The doctests can already be extracted without having built the crate (in both the old hack and with--outpuf-format=doctest), so if we have proper dependency information we could perhaps remove the dependency on the object file: feat(rustdoc): stabilize--emitflag rust-lang/rust#146220 (comment).Clippy's configuration.
msrv,check-private-itemsanddisallowed-macros; we may soon usedoc-valid-idents)..clippy.tomlfile (i.e. its existence). The kernel does not necessarily need that it is a file -- we could also use flags, for instance.CLIPPY_CONF_DIRenvironment 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.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.Remaining target features unknown to
rustc.#[target_feature]rust-lang/rust#44839 (split into roughly per-architecture ones now, e.g. Tracking Issue for aarch64_unstable_target_feature rust-lang/rust#150244, Tracking Issue for arm_target_feature rust-lang/rust#150246, Tracking Issue for loongarch_target_feature rust-lang/rust#150252, Tracking Issue for riscv_target_feature rust-lang/rust#150257, Tracking Issue for s390x_target_feature rust-lang/rust#150259).Command-line flags to eventually replace avoid target specification files (
target.json), global target features, target modifiers...-T): Tracking issue for MCP 980: group target modifier options under-Trust-lang/rust#160347.-Trust-lang/compiler-team#980.-Cflags that may change ABI): Tracking issue for all the ways in which -C compiler flags can alter the ABI rust-lang/rust#131837.-Ctarget-feature=+backchain): Tracking Issue for-Ctarget-feature=+backchainrust-lang/rust#158014.-Ctarget-feature=-apxf, i.e. disabling it): Tracking Issue for APX target feature rust-lang/rust#139284.apxftarget feature rust-lang/rust#139534 (1.88).powerpc64le-unknown-none-softfloat,powerpc64-unknown-none-softfloat,powerpc-unknown-none-softfloatrust-lang/rust#158199.-Zllvm-target-feature.-Zllvm-target-featuretarget *modifier* to directly set LLVM-level target features, and deprecate doing that with-Ctarget-featurerust-lang/rust#157753.-Zllvm-target-featuretarget *modifier* to directly set LLVM-level target features, and deprecate doing that with-Ctarget-featurerust-lang/compiler-team#994.-Cglobal-target-feature=) could be useful, i.e. a target feature that is required to be set the same way for all compilation units (without requiring a new target). In other words, using flags to create variations of targets instead of requiring a different for every possible combination (and considering some flags are not just booleans but accept integer values). Then, targets modifiers were introduced for the case where mixing them incorrectly would be unsound. Then,-Zmin-function-alignmentused the target modifiers framework, which in the end made us go full circle back into the global target feature, even if not unsound. Finally,-Zllvm-target-featurewas proposed, which would allow to set unstable LLVM target features (instead of-Ctarget-featurewhich gives a warning for LLVM ones) and thus should allow us to drop the JSON target specification file.compiler-builtinsPR: add -Zjson-target-spec to custom target workflows rust-lang/compiler-builtins#1071.compiler-teamIssue: Destabilise target-spec-json rust-lang/compiler-team#944.A way to build
corewith a stable compiler (possibly a subset of-Zbuild-std).build-stdcontext RFC proposed for merge.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-stdflag forrustc, e.g.-Zbuild-std=core(that could also potentially automatically find the source code for the library in the sysroot etc.).Nice to have (not critical, we could workaround if needed, etc.)
feature(asm_goto_with_outputs).asm_goto).feature(associated_type_defaults).TODOcomment in the upcomingpci.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.rsto simplify boilerplate needed by drivers).feature(bstr).BStrtype.ByteStrandByteStringtypes rust-lang/rust#135073).kernel::str::BStrwithcore::bstr::ByteStr#1146.feature(const_trait_impl).impl const Trait for Tyand[const](conditionally const) syntax (const_trait_impl) rust-lang/rust#67792.rust/kernel/driver.rsin the past (e.g. see_new_id_array!,define_id_array!anddefine_id_table!in https://lore.kernel.org/rust-for-linux/20240520172554.182094-3-dakr@redhat.com/).feature(doc_cfg).#[doc(cfg)]and automatically documented#[cfg]s rust-lang/rust#43781.rust/kernel/lib.rsin our oldrustbranch.doc(cfg(...))from thecfg(...)(to avoid duplication) etc. See also Consider allowing to build docs for the current kernel config #447.feature(duration_constants).rust/kernel/delay.rs.TimeUnitsto do things like2.seconds()). We can always use our own constants.feature(macro_metavar_expr_concat)(modern alternative to the unstableconcat_idents!macro).macro_metavar_expr_concatrust-lang/rust#124225.concat_idents!proc macro.feature(integer_extend_truncate).as)" in Rust wanted features #354.feature(ptr_alignment_type)or, more generally, a power-of-two type.mem::Alignmenttype rust-lang/rust#102070.PowerOfTwo<T>type.ptr::Alignmenttype rust-lang/rust#102072 (1.66).feature(ptr_metadata)(core::ptr::metadataandcore::ptr::from_raw_parts_mutfunctions).Arcin the past (before we switched tobyte_sub, i.e.pointer_byte_offsets), and potentially byimpl_zeroable!to include pointers to DSTs when their metadata isZeroablevia thePointeetrait.-Zbinary_dep_depinfo=y.-Zfunction-sections(inrustc, it applies to data too).rustc: rust-lang/rust@6b130e3).Makefile(underCONFIG_LD_DEAD_CODE_DATA_ELIMINATION, which is experimental so far).-Zub-checks(cfg(ub_checks)).feature(cfg_ub_checks)and-Zub-checksrust-lang/rust#123499.-Cdebug-assertions, but not stabilizing this means one cannot enable/disable each of them independently.-Zunpretty=expanded.RUSTC_BOOTSTRAP=1only for the target that uses it, if needed).--crate-attr(-Zcrate-attr).-Zcrate-attrform. 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.--crate-attrrust-lang/rfcs#3791.-Zcrate-attr): Add the -Zcrate-attr=foo unstable rustc option rust-lang/rust#52355.Low priority (we will likely not use them in the end)
feature(pointer_is_aligned)(is_aligned_to).FromBytes(VFS abstractions, Useis_aligned_toinFromBytesonce it's available #1038).is_aligned()) got stabilized in 1.79 (stabilize ptr.is_aligned, move ptr.is_aligned_to to a new feature gate rust-lang/rust#121948).is_aligned_to()may be stabilized, but it needs to be justified.Done (stabilized, not needed anymore, etc.)
Moved to #1223 due to reaching GitHub's 64k character limit on issue text.