Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Resolve the biggest blockers to Linux building on stable Rust #116

Open
33 of 40 tasks
nikomatsakis opened this issue Jul 22, 2024 · 8 comments
Open
33 of 40 tasks

Resolve the biggest blockers to Linux building on stable Rust #116

nikomatsakis opened this issue Jul 22, 2024 · 8 comments

Comments

@nikomatsakis
Copy link
Contributor

nikomatsakis commented Jul 22, 2024

Metadata
Owner(s) @nikomatsakis, @joshtriplett
Team(s) compiler, lang, libs-api
Goal document 2024h2/rfl_stable
See also rust-lang/rust#44874

Summary

Stabilize unstable features required by Rust for Linux project including

  • Stable support for RFL's customized ARC type
  • Labeled goto in inline assembler and extended offset_of! support
  • RFL on Rust CI
  • Pointers to statics in constants

Tasks and status

@nikomatsakis
Copy link
Contributor Author

This issue is intended for status updates only.

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

@nikomatsakis nikomatsakis added the help wanted Extra attention is needed label Aug 28, 2024
@nikomatsakis
Copy link
Contributor Author

nikomatsakis commented Aug 30, 2024

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
Copy link
Contributor Author

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:

@nikomatsakis
Copy link
Contributor Author

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
Copy link
Contributor Author

nikomatsakis commented Dec 2, 2024

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
Copy link
Contributor Author

November updates:

@nikomatsakis
Copy link
Contributor Author

nikomatsakis commented Dec 3, 2024

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

@nikomatsakis
Copy link
Contributor Author

nikomatsakis commented Dec 18, 2024

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

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants