This will allow better strategies for use of memory and File handles. However, fully taking advantage of that is left to future work.

It's possible that a file in the directory is pending deletion. In that case we might succeed after a few attempts.

rust-lang#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

Co-authored-by: Wesley Wiser <wwiser@gmail.com>

Windows: Iterative `remove_dir_all`

This will allow better strategies for use of memory and File handles. However, fully taking advantage of that is left to future work.

Note to reviewer: It's probably best to view the `remove_dir_all_recursive` as a new function. The diff is not very helpful (imho).

Add a test for issue rust-lang#33172

Adds a test confirming that rust-lang#33172 has been fixed.

CDB has some surprising results as it looks like the supposedly unmangled static's symbol name is prefixed when it shouldn't be.

r? ```@wesleywiser```

Closes rust-lang#33172

Pull Derefer before ElaborateDrops

_Follow up work to rust-lang#97025 rust-lang#96549 rust-lang#96116 rust-lang#95887 #95649_

This moves `Derefer` before `ElaborateDrops` and creates a new `Rvalue` called `VirtualRef` that allows us to bypass many constraints for `DerefTemp`.

r? ``@oli-obk``

…nkov

Set relocation_model to Pic on emscripten target

So we can support dynamically linking libraries with Emscripten (otherwise we need to use nightly and `-Zbuild-std` to rebuild std with relocations).
```@sbc100```

…bank

Fix trait object reborrow suggestion

Fixes rust-lang#93596

Slightly generalizes the logic we use to suggest fix first implemented in rust-lang#95609, specifically when we have a `Sized` obligation that comes from a struct's unsized tail.

…notriddle

Transform help popup into a pocket menu

Just like we moved the settings menu into a "pocket menu", it's doing the same to the help popup.

You can test it [here](https://rustdoc.crud.net/imperio/help-pocket-menu/doc/foo/index.html) and here is a screenshot:

![Screenshot from 2022-06-20 20-58-29](https://user-images.githubusercontent.com/3050060/174663718-538e9d11-3bf9-48b2-8909-f9bfe75af135.png)

r? ```@jsha```

…jackh726

Reverse folder hierarchy

rust-lang#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``

…ing, r=oli-obk

Fix printing `impl trait` under binders

Before, we would render `impl for<'a> Trait<'a>` like `impl Trait<for<'a> 'a>`, lol.

…nant-cast, r=lcnr

Use correct substs in enum discriminant cast

Fixes rust-lang#97634

r? ``@lcnr``