rust/compiler/rustc_middle
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
..
benches mv compiler to compiler/ 2020-08-30 18:45:07 +03:00
src Rollup merge of #98311 - eggyal:reverse-folder-hierarchy, r=jackh726 2022-06-25 15:14:11 +02:00
Cargo.toml Update to rebased rustc-rayon 0.4 2022-05-27 20:20:41 -07:00
README.md mv compiler to compiler/ 2020-08-30 18:45:07 +03:00

For more information about how rustc works, see the rustc dev guide.