---
title: Triage meeting 2022-04-12
tags: triage-meeting
---

# T-lang meeting agenda

* Meeting date: 2022-04-12

## Attendance

* Team members: nikomatsakis, Josh, Felix, Scott
* Others: Mark, Mara, Jane, jakob

## Meeting roles

* Action item scribe: Mark
* Note-taker: nikomatsakis

## Scheduled meetings

- 2021-04-13: Implied bounds and perfect derive
- 2021-04-20: Language design research overview
- 2021-04-27: Backlog Bonanza

## Announcements or custom items

(Meeting attendees, feel free to add items here!)

### Niko talked to a bunch of people at ETAPS

- There are lots of Rust verifiers now (at least 14!)
- Talking about what we could do to make their lives easier
- Some possible lang extensions
- "ghost code"
- Would like to propose for experimentation
- Other major topic: lifting coherence limitations and exploring portability
- e.g., being able to say "we want to add some specification rules to libstd"
- but I think same design could apply to portability across target platforms

### Coherence idea (Niko/Josh)

Had some brainstorming around coherence. One idea that came out was that it would be ok to have "third-party" impls as long as they are all equivalent. One way this might commonly arise is because of derive -- everybody deriving same trait on same struct -- or if there is an incredibly obvious implementation (delegation).

Felix: issues with debuginfo?

joshtriplett: Span should only be an issue if the code failed to compile-- if somebody referenced `#file`--

Felix: debugger runs, you end up with code with a filename/line-number

joshtriplett: Well, you'd unify and pick one. Doesn't seem like a big deal which one is selected.

nikomatsakis: I think "odr-link-once" does that already today.

scottmcm: What scares me here is that any new trait implementation becomes a breaking change, right? If I implement it in a way that doesn't match everyone else...?

joshtriplett: Valid.

nikomatsakis: Yes, we need to do a deep dive into all the possible issues. Lots of stuff here.

scottmcm: Agreement on having a brainstorming / proposal meeting.

nikomatsakis: I think we should sketch out the use cases we have in mind.

## Action item review

