Getting Rust for Linux into stable Rust: compiler features

[nikomatsakis]

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 and -Zsanitizer-recover=kernel-hwaddress (arm64)
• -Zsanitize-kcfi-arity (x86_64)

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