# Backlog Bonanza 2022-07-13
[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
## Tracking Issue for the avr-interrupt/avr-non-blocking-interrupt calling convention/ABI #69664
https://github.com/rust-lang/rust/issues/69664
> We agree that this needs an RFC. Not specifically for x86-interrupt, but an "target-specific interrupt calling conventions" RFC. Once that RFC goes in, new target-specific interrupt calling conventions would just need a patch to the ABI section of the reference, ideally documenting the calling convention.
> from https://github.com/rust-lang/rust/issues/40180#issuecomment-1022507941
We should point to that comment but also ask for a summary that's AVR-specific.
https://github.com/rust-lang/rfcs/pull/3246 is the RFC for interrupt calling conventions.
## Tracking Issue for const mem::discriminant #69821
https://github.com/rust-lang/rust/issues/69821
There's nothing that we are aware of blocking this from moving ahead, and we don't think that there's a need to block *const* stabilization on a use case. Josh to write a comment.
## Tracking Issue for layout information behind pointers #69835
https://github.com/rust-lang/rust/issues/69835
## Tracking Issue for "unsafe blocks in unsafe fn" (RFC #2585) #71668
https://github.com/rust-lang/rust/issues/71668
* We landed a lint for this
* Want a cargo fix, of some kind, at least
* Nominating for some additional discussion at triage around whether enabling by default
## Tracking issue for #![feature(const_precise_live_drops)] #73255
https://github.com/rust-lang/rust/issues/73255
https://github.com/rust-lang/rust/pull/91410#issuecomment-984031808
## Tracking Issue for #[repr(align(x))] on struct fields #73557
https://github.com/rust-lang/rust/issues/73557
Close, no work has been done and it needs a design (RFC/MCP).
## Tracking Issue for core::mem::variant_count #73662
* Some debate over usefulness
* Open question whether this is the right design, maybe alongside some mechanism to actually create the variants in question....
* Fits into broader enum story (AsRepr, etc.)