Rollup of 9 pull requests
Successful merges:
- rust-lang/rust#143019 (Ensure -V --verbose processes both codegen_backend and codegen-backend)
- rust-lang/rust#143140 (give Pointer::into_parts a more scary name and offer a safer alternative)
- rust-lang/rust#143175 (Make combining LLD with external LLVM config a hard error)
- rust-lang/rust#143180 (Use `tracing-forest` instead of `tracing-tree` for bootstrap tracing)
- rust-lang/rust#143223 (Improve macro stats printing)
- rust-lang/rust#143228 (Handle build scripts better in `-Zmacro-stats` output.)
- rust-lang/rust#143229 ([COMPILETEST-UNTANGLE 1/N] Move some some early config checks to the lib and move the compiletest binary)
- rust-lang/rust#143246 (Subtree update of `rust-analyzer`)
- rust-lang/rust#143248 (Update books)
r? `@ghost`
`@rustbot` modify labels: rollup
Handle build scripts better in `-Zmacro-stats` output.
Currently all build scripts are listed as `build_script_build` in the stats header. This commit uses `CARGO_PKG_NAME` to improve that.
I tried it on Bevy, it works well, giving output like this on the build script:
```
MACRO EXPANSION STATS: serde build script
```
and this on the crate itself:
```
MACRO EXPANSION STATS: serde
```
r? `@Kobzol`
give Pointer::into_parts a more scary name and offer a safer alternative
`into_parts` is a bit too innocent of a name for a somewhat subtle operation.
r? `@oli-obk`
Do not freshen `ReError`
Because `ReError` has `ErrorGuaranteed` in it, it affects candidate selection and thus causes incompleteness which leads to weirdness in eval. See the comment in the test.
Also remove an unnecessary `lookup_op_method` since it doesn't effect tests.
Fixesrust-lang/rust#132882.
r? types
Currently all build scripts are listed as `build_script_build` in the
stats header. This commit uses `CARGO_PKG_NAME` to improve that.
I tried it on Bevy, it works well, giving output like this on the build
script:
```
MACRO EXPANSION STATS: serde build script
```
and this on the crate itself:
```
MACRO EXPANSION STATS: serde
```
Shallowly bail from `coerce_unsized` more
We do a *lot* of coercion in HIR typeck. Most of the time we're just coercing a type to itself, but we always try `coerce_unsized` even if it's not necessary.
Let's avoid doing that by adding a fast path to `coerce_unsized`; see the comment in that function.
Fix suggestion spans inside macros for the `unused_must_use` lint
This PR fixes the suggestion spans inside macros for the `unused_must_use` lint by trying to find the oldest ancestor span.
Fixes https://github.com/rust-lang/rust/issues/143025
Add SIMD funnel shift and round-to-even intrinsics
This PR adds 3 new SIMD intrinsics
- `simd_funnel_shl` - funnel shift left
- `simd_funnel_shr` - funnel shift right
- `simd_round_ties_even` (vector version of `round_ties_even_fN`)
TODO (future PR): implement `simd_fsh{l,r}` in miri, cg_gcc and cg_clif (it is surprisingly hard to implement without branches, the common tricks that rotate uses doesn't work because we have 2 elements now. e.g, the `-n&31` trick used by cg_gcc to implement rotate doesn't work with this because then `fshl(a, b, 0)` will be `a | b`)
[#t-compiler > More SIMD intrinsics](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/More.20SIMD.20intrinsics/with/522130286)
`@rustbot` label T-compiler T-libs A-intrinsics F-core_intrinsics
r? `@workingjubilee`
Remove unused feature gates
After finding some unused feature gates in rust-lang/rust#143155 , I wrote a small script to see if I can find any others.
And I did. Not a lot, but still a small win 😁
Contains a few instances of `iter_from_coroutine` that can be removed due to rust-lang/rust#142801 (I guess).
Improve documentation of `TagEncoding`
This PR is follow-up from the [discussion here](https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/.E2.9C.94.20VariantId.3DDiscriminant.20when.20tag.20is.20niche.20encoded.3F/with/524384295).
It aims at making the `TagEncoding` documentation less ambiguous and more detailed with references to relevant implementation sides. It especially clears up the ambiguous use of discriminant/variant index, which sparked the discussion referenced above.
PS: While working with layout data, I somehow ended up looking at the docs for `FakeBorrowKind` and noticed that the one example was not in a doc comment. I hope that this is minor enough of a fix for it to be okay in this otherwise unrelated PR.
Use tidy to sort `sym::*` items
Use tidy to sort the symbols in the invocation of `symbols!`, instead of implementing the ordering check inside the proc macro.
(asked `````@nnethercote````` about this on zulip, he didn't have any reservations about making this change)
This has a couple of benefits:
- tidy's "version sort" (thanks to rust-lang/rust#141311 !) is nicer than the naive-cmp sort, so, e.g. `AtomicI{8, 16, 32, 64, 128}` are properly sorted by bit width.
- consistency with the rest of the repo
- allows us to remove a bit of order-verifying code from the `symbols!` proc macro impl
Do not include NUL-terminator in computed length
This PR contains just the first commit of rust-lang/rust#142579 which changes it so that the string length stored in the `Location` is the length of the `&str` rather than the length of the `&CStr`. Since most users will want the `&str` length, it seems better to optimize for that use-case.
There should be no visible changes in the behavior or API.
Only compute recursive callees once.
Inlining MIR in a cyclic call graph may create query cycles, which are ICEs. The current implementation `mir_callgraph_reachable(inlining_candidate, being_optimized)` checks if calling `inlining_candidate` may cycle back to `being_optimized` that we are currently inlining into.
This PR replaces this device with query `mir_callgraph_cyclic(being_optimized)` which searches the call graph for all cycles going back to `being_optimized`, and returns the set of functions involved in those cycles.
This is a tradeoff:
- in the current implementation, we perform more walks, but shallower;
- in this new implementation, we perform fewer walks, but exhaust the graph.
I'd have liked to compute this using some kind of SCC, but generic parameters make resolution path-dependent, so usual graph algorithms do not apply.
