# 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.)