1. 22 6月, 2022 1 次提交
    • A
      Reverse folder hierarchy · 6ac6866b
      Alan Egerton 提交于
      #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
      6ac6866b
  2. 21 6月, 2022 28 次提交
  3. 20 6月, 2022 11 次提交