Rust Project Goals

Late on the update :') niko and i continue to meet to discuss const generics. we've made some progress on figuring out problems around privacy/safety in const generics. we've also been discussing the big picture stuff for const generics and where we're "heading".

Yesterday, we held a t-lang design meeting on our current approach. [@Nadrieril][] and I authored a design document with the feedback of Tyler Mandry, Ding Xiang Fei, Alice Ryhl, and Gary Guo. In this document, we provided the motivation for this feature, what the look and feel of a solution fitting into the existing features of Rust is, and a comprehensive + compact introduction to our current approach based on virtual places. You can find the design document as well as the meeting minutes here: https://hackmd.io/H5d2-83ER2ymNPZVIWCYWg.

The general reception was extremely positive. To give some concrete quotes from the meeting:

• Josh:

  I adore this! I love how orthogonal it is, and how impactful and universal it is. I anticipate this becoming a beloved, pervasive feature of Rust.

  Places and projection seem important enough to me that they're worth giving one of our precious remaining ASCII sigils to, and @ is nicely evocative of a place (something is at a place). So to the extent the final syntax benefits from a sigil, :+1: for giving this @. (See some feedback below on the details, though.)

• TC:

  Love it. High concept. As I said in the last meeting:

  "I particularly like language features that reduce the need for library surface area, and this is one of those."

  There are, of course, many details to resolve and understand further, e.g., with respect to migration issues, interaction with const, async, and other effect-like things, etc. I'm looking forward to seeing the formalization work.

• tmandry:

  What I love about this direction is how effectively it builds on what Rust already has. I love to see designs that reinforce our existing concepts while pushing them in directions that make them more expressive.

• Jack

  Whoo boy. This is great. There's so much here that I'm not exactly sure where to begin and what to comment on. I think this is the type of thing that we will only really be able to figure out the nitty gritty details and ergonomics only after some amount of experimentation.

There are a few takeaways from this meeting:

• Mark raised the concern that t-libs should be more involved in reviewing the experimental traits that we intend to add. Ensuring that we don't accidentally stabilize or expose some behavior, have sufficient documentation on our experimental traits, and that t-libs is in the loop of this feature in general.
  • Mark offered to review PRs and I will be tagging him in those.
• Jack raised the concern that increasing the cognitive load for the 95% use-case should be avoided. Making the right choice between @ and & might be challenging for users.
  • We discussed this point more in the meeting and concluded with that we need to do some experimentation, possibly utilizing the user research team. We will of course keep this in mind and revisit it later when we have a partially working implementation.
• TC requested that we publish our fine-grained design axioms, essentially the list of things we go through when considering a modification of our proposal.
  • I will write an update on this issue explaining exactly those.

Aside from the concerns and directly actionable items, the meeting also covered design questions/comments that we want to take a look at in the coming weeks/months:

• Can we support reads/writes of different types?
• Can we support re-assembly of wrapper types, so going from Cell<[T]> to [Cell<T>]?
• The PlaceDiscriminant trait needs to be carefully designed
• How do we handle naming conflicts & ensure SemVer evolution of library types implementing our traits?
• Can we support projecting through Option, so e.g. &Option<Struct> to Option<&Field>?
• Can we support a pointer that carries alignment information & which is updated on projections?
• What compatibility with effects do we need or want to support?
• What doors on future ergonomic improvements of pointers are we closing by having field projections?

Thanks to everyone who participated in the meeting!

Trying to prepare FLS releases earlier:

• since we completed the 1.94.0 release of the FLS a bit early this time, we checked into the stretch part of our goal this year to look at 1.95.0 early
• we learned a bit more of the release notes process thanks to tips from Eric Huss and TC
• Tshepang Mbambo and I attended the t-release meeting last week where we chatted about working a little "upstream" with them on generating the release notes a bit earlier
• tomorrow in our t-fls meeting we'll discuss our interest with engaging over there; at a minimum I'll get engaged with t-release

Glossary and main-body text harmonization:

• the first PR landed from Tshepang Mbambo removing IDs from the glossary
• further steps planned, we have a tracking issue for it

Developer guide:

• akin to how the Reference now has a developer's guide now for contributing we'll do the same in the FLS
• Hristian Kirtchev has been working on this

cc Hristian Kirtchev, Tshepang Mbambo, TC , Alex Eris Celeste née Gilding for any updates I missed to share them

Key developments:

std::autodiff is now partly in CI, and std::offload got tested on a lot more benchmarks.

autodiff

Work continued on enabling autodiff in nightly. Since the last update, we have enabled autodiff in some Mingw and Linux runners. Users can now download libEnzyme artifacts, place them locally in the right spot for their toolchain, and then use autodiff on their nightly compiler. Once macOS is added, we will enable a new rustup component that will handle the download for users. Before enabling autodiff on macOS, however, we want to change how we distribute LLVM on this target (from static to dynamic linking). There are a lot of workflows and users of this target, not all of which can be modelled in the Rust CI. Our last two attempts sadly broke such downstream users and local contributors, so both attempts had to be reverted. Since testing here is tricky, progress here might be on the slower side; we will see.

offload

Most of the work on the offload side lately has been invisible, since we were working on implementing more benchmarks and LLVM optimizations, as well as missing features, discovered by those benchmarks. We achieved excellent performance on those benchmarks; more details will soon be presented by Marcelo Domínguez at the EuroLLVM conference in two weeks!

Beyond benchmarks, there was a lot of tinkering on smaller PRs, reviewing, and housekeeping. LLVM-22 landed, so we updated our bootrstrap code to make use of new APIs, and tried to move a few smaller PRs forward, mainly around a better user experience and for making more Rust features available. Since the focus is still on benchmarks, not many of those PRs landed. They are in a mostly ready state, so it's a good time to pick them up if you're considering contributing. Please ping me on Zulip or in any PR with the offload label if you are interested!

The RFC has just been published as https://github.com/rust-lang/rfcs/pull/3943. It has been significantly reworked since the last draft.

Notable changes:

• Removed the concept of activation/de-activation. Now the semantics don't need to deal with partially allocated locals. This is less powerful optimization-wise but should still cover most cases.
• Added byref/byval to call arguments to clarify how they are passed.
• Added a separate section for the surface language changes to separate it from the MIR changes.
• Added more details on the MIR optimization which eliminates moves.
• Changed the MIR operand evaluation order to be left-to-right, except for destination places which are always evaluated last.
• Added StorageLive back: we need it to mark the location where llvm.lifetime.start should be inserted, which is not the same as the location where a local is initialized. In the opsem, StorageLive doesn't actually allocate the local, that's still done when it is initialized by a write.