---
# System prepended metadata

title: Backlog Bonanza 2022-01-26

---

# 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

```rust=
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





