Rollup of 6 pull requests
Successful merges:
- rust-lang/rust#148234 (rustdoc: make mergeable crate info more usable)
- rust-lang/rust#149201 (Add suggest alternatives for Out-of-range \x escapes)
- rust-lang/rust#149208 ([rustdoc] Make more functions return `fmt::Result` and reduce number of `.unwrap()` calls)
- rust-lang/rust#149252 (miri: use `tikv-jemalloc-sys` from sysroot)
- rust-lang/rust#149255 (Use `let...else` consistently in user-facing diagnostics)
- rust-lang/rust#149275 (Fix missing double-quote in `std::env::consts::OS` values)
r? `@ghost`
`@rustbot` modify labels: rollup
Use `let...else` consistently in user-facing diagnostics
resolve: rust-lang/rust#148772
Standardize `let...else` terminology in user-facing diagnostics.
Goal: Consistently use `let...else` in all error/warning messages.
Internal technical names (`let-else`) in comments and documentation remain unchanged.
cc ``@carols10cents,`` ``@jieyouxu``
[rustdoc] Make more functions return `fmt::Result` and reduce number of `.unwrap()` calls
Following our discussion in https://github.com/rust-lang/rust/pull/149028#discussion_r2550675531, this PR makes more function return `fmt::Result`, allowing to use `?` a lot more, and also reducing number of `.unwrap()` calls.
r? `@lolbinarycat`
rustdoc: make mergeable crate info more usable
Part of https://github.com/rust-lang/rust/issues/130676
Adds documentation and a feature change aimed at making this usable without breaking backwards compat.
cc ``@EtomicBomb``
This allows LTO to work when compiling jemalloc, which should yield a
small performance boost, and makes miri's behaviour here match clippy
and rustdoc.
[Debugger Visualizers] Unify `*-gnu` and `*-msvc` enum output
Followup patch to rust-lang/rust#145218
Ports the msvc enum synthetic/summary logic to the gnu handlers so they have identical output. Also removes the "look-through-pointers" logic that caused rust-lang/rust#147450
<img width="629" height="220" alt="image" src="https://github.com/user-attachments/assets/d6ae44d5-232f-412d-b291-64ac52850c74" />
I know we don't run the test suite in CI anymore, but it's still useful locally so I updated the relevant tests.
Add doc aliases "vector" and "list" to `Vec`
- "vector" is what "vec" is short form for.
- "list" is a common name for this concept in a lot of other languages (`ArrayList` in Java, `list` in Python, `List` in C#). C++ uses the term for a linked list (`std::list`), so maybe this is contentious?
I believe that this falls under [the doc alias policy](https://std-dev-guide.rust-lang.org/policy/doc-alias.html), and I think it's plausible that a newcomer would search for either of these terms, and expect to find `Vec`.
r? libs
Fix MaybeUninit codegen using GVN
This is an alternative to https://github.com/rust-lang/rust/pull/142837, based on https://github.com/rust-lang/rust/pull/146355#discussion_r2421651968.
The general approach I took here is to aggressively propagate anything that is entirely uninitialized. GVN generally takes the approach of only synthesizing small types, but we need to generate large consts to fix the codegen issue.
I also added a special case to MIR dumps for this where now an entirely uninit const is printed as `const <uninit>`, because otherwise we end up with extremely verbose dumps of the new consts.
After GVN though, we still end up with a lot of MIR that looks like this:
```
StorageLive(_1);
_1 = const <uninit>;
_2 = &raw mut _1;
```
Which will break tests/codegen-llvm/maybeuninit-rvo.rs with the naive lowering. I think the ideal fix here is to somehow omit these `_1 = const <uninit>` assignments that come directly after a StorageLive, but I'm not sure how to do that. For now at least, ignoring such assignments (even if they don't come right after a StorageLive) in codegen seems to work.
Note that since GVN is based on synthesizing a `ConstValue` which has a defined layout, this scenario still gets deoptimized by LLVM.
```rust
#![feature(rustc_attrs)]
#![crate_type = "lib"]
use std::mem::MaybeUninit;
#[unsafe(no_mangle)]
pub fn oof() -> [[MaybeUninit<u8>; 8]; 8] {
#[rustc_no_mir_inline]
pub fn inner<T: Copy>() -> [[MaybeUninit<T>; 8]; 8] {
[[MaybeUninit::uninit(); 8]; 8]
}
inner()
}
```
This case can be handled correctly if enough inlining has happened, or it could be handled by post-mono GVN. Synthesizing `UnevaluatedConst` or some other special kind of const seems dubious.
Major changes:
- `GoalSource::InstantiateHigherRanked` was removed.
- `Interner::UnevaluatedConstId` was introduced, allowing further simplifications due to better typing. Generally we don't represent unevaluated consts like we should, but it's still better.
- `PatternKind::NotNull` was introduced.
Turn moves into copies after copy propagation
Previously copy propagation presumed that there is further unspecified distinction between move operands and copy operands in assignments and propagated moves from assignments into terminators. This is inconsistent with current operational semantics.
Turn moves into copies after copy propagation to preserve existing behavior.
Fixes https://github.com/rust-lang/rust/issues/137936.
Fixes https://github.com/rust-lang/rust/issues/146423.
r? `@cjgillot`
Auto-loaded via the debugger_visualizer attribute.
Tested on smolstr's unittest:
$ RUSTFLAGS="-C debuginfo=2 -C opt-level=0" cargo test -p smol_str --no-run
$ rust-gdb target/debug/deps/test-a806b111557a7133
(gdb) break test::conversions
(gdb) run
(gdb) next
(gdb) print s
(and other locations in that file, to test the three cases: Inline,
Static and Heap)
- Discussed in https://github.com/rust-lang/rust-analyzer/issues/21107
- Avoids activating an `attributes` feature to crates that do not use it
- Updates the 6 crates that use attributes feature to specify it in
their Cargo.toml: {hir,hir-def,hir-ty,ide-assists,ide-db,project-model}
