# Backlog Bonanza 2022-06-08

[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, Felix, Mark, Jane

## Tracking issue for procedural macros and "hygiene 2.0" #54727

https://github.com/rust-lang/rust/issues/54727

* issue covers wide variety of topics
* possible tags: design-concerns, unimplemented, or needs-summary.
* one comment: ["none of these features is blocked on hygiene, except for `proc_macro_gen`"](https://github.com/rust-lang/rust/issues/54727#issuecomment-426008711)
* we have `mixed_site`, but we still need `def_site` (which remains unstable)
* should tag as "needs-summary", with statements/questions about "what has been done versus still needs to be done"
* we also may want to break this up into finer-grain issues and then turn this into a tracking issue for those finer-grain issues
* mark: another option would be: Once there is a summary, we should perhaps close this issue as too broad in scope to be actionable, and replace it with separate tracking issues
* josh: removing the A-macros_2.0 label since this issue no longer references A-macros-2.0
* mark: well, hygiene-2.0 is a blocker for macros-2.0?
* felix: isn't this area lacking an owner in any case?
* josh: there is some amount of activity in the proc-macros space, but the macros-2.0 effort is stalled and has been for years. To get unstuck, we will need someone excited about spending the next year of their life on macros.
* josh: in any case, we should either replace this issue with a set of tracking issues, or turn it into a tracking issue with a proper series of checkboxes (that presumably link to more fine-grained actionable issues)

## Tracking issue for RFC 2412, "The optimize attribute" #54882

https://github.com/rust-lang/rust/issues/54882

* has landed/been implemented, but the propagation mechanism has not.
* proposed to tag as impl-incomplete
* the RFC as stated, has `optimize(size)` and `optmize(speed)`; people *asked* for `optimize(none)`, but that is not part of what was promised or delivered.
* it seems, in terms of what was promised, that the [transitive propagation](https://github.com/rust-lang/rfcs/blob/master/text/2412-optimize-attr.md#reference-level-explanation) is the main remaining work item.
* side conversation: how is this tested? how could this be tested in an ideal world? (see e.g.[`llvm.donothing`](https://llvm.org/docs/LangRef.html#llvm-donothing-intrinsic)).

## Tracking issue for RFC 2514, "Union initialization and Drop" #55149

https://github.com/rust-lang/rust/issues/55149

* we have stabilized `ManuallyDrop`
* it seems like all the work items are addressed?
* there is still a feature-gate for allowing arbitrary stuff into unions
* we might want to remove that code.
* we have `ManuallyDrop`, but you're not allowed to implement your own `ManuallyDrop`.
* there are some differences between `union`s and `ManuallyDrop`, e.g. `union`s suppress layout optimization today. But that is/can be a separate conversation. (E.g. we would likely address that via attributes that let one explicitly opt *in* to layout optimizations on a given `union` definition).
* So: remaining work is to remove the `untagged_union` feature gate and make it a hard error to try to do that.
* Is there anywhere we're using it internally? Based on cursory overview, seems like we are (at most) testing our *support* for it, but not actively using it in `compiler` nor `libstd`.
* So: Action is to write summary and fcp close.

## Tracking issue for RFC 2591: precise pattern matching on pointer size types #56354

https://github.com/rust-lang/rust/issues/56354

This works:

#![feature(precise_pointer_size_matching)]
fn foo(v: usize) {
    match v {
        0..=usize::MAX => {}
    }
}

* main concerns are about potential confusion,
* maybe best answer is to push on supporting half-open range patterns instead: https://github.com/rust-lang/rust/issues/67264

## Ambiguity errors in 2018 uniform import paths are not technically necessary #56414

https://github.com/rust-lang/rust/issues/56414

* context: when we decided on uniform paths for import, we introduced an ambiguity error so that we wouldn't restrict our ability to revise our thinking here in the future
* we could, hypothetically, just stabilize the current semantics
* today, we do allow shadowing in most contexts, but not this one
* do we allow shadowing with `use`?
* we allow shadowing of a parent scope. But not at the same level.
* question: has this check ever caught anything?
* memory is that we were trying to leave doors open for what module system variant we choose?
* this may be obselete, given that we have settled on uniform paths
* Is the check sufficiently annoying to users that we should remove it?
* Another take: does it provide so little utility that we should remove it because it is more trouble to continue supporting it?

# Tracking issue: platform-specific APIs for SGX target #56975

https://github.com/rust-lang/rust/issues/56975

* why is this T-lang?
* reasoning: lang had approved x86/arm intrinsics
* However, when these were created, we did not have inline assembly. Are these sufficiently valuable to be provided as intrinsics, or should we just expect people to provide them as inline-asm?
* Q: does inline-asm ever inhibit optimizations to a degree that one would *want* intrinsics instead?
* A: chances seem high that the nature of these intrinsics is that they could never be effectively optimized anyway.
* current theory: under that assumption (that this is implementable in asm without performance concerns) at this point this seems like a libs concern (in terms of whether such implementations should be provided from libstd or via third-party crates), not a lang one.

# Unstable Book Updates needed #57224

https://github.com/rust-lang/rust/issues/57224

* somebody took effort to compile list of things not in unstable book that start with letters `'A'..='E'`
* mark: don't we now mandate, via automated mechanism, that every feature have corresponding listing in the book?
* https://doc.rust-lang.org/nightly/unstable-book/language-features/abi-x86-interrupt.html
* Aside: how should we drive activity so that content actually propagates into the book, rather than having things solely live as comments on tracking issues?
* perhaps some triagebot magic could help here.

# Tracking issue for const fn integration with pattern matching #57240

https://github.com/rust-lang/rust/issues/57240

* looks like it has superceded by https://github.com/rust-lang/rust/issues/76001
* action: closing in favor of RFC 2920

# Tracking issue for #![feature(const_fn_floating_point_arithmetic)] #57241

* *something* is implemented here, namely floating-point with one particular IEEE behavior, but not *necessarily* what the runtime target would have done.
* spitballing some potential ways to address the issues here, e.g. expicitly opting into the compile-time semantics, perhaps via `const { ... }`.
* josh posted comment outlining some alternative paths forward