---
title: "Lang/RfL meeting 2024-07-17"
tags: ["T-lang", "design-meeting", "minutes"]
date: 2024-07-17
discussion: https://rust-lang.zulipchat.com/#narrow/stream/410673-t-lang.2Fmeetings/topic/RfL.20meeting.202024-07-17
url: https://hackmd.io/tJ7IS2tvTduZan9a05aH4A
---

# Discussion

People: TC, nikomatsakis, Josh, Benno Lossin, Xiang, Alice Ryhl, Miguel Ojeda

https://rust-lang.github.io/rust-project-goals/2024h2/rfl_stable.html

https://github.com/nikomatsakis/rfcs/blob/rfl-project-goal/text/0000-rust-for-linux-project-goal-2024h2.md#ownership-and-other-resources

Previous minutes:

https://hackmd.io/ng6yq6aUQ1mGHFpwiQU-RQ

## Action items

* Benno to do write-up for `Unique<T>`.
* Miguel to talk to Jakub + Guillaume.
* Josh Triplett + TC to reach out to Debian about the edition timeline and see if we can find a solution here regarding Trixie. Maybe cc Miguel.

### Derive smart pointer

Tracking issue: https://github.com/rust-lang/rust/issues/123430

RFC is merged

Implementation work:

* https://github.com/rust-lang/rust/pull/123472 (general impl)
* https://github.com/rust-lang/rust/pull/125048 (unsoundness fix)
* basically a minimally invasive change for now that doesn't commit us to anything in particular

Niko would like to have an overview of the "big picture" here -- e.g., `CoerceUnsized`, `PinCoerceUnsized`, and the interaction with deref.

Alice: What we actually may want long-term is `DerefPure`, but actually doing this is a breaking change, but it's kind of edge-case.

Write-up: https://rust-lang.github.io/rfcs/3621-derive-smart-pointer.html#pincoerceunsized-1

nikomatsakis: No lang-team decision is needed, this was already described in the RFC, we just need to do the review.

Alice: we should update the PR text

#### subtopic

Miguel: Is there a plan to expose unique or "other boxes"? There will be more kinds of boxes. What do we lose?

nikomatsakis: you lose...