* [Action items list](https://hackmd.io/gstfhtXYTHa3Jv-P_2RK7A)

## Pending lang team project proposals
### "Deprecate target_vendor " lang-team#102

**Link:** https://github.com/rust-lang/lang-team/issues/102

### "Support platforms with size_t != uintptr_t" lang-team#125

**Link:** https://github.com/rust-lang/lang-team/issues/125

### "Positional Associated Types" lang-team#126

**Link:** https://github.com/rust-lang/lang-team/issues/126

### "Interoperability With C++ Destruction Order" lang-team#135

**Link:** https://github.com/rust-lang/lang-team/issues/135

### "inner crates, aka multiple crates per file" lang-team#139

**Link:** https://github.com/rust-lang/lang-team/issues/139

### "allow construction of non-exhaustive structs when using functional update syntax" lang-team#143

**Link:** https://github.com/rust-lang/lang-team/issues/143

nikomatsakis: I don't think metajack will drive this anymore, I propose we close this and say "we'd be happy to have this but needs a new owner".

joshtriplett: Did see somebody asking about construction of non-exhaustive structs on Zulip, would be worth treating this as generally wanted?

nikomatsakis: Maybe ping that person and ask if they want to drive it?

joshtriplett: done

nikomatsakis: [commented](https://github.com/rust-lang/lang-team/issues/143#issuecomment-1096992068)

### "Add #[deprecated_safe] attribute to allow functions be be marked unsafe in a backwards compatible fashion" lang-team#147

**Link:** https://github.com/rust-lang/lang-team/issues/147

Development on track.

### "Async fns in traits" lang-team#150

**Link:** https://github.com/rust-lang/lang-team/issues/150

action item: nikomatsakis to close in favor of at racking issue

## PRs on the lang-team repo

### "Fix dead links" lang-team#156

**Link:** https://github.com/rust-lang/lang-team/pull/156

Niko to merge.

### "add notes from 2022-03-30 meeting on lint policy. " lang-team#157

**Link:** https://github.com/rust-lang/lang-team/pull/157

Felix already merged

## RFCs waiting to be merged
### "Allow using `for<'a>` syntax when declaring closures" rfcs#3216

**Link:** https://github.com/rust-lang/rfcs/pull/3216

* Needs to be merged! This is annoying!
* nikomatsakis will do it

## Proposed FCPs

**Check your boxes!**
### "RFC: Add `target` configuration " rfcs#3239

**Link:** https://github.com/rust-lang/rfcs/pull/3239

joshtriplett: Proposed merge. Was original RFC #2991. Author did not have bandwidth and Guillaume-Gomez took it over and made the changes we asked for. Has now addressed all feedback that people had. Feel free to review or object. On thread, somebody said they were not sure about having the "whole target string" approach. I don't disagree but don't feel it's a problem, we already considered that in the original proposal.

### "Stabilize `let else`" rust#93628

**Link:** https://github.com/rust-lang/rust/pull/93628

joshtriplett: Is somebody going to help with this?

pnkfelix: I'm not sure how, it is assigned to me to look into it. I'm not sure who else knows.

nikomatsakis: Might know someone, will ping on Zulip.

### "Stabilize `let_chains` in Rust 1.62.0" rust#94927

**Link:** https://github.com/rust-lang/rust/pull/94927

Three concerns were raised, but last post says all were addressed. Let's do this!

:shipit:

### "Stabilize `$$` and `${ignore}` in Rust 1.62.0" rust#95860

**Link:** https://github.com/rust-lang/rust/pull/95860

joshtriplett: Subset of macro-metavar-expr split out for separate stabilization

* `$$` is equivalent to a `$` in a nested macro
* `${ignore(i)}` used for `$()*` length matching

*some discussion of the purpose of `ignore`*

m-ou-se: Not obvious what happens at deeper levels, `$$$` or `$$$$`?

pnkfelix: This style of escaping makes me sad, but I don't have a better suggestion.

nikomatsakis: we've reinvented makefiles omg

*appreciative chuckles*

joshtriplett: I think either is fine and we should just document what is best

m-ou-se: probably has to be exponential?

scottmcm: I think that we discussed this in the RFC, didn't we?

joshtriplett: I'll raise a concern for this, we should verify that it's explicitly documented already.

## Active FCPs
### "Tracking Issue for const offset_from (const_ptr_offset_from)" rust#92980

**Link:** https://github.com/rust-lang/rust/issues/92980

### "Check if call return type is visibly uninhabited when building MIR" rust#93313

**Link:** https://github.com/rust-lang/rust/pull/93313

### "Deprecate target_vendor " lang-team#102

**Link:** https://github.com/rust-lang/lang-team/issues/102

### "Positional Associated Types" lang-team#126

**Link:** https://github.com/rust-lang/lang-team/issues/126

### "Interoperability With C++ Destruction Order" lang-team#135

**Link:** https://github.com/rust-lang/lang-team/issues/135

### "Add #[deprecated_safe] attribute to allow functions be be marked unsafe in a backwards compatible fashion" lang-team#147

**Link:** https://github.com/rust-lang/lang-team/issues/147

### "Async fns in traits" lang-team#150

**Link:** https://github.com/rust-lang/lang-team/issues/150

## P-critical issues

None.

## Nominated RFCs, PRs and issues discussed this meeting

### "Enforce that layout size fits in isize in Layout" rust#95295

**Link:** https://github.com/rust-lang/rust/pull/95295

scottmcm: do we as lang think that this is the case? Has this always been a rule that we've not necessarily documented everywhere?

nikomatsakis: it's been the rule for a long time, iirc thestinger had an issue about it, I think it is because LLVM has UB or wants to support negative offsets or something like that. Maybe it was this one https://github.com/rust-lang/rust/issues/18726 ?

scottmcm: I'll put a comment that everybody in lang thinks that this is the case.

joshtriplett: Standard caveat that "if we are breaking people we might have to reconsider" applies, but yeah.

### "[Experiment] Remove migrate borrowck mode" rust#95565

**Link:** https://github.com/rust-lang/rust/pull/95565

m-ou-se: There was a crater run with 179 crates that failed, but literally all of them were caught previously by the mutable borrow reservation conflict lint, except for 12 cases, where people had specifically disabled that warning. [Comment](https://github.com/rust-lang/rust/pull/95565#issuecomment-1095117178)

m-ou-se: scoped threads is blocked on this

nikomatsakis: do we know why?

m-ou-se: I was going to ask you

nikomatsakis: :eep: I can look into it

testcase: https://github.com/rust-lang/rust/issues/93203#issuecomment-1084630290

pnkfelix: Is this the lint that was there to accommodate stacked borrows?

nikomatsakis: That's correct. I'm somewhat in favor of reverted that lint and make stacked borrows deal with it.

joshtriplett: Main reason we didn't do that is because it made Ralf sad, right?

nikomatsakis: It may cause lost optimization potential, but I think it's worth it.

joshtriplett: Did a quick look at the list of crates that have root regressions and most of them appear to be older versions of crates that have subsequently been replaced, in some cases, a long time ago?

joshtriplett: Given that, I suspect that this warning had its intended effect and people have moved off of it. I don't think we need to block on making this decision. Moving to NLL would break these old versions of crates, but mostly not current ones?

m-ou-se: Of those 12 that disabled the warnings, there is 1 that is sort of popular, ffsend.

simulacrum: have we looked into the 160 that are getting warnings today?

pnkfelix: is this using the future incompat infra so that people get warnings?

m-ou-se: I ... think so?

pnkfelix: Hard to tell just from the text.

m-ou-se: checked. yes it is.

nikomatsakis: WE CAN'T BREAK magic-school-bus-0.7.0!! (actually, that looks really cool --ed.)

m-ou-se: is it expected that NLL accepts more cases?

nikomatsakis: I believe so, in migrate mode we still have some errors.

### "Refined trait implementations" rfcs#3245

**Link:** https://github.com/rust-lang/rfcs/pull/3245

nikomatsakis: Follows the precedent we set for unsafe, that the impl can offer a more specific API than the trait, and if we can identify which impl is used we will take advantage of this.

simulacrum: In the unsafe RFC, we had some concerns about accidentally doing this, is that something that's been discussed?

nikomatsakis: The current RFC talks about a `#[refine]` attribute, but that was mainly targeting migration, I think it might be nice to have all the time (at least as a warning).

joshtriplett: +1 for opting in.

nikomatsakis: Is the sense of the meeting that we should make `#[refine]` required? That would also resolve the edition dependency, which is nice. I think I would say your impl *can* be more specific, but you're not committed to it unless you write `#[refine]`. We might want to warn though.

joshtriplett: Warning would make it more discoverable, yes. Other than that requirement (and the potential stability requirement of doing it by accident, I've absolutely failed to match the trait ABI before), I think we should do this.

nikomatsakis: Using the unsafe as an example, I could imagine being in a state of "I don't use unsafe now and I'd like to document that, but I still might want it in the future", which is otherwise unexpressible.

nikomatsakis: cool, will leave a comment.

### "Simple postfix macros" rfcs#2442

**Link:** https://github.com/rust-lang/rfcs/pull/2442

joshtriplett: went through the comment thread and incorporated feedback, I feel it's "ready to go". Others should see what they think.

## Nominated RFCs, PRs and issues NOT discussed this meeting

### "Allow using `for<'a>` syntax when declaring closures" rfcs#3216

**Link:** https://github.com/rust-lang/rfcs/pull/3216

### "Introduce `enhanced_binary_op` feature" rust#93049

**Link:** https://github.com/rust-lang/rust/pull/93049

### "Check if call return type is visibly uninhabited when building MIR" rust#93313

**Link:** https://github.com/rust-lang/rust/pull/93313

### "Allow `impl Fn() -> impl Trait` in return position" rust#93582

**Link:** https://github.com/rust-lang/rust/pull/93582

### "make unaligned_references lint deny-by-default" rust#95372

**Link:** https://github.com/rust-lang/rust/pull/95372

### "Fix unit struct/enum variant in destructuring assignment" rust#95380

**Link:** https://github.com/rust-lang/rust/pull/95380

### "Neither require nor imply lifetime bounds on opaque type for well formedness" rust#95474

**Link:** https://github.com/rust-lang/rust/pull/95474

### "Enforce Copy bounds for repeat elements while considering lifetimes" rust#95819

**Link:** https://github.com/rust-lang/rust/pull/95819

### "Modify MIR building to drop repeat expressions with length zero" rust#95953

**Link:** https://github.com/rust-lang/rust/pull/95953

### "Specify guarantees for repr(rust) structs" reference#1152

**Link:** https://github.com/rust-lang/reference/pull/1152

### "Clarify guarantees provided by repr(packed)" reference#1163

**Link:** https://github.com/rust-lang/reference/pull/1163

### "Add attribute to run specific tests in an isolated process" compiler-team#508

**Link:** https://github.com/rust-lang/compiler-team/issues/508