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
..
src	Rollup merge of #98311 - eggyal:reverse-folder-hierarchy, r=jackh726	2022-06-25 15:14:11 +02:00
Cargo.toml	remove currently unused deps	2022-06-13 22:20:51 +03:00