make mir dataflow graphviz dumps opt-in
This should save some MIR traversals and allocations that are not really needed.
Small win but noticeable locally. Let's see what LTO/PGO say.
r? `@ghost`
refactor(resolve): delete update_resolution function
The `{ resolution.single_imports.remove(); }` code block does not modify the `binding` of this `resolution`. Therefore, the result of `resolution.binding()` before and after `let t = f(self, resolution)` will remain the same, and it will always satisfy the result: `_ if old_binding.is_some() => return t` or `None => return t`.
And then we delete the `update_resolution` function because it only called once.
r? ``@petrochenkov``
Don't try to auto-bless 32-bit `mir-opt` tests on ARM Mac hosts
#112418 added special support for automatically blessing 32-bit output on 64-bit hosts, for the subset of `mir-opt` tests that are pointer-width-dependent.
This relies on the 64-bit host having some corresponding 32-bit target that can be built “easily”. For most 64-bit hosts this is fine, but ARM Macs don't have a corresponding 32-bit target. (There have never been 32-bit ARM Macs, and ARM Macs don't have the libraries needed for building `i686-apple-darwin`.)
There is an entry for `("i686-apple-darwin", "aarch64-apple-darwin")` in the list of corresponding 32-bit platforms, but this doesn't actually work on ARM Macs. Instead, the bootstrap invocation fails to build the necessary 32-bit target support, and nothing gets tested or blessed.
According to [this Zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Can't.20bless.20any.20mir-opt.20tests.20on.20aarch64.20Mac/near/367109789), that mapping was only added because the author assumed it would work. But since it doesn't actually work on ARM Macs, the solution is to just remove that mapping.
With the mapping removed, ARM Macs still can't auto-bless 32-bit output (they will see a warning instead), but at least they can now bless the output of `mir-opt` tests that don't care about pointer width.
Don't record adjustments twice in `note_source_of_type_mismatch_constraint`
We call `lookup_method` a few times in `note_source_of_type_mismatch_constraint`, but that function has side-effects to the typeck results. Replace it with a less side-effect-y variant of the function for use in diagnostics.
Specifically the ICE in #112532 happens because we're recording deref adjustments twice for a call receiver, which causes `ExprUseVisitor` to be angry.
Fixes#112532
Don't capture `&[T; N]` when contents isn't read
Fixes the check in #111831Fixes#112607, although I decided to test the root cause rather than including the example in the issue as a test.
cc `@BoxyUwU`
- replace tokio's env-filter with a smaller&simpler targets filter
- reshuffle logging infra a bit to make sure there's only a single place
where we read environmental variables
- use anyhow::Result in rust-analyzer binary
Switch the BB CFG cache from postorder to RPO
The `BasicBlocks` CFG cache is interesting:
- it stores a postorder, but `traversal::postorder` doesn't use it
- `traversal::reverse_postorder` does traverse the postorder cache backwards
- we do more RPO traversals than postorder traversals (around 20x on the perf.rlo benchmarks IIRC) but it's not cached
- a couple places here and there were manually reversing the non-cached postorder traversal
This PR switches the order of the cache, and makes a bit more use of it. This is a tiny win locally, but it's also for consistency and aesthetics.
r? `@ghost`
Rollup of 5 pull requests
Successful merges:
- #107200 (io: soften ‘at most one write attempt’ requirement in io::Write::write)
- #112667 (Move WF/ConstEvaluatable goal to clause)
- #112685 (std: only depend on dlmalloc for wasm*-unknown)
- #112722 (bootstrap: check for dry run when copying env vars for msvc)
- #112734 (Make `Bound::predicates` use `Clause`)
r? `@ghost`
`@rustbot` modify labels: rollup
Usage of `Pin::new_unchecked(&mut …)` is dangerous with `poll_fn`, even
though the `!Unpin`-infectiousness has made things smoother.
Nonetheless, there are easy ways to avoid the need for any `unsafe`
altogether, be it through `Box::pin`ning, or the `pin!` macro. Since the
latter only works within an `async` context, showing an example
artifically introducing one ought to help people navigate this subtlety
with safety and confidence.
