# Backlog Bonanza 2022-01-26

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

## 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: Felix, Josh, Scott, Mark, Jane

# Tracking issue for the msp430-interrupt calling convention/ABI #38487

Link: https://github.com/rust-lang/rust/issues/38487

* Is there a need to tie this to the msp430-none-elf's targets stability (tier 3)?
* Should there be a per-target feature gate?
* Error on other targets?
* language guarantee vs. implementation detail of rustc specifically?
* Is this convention actually being used?
* For now:
* Check whether being used and good design -- needs-summary
* Maybe an amendment to the stability RFC (1105?) around calling conventions
* Potentially may want a just "interrupt" convention that does things for each target.
* pnkfelix: Some evidence other toolchains are doing something akin to this with an interrupt keyword.
* Josh to post a summary comment.

# Tracking issue: declarative macros 2.0 #39412

Link: https://github.com/rust-lang/rust/issues/39412

* Some recent conversation around this space
* Design concerns
* e.g., how to declare hygiene appropriately
* Some iteration on the general area of macros (from petrochenkov, notably)
* but no immediate expectation of forward progress

# Tracking issue for the x86-interrupt calling convention #40180

Link: https://github.com/rust-lang/rust/issues/40180

* Original proposal indicated no stabilization without an RFC
* Likely needs an RFC, per the above
* Mark: but maybe one describing interrupt CC in general rather than one dedicated to each target's specificity
* Does this always end up in inline assembly?
* no, not necessarily; not required
* Tagged needs-summary for now, to identify what the design work is like.
* Josh to write a comment up.

# Tracking issue for trait aliases #41517

Link: https://github.com/rust-lang/rust/issues/41517

* wg-traits territory
* needs-summary for them to give an opinion on next steps here
* pnkfelix to write up a summary

# Tracking issue for RFC 1868: A portability lint #41619

Link: https://github.com/rust-lang/rust/issues/41619

* No implementation yet (S-unimplemented)
* RFC looks approximately accurate, but design concerns not *yet* known (needs an impl to discover them)
* Generally very much desired by various teams; standard library expansion on a platform-specific area is semi-blocked on this.
* David left (possibly inaccruate) comment: https://github.com/rust-lang/rust/issues/41619#issuecomment-1022489056

# Tracking issue for unsized tuple coercion #42877

Link: https://github.com/rust-lang/rust/issues/42877

fn main() {
    let _: &(i32, [i32]) = &(3, [3, 3]) as _;
    // error[E0658]: unsized tuple coercion is not stable enough for use and is subject to change
}

* Mark: potentially blocked on tuple layout concerns
* If tuples are just structs, then seems obvious
* But may want to have fancier tuple unpacking/reshuffling down the line, so design concerns?
* Does anyone using this?
* Mark to write up a comment.

# Tracking issue for RFC 2033: Experimentally add coroutines to Rust #43122

Link: https://github.com/rust-lang/rust/issues/43122

* Niko just yesterday expressed interest in generalized coroutines
* Underpins generators/async fn
* Not yet ready to stabilize
* S-needs-summary
* Not entirely clear what current state is
* S-design-concerns
* At least input/output from `yield` points

# non-lexical lifetimes (NLL) tracking issue #43234

Link: https://github.com/rust-lang/rust/issues/43234

* Original NLL already shipped?
* There are some bits that aren't yet stabilized/shipped
* Compiler test suite is different between NLL and not (nll-migrate mode)
* Active work on pushing forward NLL full stabilization (closing out nll migration pieces), rough target of this year
* S-impl-incomplete
* but no design concerns known

# Tracking issue for RFC 1937: ? in main #43301

Link: https://github.com/rust-lang/rust/issues/43301

* Most of this is done shipped and stabilized
* `Termination` trait is still not stable, main leftover piece
* project error handling is working on Termination
* open question around representation of exit code (i32?), particularly on platform-specificity
* Is there enough expertise available to answer questions?
* Is this a libs issue, or lang?
* Is life before/after main a library problem?
* probably some overlap with lang, but minimal
* Return from `fn main` is lang in general, but that part is good
* S-tracking-design-concerns over the exit code piece
* help-wanted for a driver to resolve these
* Josh Triplett can give expertise on what the platform bits are