Skip to content

Stabilize tooling needed by Rust for Linux #116

Open
@nikomatsakis

Description

@nikomatsakis
Contributor
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 Team)
    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 Team)
    Implementation (draft PR from @azhogin)
    Standard reviews (compiler Team)
    Stabilization decision (compiler Team)

Configure no-std externally

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

Rustdoc features to extract doc tests

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

Clippy configuration

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

-Zsanitize-kcfi-arity

Activity

added this to the 2024h2 milestone on Jul 22, 2024
locked and limited conversation to collaborators on Jul 25, 2024
nikomatsakis

nikomatsakis commented on Jul 25, 2024

@nikomatsakis
ContributorAuthor

This issue is intended for status updates only.

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

nikomatsakis

nikomatsakis commented on Aug 30, 2024

@nikomatsakis
ContributorAuthor

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

nikomatsakis commented on Oct 26, 2024

@nikomatsakis
ContributorAuthor

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_with_outputs rust#119364) and extending const to support embedded pointers (Support for pointers with asm_const rust#128464).

Next steps:

nikomatsakis

nikomatsakis commented on Nov 6, 2024

@nikomatsakis
ContributorAuthor

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.

30 remaining items

Loading
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

Status

Project goal

Relationships

None yet

    Development

    No branches or pull requests

      Participants

      @nikomatsakis@joshtriplett@ojeda

      Issue actions

        Stabilize tooling needed by Rust for Linux · Issue #116 · rust-lang/rust-project-goals