Tracking Issue for `try_trait_v2`, A new design for the `?` desugaring (RFC#3058)

[scottmcm]

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 rust-lang/rfcs#1859, tracked in #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

• Implement the RFC
  • Add the new traits and impls
  • Update the desugar in ast lowering
  • Fixup all the tests
  • Add nice error messages in inference
  • Improve perf with enough MIR optimizations
  • Delete the old way after a bootstrap update Remove the TryV2 alias #88223
• Not strictly needed, but a mir-opt to simplify the matches would really help: LLVM/MIR optimizations to simplify the new RFC3058 ? desugaring #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
• Fix rustdoc to show the default type parameter on FromResidual better (Issue rustdoc removes Try from <Self as Try>::Residual in std::ops::FromResidual #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 Document implementing try_fold for iterators for internal iteration #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)
• Stabilization PR (see instructions on rustc-dev-guide)

Unresolved Questions

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 (Fix the types in one of the FromResidual implementations rwf2/Rocket#1645). But that would add more friction for cases not using the Foo<!> pattern, so may not be worth it.
  • Given the trait in Make array::{try_from_fn, try_map} and Iterator::try_find generic over Try #91286, that might look like changing the associated type Residual; to type Residual: Residual<Self::Output>;.

Implementation history

• Basic traits and impls added, Add the try_trait_v2 library basics #84092
• Removing try_trait from stdarch, Remove #![feature(try_trait)] from a test stdarch#1142
• Implementing the desugaring, Implement the new desugaring from try_trait_v2 #84767