mono collector: Reduce # of locking while walking the graph
While profiling Zed's dev build I've noticed that while most of the time `upstream_monomorphizations` takes a lot of time in monomorpization_collector, in some cases (e.g. build of `editor` itself) the rest of monomorphization_collector_graph_walk dominates it. Most of the time is spent in collect_items_rec.
This PR aims to reduce the number of locks taking place; instead of locking output MonoItems once per children of current node, we do so once per *current node*. We also get to reuse locks for mentioned and used items. While this commit does not reduce Wall time of Zed's build, it does shave off CPU time (measured with `cargo build -j1`) from 48s to 47s. I've also tested it with parallel frontend against Zed and ripgrep and found no regressions.
Rollup of 9 pull requests
Successful merges:
- #140485 (Optimize the codegen for `Span::from_expansion`)
- #140509 (transmutability: merge contiguous runs with a common destination)
- #140519 (Use select in projection lookup in `report_projection_error`)
- #140521 (interpret: better error message for out-of-bounds pointer arithmetic and accesses)
- #140536 (Rename `*Guard::try_map` to `filter_map`.)
- #140550 (Stabilize `select_unpredictable`)
- #140563 (extend the list of registered dylibs on `test::prepare_cargo_test`)
- #140572 (Add useful comments on `ExprKind::If` variants.)
- #140574 (Add regression test for 133065)
r? `@ghost`
`@rustbot` modify labels: rollup
Use select in projection lookup in `report_projection_error`
Using `for_each_relevant_impl` doesn't actually select the correct impl; we can use `select` here to actually get the correct impl with certainty. Follow-up to https://github.com/rust-lang/rust/pull/140278.
r? oli-obk
Optimize the codegen for `Span::from_expansion`
See https://godbolt.org/z/bq65Y6bc4 for the difference. the new version is less than half the number of instructions.
Also tried fully writing the function by hand:
```rust
sp.ctxt_or_parent_or_marker != 0
&& (
sp.len_with_tag_or_marker == BASE_LEN_INTERNED_MARKER
|| sp.len_with_tag_or_marker & PARENT_TAG == 0
)
```
But that was no better than this PR's current use of `match_span_kind`.
I'm working on https://github.com/rust-lang/rust-clippy/issues/14542 and
I decided to name the lint `unnecessary_map` originally. However when I
ran the command, I got:
```
thread 'main' panicked at clippy_dev/src/new_lint.rs:450:5:
Lint `unnecessary_map` already defined in `/home/imperio/rust/clippy/clippy_lints/src/methods/mod.rs`
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
It's because there is already a `unnecessary_map_or`, which matches the
`.contains()` call. This PR strengthens this check.
changelog: Fix `new_lint` clippy command
r? @flip1995
Rollup of 12 pull requests
Successful merges:
- #134034 (handle paren in macro expand for let-init-else expr)
- #137474 (pretty-print: Print shebang at the top of the output)
- #138872 (rustc_target: RISC-V `Zfinx` is incompatible with `{ILP32,LP64}[FD]` ABIs)
- #139046 (Improve `Lifetime::suggestion`)
- #139206 (std: use the address of `errno` to identify threads in `unique_thread_exit`)
- #139608 (Clarify `async` block behaviour)
- #139847 (Delegate to inner `vec::IntoIter` from `env::ArgsOs`)
- #140159 (Avoid redundant WTF-8 checks in `PathBuf`)
- #140197 (Document breaking out of a named code block)
- #140389 (Remove `avx512dq` and `avx512vl` implication for `avx512fp16`)
- #140430 (Improve test coverage of HIR pretty printing.)
- #140507 (rustc_target: RISC-V: feature addition batch 3)
r? `@ghost`
`@rustbot` modify labels: rollup
