Stabilize tooling needed by Rust for Linux

[nikomatsakis]

Metadata
Point of contact	@nikomatsakis
Team(s)	cargo, clippy, compiler, rustdoc
Goal document	2025h1/rfl

Summary

Continue working towards Rust for Linux on stable, turning focus to compiler and tooling.

Why this goal?

This goal continues our work from 2024H2 in supporting the experimental support for Rust development in the Linux kernel. Whereas in 2024H2 we were focused on stabilizing required language features, our focus in 2025H1 is stabilizing compiler flags and tooling options. We will (1) implement RFC #3716 which lays out a design for ABI-modifying flags; (2) take the first step towards stabilizing build-std by creating a stable way to rebuild core with specific compiler options; (3) extending rustdoc, clippy, and the compiler with features that extract metadata for integration into other build systems (in this case, the kernel's build system).

Tasks and status

• Discussion and moral support (compiler, rustdoc, cargo )
• Overall program management (@nikomatsakis)

Finalizing 2024h2 goals

• Stabilize derive(CoercePointee) (blocked on #136764 / #136776)
• Stabilize arbitrary self types v2 (blocked on #136764 / #136776)
• stabilize asm-goto (blocked on reference PR)
• support for pointers with asm_const Support for pointers with asm_const rust#128464

ABI-modifying compiler flags

• Author RFC (@Darksonn)
• RFC decision (compiler )
• Implementation (draft PR from @azhogin)
• Standard reviews (compiler )
• Stabilization decision (compiler )

Configure no-std externally

• Author an RFC to stabilize RFC #3791
• Implementation ()
• Standard reviews (compiler )
• Stabilization decision (compiler )

Rustdoc features to extract doc tests

• Author RFC ()
• RFC decision (rustdoc )
• Implementation ()
• Standard reviews (rustdoc )
• Experimentation in RFL (@ojeda)
• Stabilization decision (rustdoc )

Clippy configuration

• RFC text (pre-RFC draft)
• Stabilization decision (clippy )

-Zsanitize-kcfi-arity

• Tracking issue: KCFI: -Csanitize-kcfi-arity support in rustc rust#138311
• Implementation (KCFI: Add KCFI arity indicator support rust#138368, already reviewed by davidtwco)
• Stabilization

[nikomatsakis]

This issue is intended for status updates only.

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

[nikomatsakis]

Key developments:

• Implementation work is proceeding in many areas (arbitrary self types v2, derive smart pointer, and sanitizer support.
• Extended offset_of syntax is stable on nightly! 🎉 Credit to @dingxiangfei2009 for driving this.
• RFL on Rust CI is implemented but still waiting on documented policy. The first breakage was detected (and fixed) in #129416. Reading over the PR comments suggests that the policy has not been well communicated to the Rust devs, who weren't clear on who was responsible to fix the breakage etc. Suggested follow-up is to improve the bot message to link to the policy and (as an interim measure) send an email to all@ and post an Inside Rust blog post.
• Stabilization report for Pointers to Statics in Constants is now in FCP. @dingxiangfei2009 to prepare stabilization PR. 💜

Next steps

• Need to decide on a name for derive-smart pointer. @nikomatsakis to follow-up.
• Experimentation with asm-goto has revealed that a weak point in the design. A typical use case for this feature is to design control-flow, where you have some assembly code that decides which block to branch to. The current design looks like inline_asm!(..., exit1 = { ... }, exit2 = { ... }), in which the assembly code can jump to exit1 or exit2. The problem is that, since inline_asm! must be in an unsafe block, this implies the blocks associated with those labels will be allowed to use unsafe code. To circumvent this, the RFL team is having those blocks simply break from an outer block with a false return value, and then branching on that if value outside. That's the same as the C code does, as it happens, but. it's not as nice nor efficient as it could be. Discussion in the meeting suggested that the block bodies should be limited to safe code unless marked as unsafe. @joshtriplett to follow-up.
• For Sanitizer support, we will need to stabilize the -Zfixed-x18 flag as a first step. @Darksonn to start drafting a stabilization report, possibly delegating some questions to @nikomatsakis.

[nikomatsakis]

Key developments:

• Kangrejos, the Rust for Linux Workshop, took place Sep 7-8 in Copenhagen. Session listing and slides are available on https://kangrejos.com.
• @Darksonn has opened RFC #3716 proposing an approach to manage compiler flags that modify the target ABI and which therefore are only sound if used by all crates. The kernel makes use of a wide number of such flags and it is not practical to have a distinct target for all of the possible combinations. In authoring the RFC it was discovered that there are more such flags than were previously recognized, such as flags that modify LLVM behavior.
• Due to the fact that an increasing number of discussion topics had to do with the compiler, @wesleywiser and @davidtwco from the compiler team have started to join our meetings, which has been helpful in getting faster input from the compiler team.
• The final naming for the "derive-smart-pointer" feature has been settled; it will henceforth be called #[derive(CoercePointee)]. @dingxiangfei2009 prepared PR #131284 to do the rename and is preparing a patch and PR to the rust-for-linux repository.
• @nbdd0121 authored a hackmd outlining RFL's experiences with the asm-goto feature and in particular areas for improvement. From this we derived two immediate action items, making the target blocks safe-by-default (Tracking Issue for asm_goto rust#119364) and extending const to support embedded pointers (Support for pointers with asm_const rust#128464).

Next steps:

• RFC #3716 to be considered by the compiler team.
• Land PR Rename macro SmartPointer to CoercePointee rust#131284 and port code in the Rust-for-Linux repo to use it. Author stabilization report.
• Once FCP completes on Decide whether blocks inside asm goto should default to safe rust#132078, review and merge Make asm label blocks safe context rust#131544 making asm-goto target blocks safe-by-default.
• Decide on extending const to support embedded pointers (Support for pointers with asm_const rust#128464).
• Stabilization PR for embedding pointers to statics in constants (to be done by @dingxiangfei2009)

[nikomatsakis]

Brief updates from today's meeting (minutes):

• Discussed what goal to set for the next round of project goals. Miguel to prepare a candidate list of stabilization targets, prioritizing language changes (which require widespread edits to the codebase to rebase over) and outright hacks (as is used with rustdoc) and otherwise focusing on "what is needed to get some concrete production use case working". Candidate production use cases we discussed are the android linux kernel configuration or the configuration used by a popular linux distro.
• Discussed synchronization with Debian to see if we can ensure that the version of Rust in their next LTS includes support for Rust 2024, which would make it much easier for the RfL work (along with other crates in the ecosystem) to migrate.
• Compiler team documented policy with respect to RfL on their CI, so that item is done.
• Stabilizationj PR for pointers-to-statics-in-constants (Tracking Issue for const_refs_to_static rust#119618) has landed and is stable on nightly, work is needed to update the reference.
• RFC for ABI-relevant compiler flags ([RFC] Target Modifiers rfcs#3716) to be reviewed by compiler team and moved to FCP if appropriate. @wesleywiser to call attention to it in the next compiler team meeting.

[nikomatsakis]

Summary of meeting from Nov 20, prepared by @traviscross:

we went through a number of items proposed as 2025H1 project goals. The lang ones all seemed reasonable and achievable project goals. (We didn't get through all the non-lang items, so there's more to cover in the next meeting.)

Wesley mentioned that @adetaylor may not be available to continue pursuing arbitrary self types in 2025, so he's been prioritizing reviews on those to get things in this year, and that we may have to find someone to push this forward if it goes beyond that.

Alice mentioned that CoercePointee may be blocked on arbitrary self types, but wanted to think more about how fundamental that blockage is.

There was a lot of discussion about how to rebuild core in a stable way. Wesley mentioned an interesting thing, which is that the Cargo team would like rustc to support passing a compressed crate file to rustc, and that if we could do that, then we could distribute a core.crate via rustup. Kind of interesting.

There are also some items that the RfL folks want to get into unstable by Rust 1.85 as they may be stuck on that version for a long time. The main one for us is some way to relax the orphan rule. I suggested they file and nominate an ask for a lang experiment here.

[nikomatsakis]

November updates:

• @dingxiangfei2009's ports to make the RFL codebase use CoercePointee are under review.
• Pointers to static in constants were stabilized in Oct, reference PR is available and nearing completion.
• Discussion and some impl work continues with respect to the target modifiers RFC [RFC] Target Modifiers rfcs#3716.

[nikomatsakis]

FCP on rust-lang/rfcs#3716 has been proposed.

[nikomatsakis]

Summary from today's meeting: we've completed all language items but arbitrary self types, and the heavy lifting there is done. We have diagnostic work to do and then we want to get some feedback but we expect to be able to move to stabilization soon.

Arbitrary self types

The bulk of the impl work has landed, crater run showed no fallout. The only known outstanding work is improving diagnostics.

After that the next step will be stabilization. The main blocker is having some folks to play around with it and ensuring that it meets all the use cases it was meant to meet.

Derive smart pointer

• CoercePointee-- stabilization report was posted #133820
• ...and this is now in FCP

asm_goto

• Gary: stabilization PR is up + reference updates:
  • Stabilize asm_goto feature gate rust#133870
  • Add reference for asm-goto reference#1693
  • excludes the "output" feature
  • boxes checked

Compiler flags like fixed-x18

This will roll over to next year. We made good progress this half-year, with Alice authoring an RFC for the overall approach around the compiler. We are working on the implementation now.

[nikomatsakis]

In our meeting today we reviewed the plans for the 2025H1 project goal...

"Almost done" stuff from before

• re-stabilize CoercePointee -- Alice is looking at this, it's a good opportunity to try out the new template that is being discussed
• stabilize arbitrary self types v2 -- @adetaylor left a comment 3 weeks ago indicating that everything was more-or-less landed. RFL is already using it, providing evidence that it works reasonably well. Next steps are then sorting out documentation and moving to stabilize.
• asm-goto -- ready for stabilization, not been merged yet, still doing some work on the Rust reference (PRs Stabilize asm_goto feature gate rust#133870, Add reference for asm-goto reference#1693)

ABI-modifying flags

The rust-lang/rfcs#3716 is now in Final Comment Period (FCP). There is a preliminary implementation in #133138 that @petrochenkov is going to be reviewing. Some more work will be needed to test, cleanup, etc after that lands.

Other flags from RFL#2

We went through a series of flags from that RFL uses and looking into what might be blocking each of them. The process to stabilize one of these is basically to prepare the stabilization PR (minimal, but we need to rename the flag from -Z to -C) with a stabilization report and proper docs and then cc @davidtwco or @wesleywiser to prepare stabilization. In most cases we need to document how the flags can be misused, most commonly by linking against std or other crates not built with the same flags. If there are major correctness concerns as a result we likely want to consider the flag as "ABI-modifying".

• ability to extract dependency info, currently using -Zbinary_dep_depinfo=y -- basically ready to stabilize
  * tmandry: Do you want toolchain runtimes (libstd, compiler-rt) in your dep info? In my experience this features does 90% of what I want it to do, but removing the inclusion of runtimes is the only question I have before stabilizing.
• -Zcrate-attr, used to configure no-std without requiring it in the source file -- no real concerns
• -Zunpretty=expanded -- have to clearly document that the output is not stable, much like we did for emitting MIR. This is already "de facto" stable because in practice cargo expand uses RUSTC_BOOTSTRAP=1 and everybody uses it.
• -Zno-jump-tables -- this should be considered an ABI-modifying flag because we believe it is needed for CFI and therefore there is a risk if incompatible modules are linked.
• -Zdwarf-version, -Zdebuginfo-compression -- this should be ready to stabilize, so long as we document that you should expect a mix of debuginfo etc when mixing things compiled with different versions (notably libstd, which uses DWARF4). Debuggers are already prepared for this scenario. zstd compression is supported as of Rust 1.82.0.

stable rustdoc features allowing the RFL project to extract and customize rustdoc tests (--extract-doctests)

@imperio authored rust-lang/rust#134531, which is now up for review. Once PR lands, RFL will validate the design, and it can proceed to stabilization.

clippy configuration (possibly .clippy.toml and CLIPPY_CONF_DIR)

We discussed with clippy team, seems like this is not a big deal, mostly a doc change, one concern was whether clippy should accept options it doesn't recognize (because they may come from some future version of clippy). Not a big deal as of now, RFL only uses (msrv, check-private-items=true, disallowed-macros).

rebuild libcore

ARM team is working on this as part of this project goal, expect updates. 🎉

[nikomatsakis]

Updates:

2024H2 cleanup

• Arbitrary self types v2: Stabilization PR is open (Arbitrary self types v2: stabilize rust#135881).
• Stabilize CoercePointee: RFL is using it now; we are making progress towards completing the stabilization.

2025H1

• ABI-modifying flags RFC ([RFC] Target Modifiers rfcs#3716) has completed FCP and needs to be merged. Implementation PR #133138 authored by @azhogin remains under review.
• Other compiler flags, we made a prioritized list. One easy next step would be to rename all -Z flags in this list to something stabilizable (e.g., -C) that requires -Zunstable-features.
  • -Zdwarf-version -- wesley wiser
  • -Zdebuginfo-compression, unblocked
  • -Zcrate-attr, used to configure no-std without requiring it in the source file, no real concerns
  • -Zunpretty=expanded, unblocked, maybe needs a PR that says "don't rely on this", Linux only uses it for debugging macros (i.e. not in the normal build, so it is less critical). Needs a stable name, e.g., --emit macro-expanded, and we should make sure output cannot be piped to rustc. rustfmt told us (Rust for Linux) that they will try their best to keep rustfmt able to format the output of the expansion.
  • -Zno-jump-tables, considered an ABI-modifying flag
  • -Zbinary_dep_depinfo=y -- basically ready to stabilize (@tmandry asked "Do you want toolchain runtimes (libstd, compiler-rt) in your dep info? In my experience this features does 90% of what I want it to do, but removing the inclusion of runtimes is the only question I have before stabilizing", but we don't understand this point yet, as they were not present in the meeting).
• stable rustdoc: PR [rustdoc] Add --output-format=doctest command-line flag rust#134531 is under review, should land soon, then next step will be for RFL folks to try it out.
• Clippy configuration: no progress, discussed some new options and posted in thread, very minimal work required here.
• rebuild libcore: @davidtwco wasn't present so no update, but we know progress is being made

Publicizing this work

We discussed briefly how to better get the word out about this collaboration. Some points:

• @Darksonn will be speaking at Rust Nation
• We could author a Rust-lang blog post, perhaps once the language items are done done done?
• LWN article might be an option

general-regs-only

We discussed the possibility of a flag to avoid use of floating point registers, no firm conclusion yet reached.

[nikomatsakis]

This is a continuing project goal, and the updates below this comment will be for the new period 2025h1

[nikomatsakis]

Updates from our 2025-02-12 meeting:

Given the recent controversy about Rust usage in the Kernel, the RFL group wrote up a policy document explainer to explain the policy, and there was a write-up on LWN.

Regarding arbitary self types and coerce pointee, we are waiting on rust-lang/rust#136764 and rust-lang/rust#136776. The former is on lang team FCP. The latter has received approval from lang team and is awaiting further impl work by @BoxyUwU.

@ojeda is looking into how to manage dependency information and configure no-std externally.

@GuillaumeGomez's impl of rustdoc features has landed and we are waiting on RFL to experiment with it.

@davidtwco's team at ARM has authored a document regarding a blessed way to build-std and are collecting feedback.

@wesleywiser is preparing a PR to add -Zdwarf-version to help advance compiler flags.

There is an annoying issue related to cfg(no_global_oom_handling), which is no longer used by RFL but which remains in an older branch of the kernel (6.12, LTS).

As a set of "leaf crates" that evolve together in a mono-repo-like fashion, RFL would like to have a solution for disabling the orphan rule.

[nikomatsakis]

TL;DR:

We established the precise set of 2025H1 deliverables and we have been tracking them and have begun making progress towards them. Rustdoc has been updated to support extracting doc tests so that the Kernel can execute them in a special environment (this was previously done with a big hack) and RFL is in the process of trying to us that new support. The first PR towards the implementation of RFC #3716 has landed and the ARM team has begun reading early drafts of the design doc for -Zbuild-core with the cargo team.

We are also working to finalize the stabilization of the language features that were developed in 2024H2, as two late-breaking complications arose. The first (an interaction between casting of raw pointers and arbitrary self types) is expected to be resolved by limiting the casts of raw pointers, which previously accepted some surprising code. We identified that only a very small set of crates relied on this bug/misfeature; we expect nonetheless to issue a forwards compatibility warning. We are also resolving an issue where derive(CoercePointee) was found to reveal the existence of some unstable impls in the stdlib.

[nikomatsakis]

Update from our 2025-03-12 meeting (full minutes):

• RFL team requests someone to look at #138368 which is needed by kernel, @davidtwco to do so.
• -Zbinary-dep-info may not be needed; RFL may be able to emulate it.
• rustdoc changes for exporting doctests are being incorporated. @imperio is working on the kernel side of the feature too. @ojeda thinks it would be a good idea to do it in a way that does not tie both projects too much, so that rustdoc has more flexibility to change the output later on.
• Pre-RFC authored for clippy stabilization.
• Active iteration on the build-std design; feedback being provided by cargo team.
• @wesleywiser sent a PR to stabilize -Zdwarf-version.
• RfL doesn't use cfg(no_global_oom_handling) anymore. Soon, stable/LTS kernels that support several Rust versions will not use it either. Thus upstream Rust could potentially remove the cfg without breaking Linux, though other users like Windows may be still using it (#t-libs>no_global_oom_handling removal).
• Some discussion about best way forward for disabling orphan rule to allow experimentation with no firm conclusion.

[nikomatsakis]

TL;DR:

Most of the major items are in an iteration phase. The rustdoc changes for exporting doctests are the furthest along, with a working prototype; the RFL project has been integrating that prototype and providing feedback. Clippy stabilization now has a pre-RFC and there is active iteration towards support for build-std.

Other areas of progress:

• We have an open PR to stabilize -Zdwarf-version.
• The lang and types team have been discussing the best path forward to resolve #136702. This is a soundness concern that was raised around certain casts, specifically, casts from a type like *mut dyn Foo + '_ (with some lifetime) to *mut dyn Foo + 'static (with a static lifetime). Rust's defaulting rules mean that the latter is more commonly written with a defaulted lifetime, i.e., just *mut dyn Foo, which makes this an easy footgun. This kind of cast has always been dubious, as it disregards the lifetime in a rather subtle way, but when combined with arbitrary self types it permits users to disregard safety invariants making it hard to enforce soundness (see #136702 for details). The current proposal under discussion in #136776 is to make this sort of cast a hard error at least outside of an unsafe block; we evaluated the feasibility of doing a future-compatibility-warning and found it was infeasible. Crater runs suggest very limited fallout from this soundness fix but discussion continues about the best set of rules to adopt so as to balance minimizing fallout with overall language simplicity.

[nikomatsakis]

Updates from today's meeting:

Finalizing 2024h2 goals

• asm-goto is now stabilized! will be released in 1.87.
• asm-const has a preliminary impl, gcc support is needed.
• While not used in RFL, naked_asm is not on the list but it will be moving forward for stabilization. It suffers from the same LLVM bug as global_asm forgetting target feature flags.

ABI-modifying compiler flags

• Andrew Zhogin has opened a draft PR (Sanitizers target modificators rust#138736) following Alice's issue about which santisers should be modifiers (Some sanitizers should be target modifiers rust#138453)

Extract dependency information, configure no-std externally (-Zcrate-attr)

• We decided we don't need to be able to extract dependency information
• -Zcrate-attr has an RFC from jyn: RFC: --crate-attr rfcs#3791

Rustdoc features to extract doc tests

• No update.

Clippy configuration

• Pre-RFC was published but hasn't (to our knowledge) made progress. Would be good to sync up on next steps with @flip1995.

Build-std (#274)

• No update. Progress will resume next week when the contributor working on this returns from holiday.

-Zsanitize-kcfi-arity

• Added this as a new deliverable. These kind of "emerging codegen flag" requests can be expected from time to time. Notes available here and here.
• The PR has been reviewed and is unblocked to land.