* borrow checker will not understand them:
* borrows are less precise (don't track individual fields)
* you can't move out with `*` or partially move out
* optimization due to aliasing assumptions
* no-alias generation

Benno: bigger problem is the 2nd one

Miguel: it'd be nice to have `derive(SmartPointerBox)` where you are promising uniqueness in exchange for no-alias guarantees.

Benno: I think a `Unique` type like the one the library has would be a better approach.

nikomatsakis: Is `Unique` in the stdlib already integrated into the compiler (e.g., benefitting from no-alias)

Benno: Unknown

joshtriplett: I don't anticipate this being a big libs concern, doesn't seem to have a stability hazard; if we are imprecise on the semantics or it's unclear that the semantics will be the same for all time, that's a bigger problem.

nikomatsakis: We should probably discuss with the libs team then. Somebody should do a write-up of what is to be proposed and float it.

**Benno to do write-up, and contact Josh for review of drafts**

### Arbitrary self types v2

Plan: https://github.com/rust-lang/rust/issues/44874#issuecomment-2122179688

Lang team unblocked a bit of this in the meeting earlier today...

https://github.com/rust-lang/rust/pull/117967

...but it still needs review.

Niko pinged lcnr.

### asm_goto

No progress since last meeting because Alice is on vacation.

### Extended offset_of syntax

Waiting for checkboxes on:

https://github.com/rust-lang/rust/issues/120140

https://github.com/rust-lang/rust/issues/120140#issuecomment-2174477951

Niko pinged the 4 holdouts.

### RFL on Rust CI

Status: Basically done.

Miguel: so far we've not gotten any pings since it was enabled. But it might be worth expanding the CI job to cover the rustdoc unstable features that we rely on (doctest-related). I talked to Guillaume and will follow-up with Jakub.

**Action item: Miguel to talk to Jakub + Guillaume.**

### Aside: Precise capturing syntax

TC: Can you do experiments with precise capturing syntax?

Miguel: We could but older compiler support is required. We don't really use lifetime bounds in the code I checked, so we don't have places where we would *need* to use it. We do have some instances of lifetime bounds in the older branch, but they were straightforward. We could enable it but we don't really have a piece of code that requires it.

### Aside: Rust 2024

TC: What's your plan for upgrading to Rust 2024? Part of what happens is that the semantics for RPIT change, so you may develop new places where you need it. If you were relying on the lifetimes not being captured you would need it then. The way to test it is to enable the new edition or maybe the feature independently.

Miguel: I was told that the new Debian stable will maybe use 1.83.0 according to the schedules. So we could increase the minimum to that easily. We can update it for a good reason but we try to avoid it otherwise to not be annoying to kernel developers.

TC: Any way to convince Debian to ship 1.85?

Josh: It's all about the dates. They could have plans to file a freeze exception, if we told them "hey if you can get something in after the freeze starts then you could support Rust 2024", then verifying that they're aware of that point may be useful. Gating factor will be the willingness of the release managers to grant exceptions.

https://release.debian.org/testing/freeze_policy.html

That said: are we prepared to commit to 1.85?

TC: It would surprise me greatly -- though we can be surprised with stabilizations that take longer than anticipated.

Josh: If we are prepared to commit, that's worth communicating.

Miguel: what I heard...

> Once the freeze starts (rustc is part of the earliest set of packages to get frozen before a new Debian stable release), new versions will only hit experimental, if at all. Last time around (for Bookworm), the relevant freeze date was January 12th. Assuming a similar timeline (not yet decided by the Release Team), and no hickups with upstream release cadence, that would mean trixie (to be released around summer '25) will ship with 1.83.

Josh: Rust is early in the dependency chain so that makes getting an exception more difficult. If we can promise compatibility though and are confident we can address regressions, that may make them more confident.

Miguel: Should we move to new edition?

TC: Yes.

Josh: If you need the features...

TC: Our policy is "editions are meant to be adopted", so it'd be a good look. Part of what we're trying to do is to give good ergonomics to kernel developers, and to bring them into the fold a bit, so it would be a negative if RFL ended up staying on 2021 for 3 years. Better to get it in when possible.

Josh: Constraint will probably be more about toolchains and what versions of the compiler they're supplying.

Miguel: New Debian stable would really help, then we can say "we'll upgrade the minimum to that one".

Niko: If we miss this window, we'll have to wait a few years before the next stable comes out?

Josh: Yes.

Miguel: We should definitely be on stable by the time the next stable comes around.

Josh: Next stable version of Debian has rustup. Worth at least floating that you can `apt install rustup` and then upgrade rust and keep it up to date. Reasonable thing to do esp. if the kernel has the metadata to keep things up to date.

Miguel: Still a trust issue if they are downloading binaries from rust-lang.org.

https://github.com/Rust-for-Linux/linux/blob/rust-next/Documentation/rust/quick-start.rst

**ACTION ITEM:** Josh Triplett + TC to reach out to Debian about the edition timeline and see if we can find a solution here regarding Trixie.

### Pointers to static in constants

No real update, Niko started reviewing the Zulip thread and preparing notes.

### Final comments

Josh: Would it be useful to have docs to communicate what the Rust edition means, why we are doing it, etc? Modules can compile with different editions but maybe you want to avoid that by policy for other reasons.

Josh: Do we have a list of the edition items?

TC: It's here:

<https://github.com/rust-lang/rust/issues?q=label%3AA-edition-2024+label%3AC-tracking-issue>

It may be a bit more clear to exclude the style items:

<https://github.com/rust-lang/rust/issues?q=label%3AA-edition-2024+label%3AC-tracking-issue+-label%3AT-style>

(The meeting ended here.)