# Backlog Bonanza 2022-02-09

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

## omg 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, Felix, Mark, David Barsky, Michael Goulet

---

# Tracking issue for RFC 1861: Extern types #43467

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

* Intended for FFI and similar, opaque type
* Questions?
* `?Sized`, etc.
* Interactions with unsizing -- &Opaque -> &dyn Foo doesn't work
* Is this forward-compatible? Could we make `extern type` opaque and `?Sized` for now, and potentially extend it in the future to allow sized values or custom DSTs?
* Did this see a new design after the ThinPtr and other libs-api discussions?
* e.g., `ptr::null::<Foo>` doesn't currently work, because `extern type Foo: ?Sized`
* May actually want a `Metadata = ()` bound.

* Scott to briefly summarize the discussed open question (thin ptrs) and ask for a complete summary.

# Tracking issue for tweaks to object safety (RFC 2027) #43561

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

* Niko may have opinions :)
* Theory: moves the where clause such that things can't be called, but dyn Foo can exist?
* S-needs-summary; Josh to ask Niko in a comment

# Tracking issue for oom=panic (RFC 2116) #43596

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

* Implementation work: https://github.com/rust-lang/rust/pull/88098, https://github.com/rust-lang/rust/pull/92535
* originally related to `try_reserve` and similar mechanisms, now about unwinding on oom rather than aborting
* S-needs-summary about open questions

# :microscope: Tracking issue for generic associated types (GAT) #44265

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

* Open design question of where to put where clauses
* resolved, but not yet finalized FCP
* needs https://github.com/rust-lang/rust/pull/90076 to land
* S-needs-summary -- maybe just one last unresolved question
* just a couple more GATs-blocking issues
* but likely nearly ready to stabilize

# :microscope: Tracking issue for RFC 2089: Implied bounds #44491

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

* S-needs-summary?
* unclear current state -- maybe partially implemented?
* S-design-concerns?
* some concern around semver compat hazards
* `Cell<T: Copy>` changing to `Cell<T: !Copy>` not possible with this
* Currently, need to copy the trait bound onto your method if the type has it in the type definition
* doesn't block impl, but needs an answer before stabilizing.
* S-impl-incomplete
* Josh to post comment

# Tracking issue for RFC 2115: In-band lifetime bindings #44524

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

* Dispositioned close (FCP finished)
* To be removed -- just pending
* S-design-concerns: will be eventually closed because of them
* really hard to know where the lifetime comes from when looking at one
* shadowing vs. using difficult to distinguish (including just typos)
* There was an fcp close that discussed some of the issues
* Scott to comment asking for a PR removing it
* Done: https://github.com/rust-lang/rust/issues/44524#issuecomment-1034094520

# Tracking issue for const generics (RFC 2000) #44580

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

* Shipped min_const_generics
* const-generics group continuing to do work, and continuing evolution
* A meta tracking issue
* Maybe the RFC 2000 tracking issue should be closed, since that particular RFC is largely implemented?
* And new tracking issues filed for any new work
* https://github.com/rust-lang/project-const-generics exists
* A zulip thread about how to best track ongoing design/impl work -- Felix to start

# Tracking issue for RFC 2045: improving #[target_feature] #44839

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

* Initial RFC implemented, but has a long-tail target-specific component
* Potentially remaining portion is `--enable-feature` CLI opts from the RFC
* Discussion primarily focusing on new CPU features
* `--enable-feature` not being tracked (anywhere?)
* There are an infinite long-tail of future CPU features we could support, and tracking them on one issue does not feel right
* Docs: https://doc.rust-lang.org/nightly/reference/attributes/codegen.html#the-target_feature-attribute
* Proposal:
* FCP Close this issue; any new features slated for stabilization should be in new issues if needed
* Implicitly indicate that --enable-feature is no longer desired without a new proposal
* Felix to own the fcp close

# Tracking issue for arbitrary_self_types #44874

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

* Provides support for `self: Box<Self>`, etc.
* Stabilized some of these?
* in https://github.com/rust-lang/rust/pull/64325/
* S-needs-summary -- unclear what is currently stable and unstable, etc.
* Felix to leave a comment

# Tracking issue for RFC 2137: Support defining C-compatible variadic functions in Rust #44930

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

* Implemented, substantially working
* Doesn't work on all architectures yet
* but unlike e.g. asm!, there may not be architecture-specific code
* what tier of architecture needs support for this to be stable?
* Is this the tracking issue for the libs-api portion of this?
* Could cfg gate `std::ffi::VaList` etc
* but portability lint implications
* Target tier policy for u128, stack overflow detection, etc.
* need to document deficiencies for safety features
* u128 support expected when raising to next tier
* Needs-decision/nominated
* discuss at next meeting