Fix cycle when debug-printing opaque types
Fixes#61577
When printing an opaque type in non-verbose mode, we use the
`tcx.predicates_of` query to retrieve the opaque type's bounds for
pretty-printing. However, the pervasiveness of logging within librustc
means that we may already be executing `tcx.predicates_of` for the
opaque type we're trying to print, leading to a cycle error.
This commit adds a new 'no queries' thread-local flag to the pretty
printer. This flag is enabled during the computation of `predicates_of`
for opaque types, and causes us to print the opaque type in 'verbose'
mode (which does not require computing any additinal queries). This
should only affect debug logging for highly nested log messages, not any
user-visible output.
Scope format! temporaries
This places the temporaries that `format!` generates to refer to its arguments (through `&dyn Trait`) in a short-lived scope surrounding just the invocation of `format!`. This enables `format!` to be used in generators without the temporaries preventing the generator from being `Send` (due to `dyn Trait` not being `Sync`).
See rust-lang/rust#64477 for details.
Rollup of 5 pull requests
Successful merges:
- #61351 (Stabilize cfg(doc))
- #66539 (Point at type in `let` assignment on type errors)
- #66655 (rustdoc: Mark `--extern-private` as unstable)
- #66657 (rustdoc: Don't panic when failing to write .lock file)
- #66673 (Move def collector from `rustc` to `rustc_resolve`)
Failed merges:
r? @ghost
Move def collector from `rustc` to `rustc_resolve`
It's used only from `rustc_resolve`, so we can move it there, thus reducing the size of `rustc` (https://github.com/rust-lang/rust/issues/65031).
It's quite possible that we can merge the def collector pass into the "build reduced graph" pass (they are always run together and do similar things), but it's some larger work.
r? @eddyb
rustdoc: Don't panic when failing to write .lock file
It can be treated like any other unexpected IO error.
I couldn't think of a good way to add a test for this unfortunately.
r? @GuillaumeGomez
debuginfo: Support for std::collections::Hash* in windows debuggers.
Okay, I finally needed to debug code involving a HashMap! Added support for HashSet s as well.
r? @michaelwoerister
### Local Testing
Verified these are passing locally:
```cmd
:: cmd.exe
python x.py test --stage 1 --build x86_64-pc-windows-msvc src/test/debuginfo
python x.py test --stage 1 --build i686-pc-windows-msvc src/test/debuginfo
python x.py test --stage 1 src/tools/tidy
:: MinGW MSYS2
./x.py test --stage 1 --build x86_64-pc-windows-gnu src/test/debuginfo
```
### Related Issues
* https://github.com/rust-lang/rust/issues/36503
* https://github.com/rust-lang/rust/issues/40460
* https://github.com/rust-gamedev/wg/issues/20
Clarify Step Documentation
While the redesign is in progress (#62886), clarify the purpose of replace_zero and replace_one.
First, "returning itself" is technically impossible due to the function signature of &mut self -> Self. A clone or copy operation must be used. So this is now explicitly stated in the documentation.
Second, the added docs give some guidance about the actual contract around implementation of replace_zero and replace one. Specifically, the only usage is to create a range with no more steps, by setting start to replace_one and end to replace_zero. So the only property that is actually used is `replace_one > replace_zero`. See https://github.com/rust-lang/rust/issues/42168#issuecomment-489554232
The new documentation does not say that is the *only* contract, and so it should not be considered an api change. It just highlights the most important detail for implementors.
The redesign doesn't seem to be landing any time soon, so this is a stopgap measure to reduce confusion in the meantime.
