Repository: rust
Issue: Tracking Issue for `try_trait_v2`, A new design for the `?` desugaring (RFC#3058)
Labels: B-RFC-approved,T-lang,T-libs-api,C-tracking-issue,F-try_trait_v2,S-tracking-design-concerns

<!--
NOTE: For library features, please use the "Library Tracking Issue" template instead.

Thank you for creating a tracking issue! 📜 Tracking issues are for tracking a
feature from implementation to stabilisation. Make sure to include the relevant
RFC for the feature if it has one. Otherwise provide a short summary of the
feature and link any relevant PRs or issues, and remove any sections that are
not relevant to the feature.

Remember to add team labels to the tracking issue.
For a language team feature, this would e.g., be `T-lang`.
Such a feature should also be labeled with e.g., `F-my_feature`.
This label is used to associate issues (e.g., bugs and design questions) to the feature.
-->

This is a tracking issue for the RFC "`try_trait_v2`: A new design for the `?` desugaring" (rust-lang/rfcs#3058).
The feature gate for the issue is `#![feature(try_trait_v2)]`.

This obviates https://github.com/rust-lang/rfcs/pull/1859, tracked in https://github.com/rust-lang/rust/issues/42327.

### About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however *not* meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

### Steps
<!--
Include each step required to complete the feature. Typically this is a PR
implementing a feature, followed by a PR that stabilises the feature. However
for larger features an implementation could be broken up into multiple PRs.
-->

- [ ] Implement the RFC
  - [x] Add the new traits and impls
  - [x] Update the desugar in ast lowering
  - [x] Fixup all the tests
  - [ ] Add nice error messages in inference
  - [ ] Improve perf with enough MIR optimizations
  - [x] ~~Delete the old way after a bootstrap update~~ https://github.com/rust-lang/rust/pull/88223
- [x] Not strictly needed, but a mir-opt to simplify the matches would really help: https://github.com/rust-lang/rust/issues/85133
- [ ] Add more detailed documentation about how to implement and use the traits
- [ ] Decide whether to block return types that are `FromResidual` but not `Try`
- [x] Fix rustdoc to show the default type parameter on `FromResidual` better (Issue https://github.com/rust-lang/rust/issues/85454)
- [ ] Before stabilizing, ensure that all uses of `Infallible` are either fine that way or have been replaced by `!`
- [ ] Stabilizing this will allow people to implement `Iterator::try_fold`
  - [ ] As part of stabilizing, document implementing try_fold for iterators (perhaps reopen https://github.com/rust-lang/rust/pull/62606)
  - [ ] Ensure that the default implementations of other things have the desired long-term DAG, since changing them is essentially impossible later.  (Specifically, it would be nice to have `fold` be implemented in terms of `try_fold`, so that both don't need to be overridden.)
- [ ] Adjust documentation ([see instructions on rustc-dev-guide][doc-guide])
- [ ] Stabilization PR ([see instructions on rustc-dev-guide][stabilization-guide])

[stabilization-guide]: https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#stabilization-pr
[doc-guide]: https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#documentation-prs

### Unresolved Questions
<!--
Include any open questions that need to be answered before the feature can be
stabilised.
-->

From RFC:
- [ ] What vocabulary should `Try` use in the associated types/traits? Output+residual, continue+break, or something else entirely?
- [ ] Is it ok for the two traits to be tied together closely, as outlined here, or should they be split up further to allow types that can be only-created or only-destructured?

From experience in nightly:
- [ ] Should there be a trait requirement on residuals of any kind?  It's currently possible to accidentally be `FromResidual` from a type that's never actually produced as a residual (https://github.com/SergioBenitez/Rocket/pull/1645).  But that would add more friction for cases not using the `Foo<!>` pattern, so may not be worth it.
  - Given the trait in #91286, that might look like changing the associated `type Residual;` to `type Residual: Residual<Self::Output>;`.

### Implementation history

<!--
Include a list of all the PRs that were involved in implementing the feature.
-->

- [x] Basic traits and impls added, https://github.com/rust-lang/rust/pull/84092
- [x] Removing `try_trait` from `stdarch`, https://github.com/rust-lang/stdarch/pull/1142
- [x] Implementing the desugaring, https://github.com/rust-lang/rust/pull/84767