rust/compiler/rustc_trait_selection/src
Matthias Krüger 65187f51dc
Rollup merge of #98311 - eggyal:reverse-folder-hierarchy, r=jackh726
Reverse folder hierarchy

#91318 introduced a trait for infallible folders distinct from the fallible version.  For some reason (completely unfathomable to me now that I look at it with fresh eyes), the infallible trait was a supertrait of the fallible one: that is, all fallible folders were required to also be infallible.  Moreover the `Error` associated type was defined on the infallible trait!  It's so absurd that it has me questioning whether I was entirely sane.

This trait reverses the hierarchy, so that the fallible trait is a supertrait of the infallible one: all infallible folders are required to also be fallible (which is a trivial blanket implementation).  This of course makes much more sense!  It also enables the `Error` associated type to sit on the fallible trait, where it sensibly belongs.

There is one downside however: folders expose a `tcx` accessor method.  Since the blanket fallible implementation for infallible folders only has access to a generic `F: TypeFolder`, we need that trait to expose such an accessor to which we can delegate.  Alternatively it's possible to extract that accessor into a separate `HasTcx` trait (or similar) that would then be a supertrait of both the fallible and infallible folder traits: this would ensure that there's only one unambiguous `tcx` method, at the cost of a little additional boilerplate.  If desired, I can submit that as a separate PR.

r? ````@jackh726````
2022-06-25 15:14:11 +02:00
..
traits Rollup merge of #98311 - eggyal:reverse-folder-hierarchy, r=jackh726 2022-06-25 15:14:11 +02:00
autoderef.rs Filter OnceNote in diagnostic infra. 2022-03-20 20:36:26 +01:00
infer.rs Revert "Auto merge of #91491 - spastorino:revert-91354, r=oli-obk" 2021-12-12 12:34:46 +08:00
lib.rs Fix minor documentation typo 2022-06-20 03:30:21 +01:00
opaque_types.rs Rename the ConstS::val field as kind. 2022-06-14 13:06:44 +10:00