Stabilize Rust for Linux compiler features

[nikomatsakis]

Metadata
Point of contact	@tomassedovic
Team(s)	compiler
Goal document	2026/rust-for-linux-compiler-features

Summary

Develop and stabilize compiler features that Rust for Linux uses. This is a continuation of the existing Rust for Linux effort.

Tasks and status

---

Note: we have updated the body to match the 2026 goal. Your original text is preserved below.

Details

Metadata
Point of contact	@tomassedovic
Team(s)	compiler
Goal document	2025h2/Rust-for-Linux-compiler

Summary

Continue working towards Rust for Linux on stable. In particular, this goal is focused on the compiler features.

Tasks and status

• Discussion and moral support (compiler )

Finish and stabilize a given -Z... flag

• Discussion and moral support (compiler )
• Finalize remaining work ()
• Author stabilization report ()
• Author stabilization PR ()
• Stabilization decision (compiler )

Flags in use that need to be stabilized:

• -Zbranch-protection (arm64)
• -Zcf-protection (x86_64)
• -Zcrate-attr
• #![register_tool]
• -Zdebuginfo-compression
• -Zdirect-access-external-data (loongarch)
• -Zfixed-x18 (arm64)
• -Zfunction-return (x86)
• -Zfunction-sections
• -Zno-jump-tables (x86_64)
• -Zunpretty=expanded
• -Zsanitizer=kernel-address (arm64, riscv64)
• -Zsanitizer=shadow-call-stack (arm64, riscv64)
• -Zsanitizer=kcfi and -Zsanitizer-cfi-normalize-integers (arm64, riscv64, x86_64)

Flags to be used in the future:

• -Zharden-sls (x86_64)
• -Zindirect-branch-cs-prefix (x86)
• -Zmin-function-alignment
• -Zrandomize-layout
• -Zregparm (x86_32)
• -Zreg-struct-return (x86_32)
• -Zretpoline and -Zretpoline-external-thunk (x86)
• -Zsanitizer=kernel-hwaddress
• -Zsanitizer-recover=kernel-hwaddress (aarch64)
• -Zsanitize-kcfi-arity (x86_64)
• Sanitizers tracking issue

[nikomatsakis]

This issue is intended for status updates only.

For general questions or comments, please contact the owner(s) directly.

[tomassedovic]

I've updated the top-level description to show everything we're tracking here (please let me know if anything's missing or incorrect!).

[tomassedovic]

• [merged] Sanitizers target modificators / Sanitizers target modificators rust#138736
• [merged] Add assembly test for -Zreg-struct-return option / Add assembly test for -Zreg-struct-return option rust#145382
• [merged] CI: rfl: move job forward to Linux v6.17-rc5 to remove temporary commits / CI: rfl: move job forward to Linux v6.17-rc5 to remove temporary commits rust#146368
• -Zharden-sls / -Zharden-sls flag (target modifier) added to enable mitigation against straight line speculation (SLS) rust#136597
  • Waiting on review
• #![register_tool] / Tracking issue for #![register_tool] rust#66079
  • Waiting on #![register_{attribute,lint}_tool] rfcs#3808
• -Zno-jump-tables / Stabilize -Zno-jump-tables into -Cjump-tables=bool rust#145974
  • Active FCP, waiting on 2 check boxes

[tomassedovic]

-Cunsigned-char

We've discussed adding an option analogous to -funsigned-char in GCC and Clang, that would allow you to set whether std::ffi::c_char is represented by i8 or u8. Right now, this is platform-specific and should map onto whatever char is in C on the same platform. However, Linux explicitly sets char to be unsigned and then our Rust code conflicts with that. And isn this case the sign is significant.

Rust for Linux works around this this with their rust::ffi module, but now that they've switched to the standard library's CStr type, they're running into it again with the as_ptr method.

Tyler mentioned https://docs.rs/ffi_11/latest/ffi_11/ which preserves the char / signed char / unsigned char distinction.

Grouping target modifier flags

The proposed unsigned-char option is essentially a target modifier. We have several more of these (e.g. llvm-args, no-redzone) in the Rust compiler and Josh suggested we distinguish them somehow. E.g. by giving them the same prefix or possibly creating a new config option (right now we have -C and -Z, maybe we could add -T for target modifiers) so they're distinct from the e.g. the codegen options.

Josh started a Zulip thread here: https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Grouping.20target.20modifier.20options.3F/with/546524232

#![register_tool] / rust#66079 / RFC#3808

Tyler looked at the RFC. The Crubit team started using register_tool but then moved to using an attribute instead. He proposed we could do something similar here, although it would require a new feature and RFC.

The team was open to seeing how it would work.

[tomassedovic]

Update from the 2025-11-05 meeting.

-Zharden-sls / rust#136597

Wesley Wiser left a comment on the PR, Andr

-Zno-jump-tables / rust#145974

Merged, expected to ship in Rust 1.93. The Linux kernel added support for the new name for the option (-Cjump-tables=n).

[tomassedovic]

Update form the 2025-11-19 meeting:

-Zharden-sls / rust#136597

Andrew addressed the comment and rebased the PR. It's waiting for a review again.

#![register_tool] / rust#66079

Tyler Mandry had an alternative proposal where lints would be defined in an external crate and could be brought in via use or something similar: https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/namespaced.20tool.20attrs.

A concern people had was the overhead of having to define a new crate and the potential difficulty with experimenting on new lints.

Tyler suggested adding this as a future possibility to RFC#3808 and FCPing it.

[tomassedovic]

Update from the 2025-12-03 meeting:

-Zharden-sls

Wesley reviewed it again, provided a qualification, more changes requested.

[tomassedovic]

Update from the 2026-01-14 meeting:

#![register_tool] rust#66079

Tyler Mandry proposed FCP of the RFC#3808 and nominated it for a Lang discussion.

-Zdebuginfo-compression rust#120953

Wesley Wiser proposed stabilization: rust#150625.

Josh Triplett suggested trying to bring zlib-rs in the kernel as a case study.

-Zdirect-access-external-data rust#127488

rust#150494 was merged two days ago, what reminds is updating the documentation and stabilizing the feature.

There's an ongoing discussion about the feature on the Rust Zulip as well.

[tomassedovic]

Updates from the 2026-01-28 and 2026-02-11 meetings:

-Zdirect-access-external-data rust#127488

@nbdd0121's fix PR was merged: rust-lang/rust#150494

--emit=noreturn

@ojeda reiterated that this is high on the list of compiler features the project needs. Right now, they're doing these checks manually: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/objtool/check.c#n186.

Improving objtool's handling of noreturn is on @nbdd0121's radar but there wasn't time yet.

[tomassedovic]

Update from the 2026-03-11 meeting:

--emit=noreturn

It seems that figuring out which functions are noreturn is at a level too low for rustc. Function signatures are not sufficient and there are cases where rustc doesn't know whether to emit noreturn. It is something we should ask the LLVM to give us that information.

-Zsanitizer=kernel-hwaddress

@Darksonn opened a new issue to introduce the -Zsanitizer=kernel-hwaddress sanitizer for aarch64 targets: rust-lang/compiler-team#975

-Zharden-sls

@wesleywiser is working on rust-lang/rust#152821 which the -Zharden-sls patch should be rebased on top.

#![register_tool]

The corresponding RFC has been discussed by the Lang team on 2026-03-11. The overall vibe was positive and @traviscross is going to read through it and hopefully check a box on the proposed FCP.

-Zdebuginfo-compression

The proposed stabilization received some feedback that needs to be addressed.

-Zdirect-access-external-data

The discussion here has stalled.