`rustc` wanted features & bugfixes

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

• x86's CONFIG_CPU_MITIGATIONS (previously CONFIG_SPECULATION_MITIGATIONS).

  • In C compilers, they are enabled via flags, but they are missing in rustc.
  • Some may be able to be enabled via LLVM target features.
  • For instance:
    • CONFIG_MITIGATION_RETPOLINE:
      • Clang's -mretpoline-external-thunk and GCC's -mindirect-branch=thunk-extern -mindirect-branch-register (plus -mindirect-branch-cs-prefix for both).
      • Old issue (when the target feature was +retpoline: Please add retpoline support. rust-lang/rust#54637).
      • Passing the target features in the target specification file works, but we cannot use -Ctarget-feature= due to the warnings -- see Retpoline support in rustc (target features or dedicated flags) rust-lang/rust#116852.
      • Draft PR: retpoline and retpoline-external-thunk flags (target modifiers) to enable retpoline-related target features rust-lang/rust#135927.
      • MCP: Flags for retpoline mitigation rust-lang/compiler-team#868.
    • CONFIG_MITIGATION_RETHUNK:
      • Clang's/GCC's -mfunction-return=thunk-extern.
      • See Tracking Issue for -Zfunction-return rust-lang/rust#116853.
      • PR: Add -Zfunction-return={keep,thunk-extern} option rust-lang/rust#116892.
    • CONFIG_MITIGATION_SLS:
      • Clang's/GCC's -mharden-sls=all.
      • Passing the target features in the target specification file works, but we cannot use -Ctarget-feature= due to the warnings -- see SLS support in rustc (target features or dedicated flags) rust-lang/rust#116851.
      • Draft PR: -Zharden-sls flag (target modifier) added to enable mitigation against straight line speculation (SLS) rust-lang/rust#136597.
      • MCP: Flags for mitigating straight line speculation rust-lang/compiler-team#869.

• Export (somehow) a list of all noreturn symbols.

  • objtool needs a list of functions that do not return.
  • Currently, we have a workaround with some heuristics: https://lore.kernel.org/rust-for-linux/20240725183325.122827-6-ojeda@kernel.org/
  • It would be ideal if rustc could emit somewhere (e.g. a file, via --emit=noreturns) a list of noreturn symbols. In particular, Peter suggests using a section: https://lore.kernel.org/rust-for-linux/20240806202217.GZ37996@noisy.programming.kicks-ass.net/
  • Gary proposed reading DWARF instead and wrote a quick Rust script for it via object and gimli, though DWARF would need to be available or generated on the fly just for that (and we cannot commit a fixed list since the kernel config may change and we support several Rust versions and so on): https://gist.github.com/nbdd0121/449692570622c2f46a29ad9f47c3379a.
  • Cc: @nbdd0121.

• -funsigned-char (GCC, Clang).

  • It could perhaps be a flag like -Cunsigned-char, or a "target modifier" instead, if those (RFC) come to fruition.
  • The kernel uses it (unconditionally) since commit 3bc753c ("kbuild: treat char as always unsigned") (v6.2).
  • The kernel will use a custom FFI mapping (kernel::ffi:: instead of core::ffi::) everywhere (i.e. for bindgen-generated code as well as manually written code), so we have a workaround for that part. However, things like CStr/c"" still use core::ffi::'s definition, so it would still be nice to match it.
  • Rust Zulip: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Changing.20the.20types.20in.20.60core.3A.3Affi.60/near/470131005.
  • Lore: https://lore.kernel.org/rust-for-linux/20240928193632.063d62a6.gary@garyguo.net/.

• -mpreferred-stack-boundary (GCC, Clang does not support it) / -mstack-alignment (GCC does not support it, Clang).

  • Used by: x86_64 (-mpreferred-stack-boundary=3, -mstack-alignment=8).
  • Used by: x86 (-mpreferred-stack-boundary=2, -mstack-alignment=4).
  • Issue: -Cstack-alignment/-Cpreferred-stack-boundary support in rustc rust-lang/rust#128833.
  • Commit: d9b0cde ("x86-64, gcc: Use -mpreferred-stack-boundary=3 if supported").
  • Commit: d77698d ("x86/build: Specify stack alignment for clang").
  • Commit: 8f91869 ("x86/build: Fix stack alignment for CLang").

• -mskip-rax-setup (GCC, Clang).

  • Used by: x86_64.
  • Commit: d9ee948 ("x86/asm: Use -mskip-rax-setup if supported").

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

• Support overriding all flags on the command line (i.e. support multiple --target, --sysroot, --edition...).

  • Some flags, such as --target, --sysroot and --edition, can only be applied once: it is a hard error to supply them more than once.
  • Some projects would benefit from a way to allow to override them, or have had issues related to this behavior. For instance:
    • The Linux kernel allows users to pass "additional" flags as environment variables, rather than having to pass (again) the entire flag list (or having in the kernel side a way to manually filter previous flags). This came up for the Android build and was a problem.
    • Compiler Explorer allows users to pass flags, but it added a custom UI for toggling the edition, which in turn meant writing --edition was a hard error unless handled especially, which was eventually added.
  • If backwards compatibility is desired, then perhaps an opt-in flag could be added, e.g. --allow-override=target,edition.
  • Lore: https://lore.kernel.org/rust-for-linux/20241112184455.855133-1-ojeda@kernel.org/.
  • CE Issue: [BUG]: Rust links that included the --edition flag broke with compiler overrides compiler-explorer/compiler-explorer#5429.
  • CE Issue: [REQUEST]: Pre-fill --edition=2021 for Rust compiler-explorer/compiler-explorer#3765.
  • CE PR: When rust edition appears in both overrides and compiler-options, prefer the options compiler-explorer/compiler-explorer#6789.
  • Zulip: https://rust-lang.zulipchat.com/#narrow/channel/425075-rust-for-linux/topic/Support.20overriding.20all.20flags/near/486988024.
  • MCP: allow all command line flags to be passed multiple times, overwriting previous usages rust-lang/compiler-team#731.

• -falign-jumps=1, i.e. not aligned (GCC, Clang does not support it).

  • Used by: x86_64.
  • Used by: x86_32 (-falign-jumps=0, only for a few CPUs).
  • Commit: be6cb02 ("x86: Align jump targets to 1-byte boundaries").
  • Issue: -Calign-jumps=1 support in rustc rust-lang/rust#128831.
  • This is not critical now, since we mainly support only LLVM=1 builds so far, but eventually we will want to match the C side for GCC builds when those become non-experimental.

• -falign-loops=1, i.e. not aligned (GCC, Clang).

  • Used by: x86_64.
  • Used by: x86_32 (-falign-loops=0, only for a few CPUs).
  • Issue: -Calign-loops=1 support in rustc rust-lang/rust#128832.
  • Commit: 52648e8 ("x86: Pack loops tightly as well").
  • For LLVM, we may use -Cllvm-args=--align-loops=1: -Calign-loops=1 support in rustc rust-lang/rust#128832 (comment).

• Showing type aliases (perhaps in addition to resolved types) in error messages, potentially manually tagging the cases with sometimes like #[own_name].

  • From: Mutex/spinlock/condvar #990 (comment).
  • May allow us to have Arc<T> = ARef<WithRef<T>> and would improve readability of messages around e.g. Mutex<T> = Lock<T, MutexBackend>.
  • Rust Zulip: https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/type.20aliases.20and.20names.20in.20errors.

• A way to skip the existing bypass of lints that come from foreign crates.

  • In our case, the "foreign" crates are really our own code, thus we would still want the lints.
  • In particular, this would allow to still get lints like -Dunsafe_op_in_unsafe_fn in generated code by proc macros.
  • PR that introduced the change: Squash all lints tied to foreign macros by default rust-lang/rust#52467.
  • Related open issues: function-like procedural macros: no dead_code warning on created code (e.g. "function is never used" warning) rust-lang/rust#73556, dead_code lint not running on code generated by crate-external macros rust-lang/rust#53209.

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

  • See Rust wanted features #354.

• MSRV for rustc, similar to Cargo's and Clippy ones (--msrv=version).

  • Issue & MCP: --hint-msrv=version option so the compiler can take MSRV into account when linting rust-lang/compiler-team#772 (accepted).

• Ability to load .so libraries under macOS.

  • Some kernel developers want to build Linux under macOS, but the kernel does not support that (the macOS support is maintained out-of-tree). So they may need something like this to minimize the differences with upstream. There may be other possible solutions (e.g. using symlinks, if that works, but it would require knowing the names in general). Perhaps this could help other projects to be ported to macOS too.
  • Issue: --extern mycrate=path/to/my/crate/with/random.suffix fails with "file name should be lib*.rlib or lib*.so" rust-lang/rust#131720.
  • Lore: https://lore.kernel.org/rust-for-linux/CAJ-ks9==6mi7SF5rTR=YouwC6RwktJftqXHqhsBcHNTWxdbfig@mail.gmail.com/.

• Flag output.

  • Issue (project-inline-asm): Request: flag output rust-lang/project-inline-asm#14.
  • Cc: @fbq @nbdd0121.

• Removing crate disambiguators from symbol names.

  • We plan to enforce that all crate names are unique in the kernel -- would that allow disambiguators to be removed from the generated symbol names?
  • Zulip: https://rust-lang.zulipchat.com/#narrow/channel/425075-rust-for-linux/topic/Long.20symbols.20and.20crate.20disambiguators/near/501791872.

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

• --check mode / --emit=check.
  • Like cargo check, but for rustc.
  • cargo check appears to do --emit=dep-info,metadata, but that would not be needed for the leaves.
  • Currently, the best approximation appears to be --emit=metadata, but it would be nice to have a way that reduces the work to the minimum, at least avoiding to emit the metadata and temporaries.
  • --emit=metadata=/dev/null does not appear to work due to the generated temporaries (and -Ztemps-dir does not seem to change that).
  • Use case: some tests (e.g. in upstream Rust: the warning-free builds of core and alloc under no_global_oom_handling in rustc) and faster development (it could also be part of a dev-mode in the kernel, which could include other changes like disabling the missing documentation warning).
  • From: Add test for warning-free builds of core under no_global_oom_handling rust-lang/rust#110652.

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

• -Zpatchable-function-entry support (GCC's and Clang's -fpatchable-function-entry), as well as the patchable_function_entry function attribute.

  • Moved into the main list since it got implemented.

• -Zregparm=3 and -Zreg-struct-return.

  • Moved to the main list, since they got issued a tracking issue and are being implemented.
  • GCC's/Clang's -mregparm=3 and -freg-struct-return.
  • Used by: x86 (i.e. 32-bit).
  • -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 can be skipped if a target.json is used (abi_return_struct_as_int in target spec).
  • Tracking Issue: Tracking Issue for -Zregparm rust-lang/rust#131749.
  • Tracking Issue: Tracking issue: -Zreg-struct-return support in rustc rust-lang/rust#116973.
  • Issue: -Zregparm=3 support in rustc rust-lang/rust#116972.
  • PR: rust_for_linux: -Zregparm=<N> commandline flag for X86 (#116972) rust-lang/rust#130432.
  • PR: rust_for_linux: -Zreg-struct-return commandline flag for X86 (#116973) rust-lang/rust#130777.
  • From: [BROKEN] 32-bit x86 (i386) support #966 (comment).
  • Commit: e852f31 ("[PATCH] Add CONFIG for -mregparm=3") (in history.git).
  • Commit: 2516512 ("[PATCH] x86: add -freg-struct-return to CFLAGS").

• Layout randomization.

  • -Zrandomize-layout (and -Zlayout-seed=<seed>) were implemented, though 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*).
  • MCP: Add the -Z randomize-layout flag rust-lang/compiler-team#457.
  • Feature Request: Add -Zrandomize-layout flag to better detect code that rely on unspecified behavior related to memory layout rust-lang/rust#77316.
  • Issue: Tracking issue for -Z randomize-layout rust-lang/rust#106764.
  • PR: Added -Z randomize-layout flag rust-lang/rust#87868.
  • PR: Add user seed to -Z randomize-layout rust-lang/rust#91932.

• CET (-Zcf-protection=branch).

  • Moved into the main list since it got implemented.

• KCFI (-Zsanitizer=kcfi & -Zsanitizer-cfi-normalize-integers).

  • Moved into the main list since it got implemented.

• x86's CONFIG_X86_KERNEL_IBT support (-Zcf-protection=branch -Zno-jump-tables).

  • GCC's/Clang's -fcf-protection=branch -fno-jump-tables.
  • Moved into the main list since the flags got implemented.

• Make debug_triple depend on target.json file content rather than file path.

  • Use case: Out-of-tree module failed to build if the kernel source path is different #792.
  • Related issue: Found unstable fingerprints for exported_symbols with custom target rust-lang/rust#92403.
  • PR: Make debug_triple depend on target json file content rather than file path rust-lang/rust#98225 (1.63).
  • Issue: https://bugs.launchpad.net/ubuntu/+source/rustc-1.62/+bug/2011355.

• Diagnostics for -D flags make it slightly harder to allow vs. #![deny(...)].

  • Issue: Diagnostics for -D flags make it slightly harder to allow vs. #![deny(...)] rust-lang/rust#114030.
  • PR (help: line): Add an allow attribute suggestion along with the implied by suggestion rust-lang/rust#114089 (1.74).

• .comment section support.

  • PR: [RFC] Support .comment section like GCC/Clang (!llvm.ident) rust-lang/rust#97550 (1.73).
  • PR (rustc_codegen_gcc): subtree update cg_gcc 2023/11/17 rust-lang/rust#118068 (1.76).

• arm64: shadow call stack (SCS) support.

  • Used by: Kbuild (and, in particular, Android enables dynamic SCS).
  • Issue (support -Zsanitizer=shadow-call-stack in the builtin target): Shadow call stack should be supported on aarch64-unknown-none rust-lang/rust#121972.
  • Issue (recognize -Ctarget-feature=+reserve-x18 to avoid warning): Compiler does not recognize the reserve-x18 target feature rust-lang/rust#121970.
  • PR (alternative 1: recognize -Ctarget-feature=+reserve-x18 to avoid warning): Add reserve-x18 target feature for aarch64 rust-lang/rust#124323.
  • PR (alternative 2: add a GCC/Clang-like -Zfixed-x18 flag): Add -Zfixed-x18 rust-lang/rust#124655 (1.80).
  • MCP: -Zfixed-x18 rust-lang/compiler-team#748.
  • Issue (improve docs): List of arches that support -Zsanitizer=shadow-call-stack is incomplete rust-lang/rust#121966.
  • Zulip: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/-ffixed-x18/near/430864291.
  • Zulip: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/New.20.60reserve-x18.60.20target.20feature/near/438370694.
  • Cc: @Darksonn.

• KASAN.

  • -Zsanitizer=kernel-address is being implemented.
  • PR: Add kernel-address sanitizer support for freestanding targets rust-lang/rust#99679.

• -fmin-function-alignment (GCC, Clang does not support it) / -falign-functions (GCC, Clang)

  • Moved into the main list since it got implemented.
  • Used by all architectures.
  • Used by: x86_32 (-falign-functions=0, only for a few CPUs).
  • The behavior wanted is that of GCC's -fmin-function-alignment and Clang's -falign-functions, i.e. align all functions, including cold functions.
  • There is feature(fn_align), but we need to do it globally.
  • Issue: Tracking Issue for #[repr(align(...))] on function items (fn_align) rust-lang/rust#82232.
  • Original Issue: -Cmin-function-alignment/-Calign-functions support in rustc rust-lang/rust#128830.
  • PR: add -Zmin-function-alignment rust-lang/rust#134030 (1.86).

• -Zsanitize-kcfi-arity (i.e. the equivalent of Clang's -fsanitize-kcfi-arity).

  • Required for the upcoming CONFIG_FINEIBT_BHI.
  • Issue: Tracking Issue for -Zsanitize-kcfi-arity rust-lang/rust#138311.
  • 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).

---

Bugs that we would like to see fixed

Required (we almost certainly want them)

• The -softfloat target does not have KCFI nor KASAN enabled.
  • Starting with Rust 1.85.0, we are supposed to use the -softfloat target to avoid the warning avoid disabling neon in the non-softfloat one, because it warns (without the ability to silence it) and will be a hard error eventually.
  • Issue in Zulip: https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/arm64.20neon.20.60-Ctarget-feature.60.20warning/near/495358442.
  • PR: Enable kernel sanitizers for aarch64-unknown-none-softfloat rust-lang/rust#135905 (1.86).
  • Backport to beta PR: [beta] backports rust-lang/rust#136650 (1.85 since rustc 1.85.0-beta.8 (38213856a 2025-02-06)).

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

• Include all (i.e. non-code-related) warnings in -Dwarnings (or include a way to control whether they are errors).

  • Issue: target json file contains unused fields unaffected by -Dwarnings rust-lang/rust#91262.
  • MCP: -Dwarnings to cover all warnings rust-lang/compiler-team#473.

• Finish unreachable_pub lint implementation.

  • Issue: Lint unreachable_pub got easily confused by multiple items in a single pub use ... statement rust-lang/rust#64762.
  • Issue: Move collection of items accessible directly or through reexports from rustc_privacy to rustc_resolve rust-lang/rust#82064.

• --emit=dep-info + -Zunpretty=expanded emits output.

  • Issue: --emit=dep-info + -Zunpretty=expanded emits output rust-lang/rust#93201.

• Missed optimization (to_result discussion).

  • From: https://lore.kernel.org/rust-for-linux/CANiq72nO=Eje0dv_NCagvTzOLU7WkfM-bwqH33z_kC=f=m1m1A@mail.gmail.com/
  • Issue: Missed optimization when removing intermediate rust-lang/rust#116150.
  • Issue in LLVM: Missed optimization llvm/llvm-project#67342.

• Missed optimization (wrapping "raw generated enums into cleaner ones).

  • From: https://lore.kernel.org/rust-for-linux/CANiq72nCJc6wL1VY9=8A5NruY++8X4db+agpC-SW2MMiuyduHA@mail.gmail.com/
  • Issue: Missed optimization: converting "equivalent" enums rust-lang/rust#116272.
  • Issue in LLVM: Missed optimization of switch to arithmetic llvm/llvm-project#67842.
  • Issue in LLVM: Missed optimization of switch to arithmetic llvm/llvm-project#67843.
  • PR in LLVM: [SimplifyCFG] Improve linear mapping in switch lookup tables llvm/llvm-project#67881.
  • PR in LLVM: [SimplifyCFG] Improve range reducing for switches llvm/llvm-project#67882.

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

• rustc warns when finding an unknown jobserver style.
  • Non-critical for us, since we should be able to update rustc (or users could force an older jobserver style).
  • Issue: rustc warns when finding an unknown jobserver style rust-lang/rust#120532.

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

• creader: Host crate loaded twice produces different CrateNums if host != target.

  • Issue: creader: Host crate loaded twice produces different CrateNums if host != target rust-lang/rust#56935.
  • PR: Reuse CrateNum for proc-macro crates even when cross-compiling rust-lang/rust#86876.

• Skip linking if it is not required.

  • PR: Skip linking if it is not required rust-lang/rust#81118.

• ICE when proc macro panics if compiled with -Cpanic=abort.

  • Issue: rustc crash when proc macro panics if compiled with -Cpanic=abort rust-lang/rust#82320.
  • PR: Warn when using panic-strategy abort for proc-macro crates rust-lang/rust#106678.

• Set dso_local for hidden, private and local items.

  • PR: Set dso_local for hidden, private and local items rust-lang/rust#83592.

• Set dso_local for more items.

  • PR: Set dso_local for more items rust-lang/rust#85276.

• Add back support for inline stack-probes.

  • LLVM: https://bugs.llvm.org/show_bug.cgi?id=50165.
  • Issue: Extend stack probe support to non-tier-1 platforms, and clarify policy for mitigating LLVM-dependent unsafety rust-lang/rust#43241.
  • Issue: In latest nightly observing a to-be returned variable changes its value. rust-lang/rust#84667.
  • Related: Use probe-stack=inline-asm in LLVM 11+ rust-lang/rust#77885.
  • Related: On linux, __rust_probestack shouldn't be called on smallish stack allocations rust-lang/rust#74405.
  • Related: Enable stack probes on aarch64 for LLVM 18 rust-lang/rust#118491.

• Strange -Zunpretty=expanded behavior with global_asm!.

  • Issue: -Zunpretty=expanded output with global_asm! loses semicolon thus cannot be formatted rust-lang/rust#101047.
  • Issue: -Zunpretty=expanded output may not contain global_asm! depending on comments/whitespace/... rust-lang/rust#101051.
  • PR: Fix global_asm macro pretty printing rust-lang/rust#101369.

• The x86_64-unknown-none-linuxkernel target is not actually used.

  • PR: Remove linuxkernel targets rust-lang/rust#104015.

• ARM64: Fix some issues with folded AArch64 features.

  • Lore: https://lore.kernel.org/rust-for-linux/20230125163739.3798252-1-Jamie.Cunliffe@arm.com/.
  • PR: Fix some issues with folded AArch64 features rust-lang/rust#107294.

• Ensure 128-bit types from the C side (__int128_t, __uint128_t) are usable for architectures that need it.

  • For ARM64, i128/u128 match the ABI of the C ones, and that should remain the case thanks to Create optionally-available __int128 typedefs and use them for ARM64 definitions. rust-lang/libc#2719.
  • Issue: i128 / u128 are not compatible with C's definition. rust-lang/rust#54341.
  • Issue: Proposal: Remove i128/u128 from the improper_ctypes lint rust-lang/lang-team#255.
  • Status: i128 / u128 are not compatible with C's definition. rust-lang/rust#54341 (comment).
  • Lore: https://lore.kernel.org/rust-for-linux/Bs9NB9XuVGuOkEvvTFpYIPDo-S-bn6LpsSKciLfFkp5J73L84wAsJFXGKYEZ7VtCKYIWUWyKxvtelgi7NuvcDT6kgPXGiz8VoUv6gh-fFGQ=@protonmail.com/.

• .eh_frame section emitted for kernel.o (debug assertions enabled, rustc >= 1.70.0).

  • Issue: .eh_frame section emitted for kernel.o (debug assertions enabled, rustc >= 1.70.0) #1012.
  • PR: Prevent .eh_frame from being emitted for -C panic=abort rust-lang/rust#112403 (1.72).

• .eh_frame section emitted for rust_echo_server.o.

  • Issue: .eh_frame section emitted for rust_echo_server.o #1016.
  • PR: Add MIR validation for unwind out from nounwind functions + fixes to make validation pass rust-lang/rust#113124 (1.73).

• -Zunpretty=expanded does not emit dep-info anymore (1.68 -> 1.69).

  • Issue: -Zunpretty=expanded does not emit dep-info anymore (1.68 -> 1.69) rust-lang/rust#112898.
  • PR: Fix missing dependency file with -Zunpretty rust-lang/rust#114476 (1.73).

• #[expect(dead_code)] does not behave identically to #[allow(dead_code)].

  • Issue: #[expect(dead_code)] does not behave identically to #[allow(dead_code)] rust-lang/rust#114557.
  • PR: Respect #[expect] the same way #[allow] is with the dead_code lint rust-lang/rust#114710 (1.73).

• 1.74 ICE.

  • Seen in the Asahi AGX kernel driver.
  • Solved in 1.74.1.
  • Issue: 1.74 causes an internal compiler error: broken MIR in Item rust-lang/rust#117976.
  • Marked for stable backport: Move subtyper below reveal_all and change reveal_all rust-lang/rust#116415.

• rustc 1.76 (beta) warns about non-recursive invocation from Make.

  • rustc may document that it may always take advantage of the jobserver (e.g. for backend and eventually frontend parallelism), and thus users should always call rustc as recursive from Make.
  • Issue: rustc inside make -j2 warns (regression from 1.75.0) rust-lang/rust#120515.
  • PR: rustc: document the jobserver rust-lang/rust#121564 (1.80).

• The last --jobserver-auth flag should be used like the GNU Make manual asks to (jobserver crate, used by rustc).

  • Non-critical for us, since kernel developers should not be touching the flag manually or using something that is not GNU Make.
  • Issue: The last --jobserver-auth flag should be used rust-lang/jobserver-rs#66.
  • PR (jobserver): fix: last --jobserver-auth wins  rust-lang/jobserver-rs#67.
  • PR: Update jobserver-rs to 0.1.28 rust-lang/rust#120846 (1.77).

• rustc should disable the jobserver if file descriptors are negative like the GNU Make manual asks to.

  • Non-critical for us, since even if a user requests the older jobserver style, we will be marking all rustc calls as recursive.
  • Kernel users should not see this unless they request in Make 4.4 the older jobserver style for some reason.
  • Issue: no separate issue; from rustc inside make -j2 warns (regression from 1.75.0) rust-lang/rust#120515.
  • PR (jobserver): disable jobserver on unix, if file descriptors are negative rust-lang/jobserver-rs#68.
  • PR: Update jobserver-rs to 0.1.28 rust-lang/rust#120846 (1.77).

• ICE on rustc 1.79.0-beta.4 (a26981974 2024-05-10) when compiling core.o.

  • Reproducer: RUSTC_BOOTSTRAP=1 rustc --edition=2021 -Csymbol-mangling-version=v0 --cfg no_fp_fmt_parse --crate-type rlib library/core/src/lib.rs --sysroot=/dev/null.
  • Related PR (beta nominated): Add v0 symbol mangling for f16 and f128 rust-lang/rust#123816 (1.79).
  • Issue: f16/f128 fallback code is not getting inlined rust-lang/rust#125229.
  • PR (beta nominated): Add #[inline] to float Debug fallback used by cfg(no_fp_fmt_parse) rust-lang/rust#125252 (1.79).
  • PR: [beta] backports rust-lang/rust#125529 (1.79).
  • Fixed in rustc 1.79.0-beta.7 (d9e85b56e 2024-05-25).
  • Cc: @tgross35.

• Are attributes such as noalias, readonly, dereferenceable... worth it for performance or could they potentially be all disabled to get something like -fno-strict-aliasing?

  • Perf run: perf experiment: remove noalias, readonly, dereferenceable attributes rust-lang/rust#137707.