# Backlog Bonanza 2022-04-27

[GitHub query](https://github.com/rust-lang/rust/issues?q=is%3Aopen+label%3AC-tracking-issue+label%3AT-lang)

## What are we DOING?

* Take things that have been unstable for a while and "disposition them".
* Goal: Everything that is nightly only has one or more of the following labels, indicating the blocker(s) to stabilizing it:
* S-tracking-ready-to-stabilize: Needs a stabilization PR (good to go :train:)
* S-tracking-needs-to-bake: Needs time to bake (set a date? other criteria?)
* S-tracking-impl-incomplete: Not code complete or blocking bugs
* S-tracking-unimplemented: Implementation not begun
* S-tracking-design-concerns: Blocking design concerns
* This might be "doesn't quite seem to deliver value we hoped for" or "something doesn't feel right"
* S-tracking-perma-unstable
* Internal implementation detail of rustc, stdlib
* S-tracking-needs-investigation

Attendance: Josh, Scott, Mark Rousskov, David Barsky, Jane Lusby

## Issue 48594

* Stabilization report at https://github.com/rust-lang/rust/issues/48594#issuecomment-421625182
* One concern it raised is still valid: there's a FIXME in https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/src/test/ui/for-loop-while/label_break_value.rs
* Discussion about label hygiene and label shadowing.
* S-tracking-needs-summary: https://github.com/rust-lang/rust/issues/48594#issuecomment-1111269353
* Can start FCP to merge once we have a summary

## Issue 49733

https://github.com/rust-lang/rust/issues/49733
Tracking issue for box syntax

scottmcm: explicitly unaccepted, but still in the compiler, so the issue is open

mark: some performance questions about whether we can remove it from implementation details

josh: S-tracking-perma-unstable

scottmcm: "Remove all unstable placement features" https://github.com/rust-lang/rust/pull/48333
https://github.com/rust-lang/rfcs/pull/2387

> Closes #22181, #27779. Effectively makes the assortment of placement RFCs (rust-lang/rfcs#470, rust-lang/rfcs#809, rust-lang/rfcs#1228) 'unaccepted'. It leaves box_syntax and keeps the <- token as recognised by libsyntax.

David: will write note that this has been unaccepted.

josh: not in a rush to remove this, but would if we grow a new stabilization-track feature for it.

## Issue https://github.com/rust-lang/rust/issues/49804

### Tracking issue for RFC 2102, "Unnamed fields of struct and union type"

josh: mechanism to make an unnamed field in `struct` or `union` to overlap storage without a name. RFC was written and merged, but not implemented

Mark: parsing was implemented

josh: still E-mentor and E-help-wanted. So S-unimplemented

Mark: And we should probably drop E-mentor since it's been a while.

https://github.com/rust-lang/rust/issues/49804#issuecomment-1111283077

## https://github.com/rust-lang/rust/issues/50297

### Tracking issue for eRFC 2318, Custom test frameworks

josh: a bunch of libs, lang for "collect a bunch of stuff"

mark: cargo & such too

josh: surface area questions.

scott: should we close this since it's experimental and nothing has happened?

scott: I'd love to see the distributed-slice thing happen as a lang piece, which seems like a mechanism this wants

David: would also be great for the performance of `tracing` in rustc

josh: do we have an issue for this anywhere? Or just the IRLO discussions?

David: No, just conversations

Josh: Maybe we need an MCP for this feature? And then either design-concerns or close. Activity in Feb, at least?

Scott: If there's nothing active here, I think we should close, as we did things like the Copy ergonomics issue.

Josh: will write a comment to close, with an encouragement to open new MCPs/WGs/something if they want to sign up for it.

Mark: Open questions about integration with tests, but yes.

David: I can make a distributed-slice MCP. Does that mean a design meeting, or?

Josh: Please file if you're interested on working on it! And if you can find more people to help, even better.

Here's the copy type ergonomics issue I mentioned that we closed, for the same

## https://github.com/rust-lang/rust/issues/51085

### Tracking issue for RFC 1872: exhaustive_patterns feature

Jane: blocked on never patterns?

match r {
    Ok(v) => v,
    Err(!),
}

Jane: and we need to figure out when safe code can just use "auto-never", rather than needing it directly. But this isn't tracked anywhere, it's just in Niko's head (and blog post)

https://smallcultfollowing.com/babysteps/blog/2018/08/13/never-patterns-exhaustive-matching-and-uninhabited-types-oh-my/

Mark: Maybe this is just design concerns, and someone needs to make a case for either saying we need those never patterns, or whether we're fine with how it works today. Not actually related to never *type* itself.

Josh: the implementation of this works with any uninhabited enum already?

Mark/Scott: Yes

Mark: The concerns are here about what it means to match on one of these things, and what assertions it's making about the values.

Jane: Will push forward and contact Niko