Polonius: update to 0.12.1, fix more move errors false positives, update test expectations
This PR:
- updates `polonius-engine` to version 0.12.1 to fix some move errors false positives
- fixes a fact generation mistake creating the other move errors false positives
- updates the test expectations for the polonius compare-mode so that all (minus the 2 OOMs) ui tests pass again (matching the [analysis doc](https://hackmd.io/CjYB0fs4Q9CweyeTdKWyEg?view) starting at case 34)
In my opinion, this is safe to rollup.
r? @nikomatsakis
avoid creating unnecessary reference in Windows Env iterator
Discovered in https://github.com/rust-lang/miri/pull/1225: the Windows `Env` iterator violates Stacked Borrows by creating an `&u16`, turning it into a raw pointer, and then accessing memory outside the range of that type.
There is no need to create a reference here in the first place, so the fix is trivial.
Cc @JOE1994
Cc https://github.com/rust-lang/unsafe-code-guidelines/issues/134
Rename `librustc` to `librustc_middle`
Here we rename `librustc` to `librustc_middle`.
This crate is not nearly as large or central as it was previously and so it doesn't make much sense to give it such a central name as `librustc` ("the entry point to the compiler"). Moreover, there is already a `rustc` crate which is has the actual `fn main` of `rustc`, so having `librustc` is confusing relative to that.
r? @eddyb
Make `Visitor::visit_body` take a plain `&Body`
`ReadOnlyBodyAndCache` has replaced `&Body` in many parts of the code base that don't care about basic block predecessors. This includes the MIR `Visitor` trait, which I suspect resulted in many unnecessary changes in #64736. This reverts part of that PR to reduce the number of places where we need to pass a `ReadOnlyBodyAndCache`.
In the long term, we should either give `ReadOnlyBodyAndCache` more ergonomic name and replace all uses of `&mir::Body` with it at the cost of carrying an extra pointer everywhere, or use it only in places that actually need access to the predecessor cache. Perhaps there is an even nicer alternative.
r? @Nashenas88
This will fix the other move errors false positives:
emitting the fact at the start point caused accesses to be at the
same point as an initialization fact of the return place of a call
on the following block, which emitted an error.
Tweak `suggest_constraining_type_param`
Some of the bound restriction structured suggestions were incorrect while others had subpar output.
The only issue left is a suggestion for an already present bound when dealing with `const`s that should be handled independently.
Fix#69983.
#[link]: mention wasm_import_module instead of cfg
`#[link(cfg)]` is perma-unstable and is not documented anywhere else. It makes more sense to mention `wasm_import_module` here since it's stable.
This makes it harder to hit https://github.com/rust-lang/rust/issues/70538 (if it weren't for this text, I wouldn't even know this feature existed).
add test for 62220
Closes#62220
Adds a test for https://github.com/rust-lang/rust/issues/62220.
Im not sure whether `check-pass` is sufficient here. I didn't put `run-pass` in, as I'm afraid that'll fail due to the `unimplemented!()` return in the code.
Add Result<Result<T, E>, E>::flatten -> Result<T, E>
This PR makes this possible (modulo type inference):
```rust
assert_eq!(Ok(6), Ok(Ok(6)).flatten());
```
Tracking issue: #70142
<sub>largely cribbed directly from <https://github.com/rust-lang/rust/pull/60256></sub>
BTreeMap testing: introduce symbolic constants and use height consistently
Doesn't change what or how much is tested, except for some exact integer types, just for convenience and because `node::CAPACITY` is a usize.
r? @RalfJung
Russell Cohen