Rollup of 9 pull requests
Successful merges:
- #135354 ([Debuginfo] Add MSVC Synthetic and Summary providers to LLDB)
- #136826 (Replace mem::zeroed with mem::MaybeUninit::uninit for large struct in Unix)
- #137194 (More const {} init in thread_local)
- #137334 (Greatly simplify lifetime captures in edition 2024)
- #137382 (bootstrap: add doc for vendor build step)
- #137423 (Improve a bit HIR pretty printer)
- #137435 (Fix "missing match arm body" suggestion involving `!`)
- #137448 (Fix bugs due to unhandled `ControlFlow` in compiler)
- #137458 (Fix missing self subst when rendering `impl Fn*<T>` with no output type)
r? `@ghost`
`@rustbot` modify labels: rollup
Improve a bit HIR pretty printer
This PR improve (a bit) the HIR pretty printer.
It does so by:
- Not printing elided lifetimes (those are not expressible in surface Rust anyway)
- And by rendering implicit self with the shorthand syntax
I also tried fixing some indentation and other things but gave up for now.
Best reviewed commit by commit.
Replace mem::zeroed with mem::MaybeUninit::uninit for large struct in Unix
As discussion in #136737.
- Replace `mem::zeroed()` with `MaybeUninit::uninit()` for `sockaddr_storage` in `accept()` and `recvfrom()` since these functions fill in the address structure
- Replace `mem::zeroed()` with `MaybeUninit::uninit()` for `pthread_attr_t` in thread-related functions since `pthread_attr_init()` initializes the structure
- Add references to man pages to document this behavior
[Debuginfo] Add MSVC Synthetic and Summary providers to LLDB
Adds handling for `tuple$<>`, `ref$<slice$2<>`, `ref$<str$>` and `enum2$<>`.
Also fixes a bug in MSVC vec/string handling where the script was unable to determine the element's type due to LLDB ignoring template arg debug information
<details>
<summary>Sample code</summary>
```rust
pub enum Number {
One = 57,
Two = 99,
}
#[repr(u8)]
pub enum Container {
First(u32),
Second { val: u64, val2: i8 },
Third,
}
...
let u8_val = b'a';
let float = 42.78000000000001;
let tuple = (u8_val, float);
let str_val = "eef";
let mut string = "freef".to_owned();
let mut_str = string.as_mut_str();
let array: [u8; 4] = [1, 2, 3, 4];
let ref_array = array.as_slice();
let mut array2: [u32; 4] = [1, 2, 3, 4];
let mut_array = array2.as_mut_slice();
let enum_val = Number::One;
let mut enum_val2 = Number::Two;
let sum_val = Container::First(15);
let sum_val_2 = Container::Second { val: 0, val2: 0 };
let sum_val_3 = Container::Third;
let non_zero = NonZeroU128::new(100).unwrap();
let large_discr = NonZeroU128::new(255);
```
</details>
Before:

After:

try-job: aarch64-apple
try-job: x86_64-msvc-1
try-job: i686-msvc-1
try-job: x86_64-mingw-1
try-job: i686-mingw
try-job: aarch64-gnu
stabilize stage management for rustc tools
https://github.com/rust-lang/rust/pull/135990 got out of control due to excessive complexity. This PR aims to achieve the same goal with a simpler approach, likely through multiple smaller PRs. I will keep the other one read-only and open as a reference for future work.
This work stabilizes the staging logic for `ToolRustc` programs, so you no longer need to handle build and target compilers separately in steps. Previously, most tools didn't do this correctly, which was causing the compiler to be built twice (e.g., `x test cargo --stage 1` would compile the stage 2 compiler before, but now it only compiles the stage 1 compiler).
I also tried to document how we should write `ToolRustc` steps as they are quite different and require more attention than other tools.
Next goal is to stabilize how stages are handled for the rustc itself. Currently, `x build --stage 1` builds the stage 1 compiler which is fine, but `x build compiler --stage 1` builds stage 2 compiler.
~~for now, r? ghost~~
Remove `NtVis` and `NtTy`
The next part of #124141. The first actual remove of `Nonterminal` variants. `NtVis` is a simple case that doesn't get much use, but `NtTy` is more complex.
r? `@petrochenkov`
Emit `trunc nuw` for unchecked shifts and `to_immediate_scalar`
- For shifts this shrinks the IR by no longer needing an `assume` while still providing the UB information
- Having this on the `i8`→`i1` truncations will hopefully help with some places that have to load `i8`s or pass those in LLVM structs without range information
Bump sccache in CI to 0.9.1
We haven't updated the used sccache version for years, it has accrued a bunch of fixes and features in the meantime. It now supports the `--show-adv-stats` flag, which gives a more detailed summary of the results of caching. And it can also cache Rust code, which could be useful in the future (https://github.com/rust-lang/rust/pull/136942 - although now there are no large wins).
It also supports caching PGO now, but since the PGO profiles are always different, it won't make any real difference.
https://github.com/rust-lang/rust/pull/133076 previously tried to update the version to 0.3 (CC `@klensy)`
r? `@marcoieni`
Organize `OsString`/`OsStr` shims
Synchronize the `bytes.rs` and `wtf8.rs` shims for `OsString`/`OsStr` so they're easier to diff between each other. This is mostly ordering items the same between the two. I tried to minimize moves and went for the average locations between the files.
With them in the same order, it is clear that `FromInner<_>` is not implemented for `bytes::Buf` and `Clone::clone_from` is not implemented for `wtf8::Buf`, but they are for the other. Fix that.
I added #[inline] to all inherent methods of the `OsString`/`OsStr` shims, because it seemed that was already the rough pattern. `bytes.rs` has more inlining than `wtf8.rs`, so I added the corresponding ones to `wtf8.rs`. Then, the common missing ones have no discernible pattern to me. They're not divided by non-allocating/allocating. Perhaps the pattern is that UTF-8 validation isn't inlined? Since these types are merely the inner values in `OsStr`/`OsString`, I put inline on all methods and let those public types dictate inlining. I have not inspected codegen or run benchmarks.
Also, touch up some (private) documentation comments.
r? ``````@ChrisDenton``````
Lint `#[must_use]` attributes applied to methods in trait impls
The `#[must_use]` attribute has no effect when applied to methods in trait implementations. This PR adds it to the unused `#[must_use]` lint, and cleans the extra attributes in portable-simd and Clippy.
CI: Stop /msys64/bin from being prepended to PATH in msys2 shell
We used to do this along time ago but we stopped doing it when we started installing msys2 manually. 4fd3cf96a1/src/ci/scripts/install-msys2.sh (L11-L13)Fixes#136795
try-job: dist-i686-mingw
Use more explicit and reliable ptr select in sort impls
Using `if ...` with the intent to avoid branches can be surprising to readers and carries the risk of turning into jumps/branches generated by some future compiler version, breaking crucial optimizations.
This commit replaces their usage with the explicit and IR annotated `bool::select_unpredictable`.
Add `MAX_LEN_UTF8` and `MAX_LEN_UTF16` Constants
This pull request adds the `MAX_LEN_UTF8` and `MAX_LEN_UTF16` constants as per #45795, gated behind the `char_max_len` feature.
The constants are currently applied in the `alloc`, `core` and `std` libraries.
coverage: Get hole spans from nested items without fully visiting them
This is a small simplification to the code that collects the spans of nested items within a function, so that those spans can be treated as “holes” to be avoided by the current function's coverage mappings.
The old code was using `nested_filter::All` to ensure that the visitor would see nested items. But we don't need the actual items themselves; we just need their spans, which we can obtain via a custom implementation of `visit_nested_item`.
This avoids the more expansive queries required by `nested_filter::All`.
Don't mention `FromResidual` on bad `?`
Unless `try_trait_v2` is enabled, don't mention that `FromResidual` isn't implemented for a specific type when the implicit `From` conversion of a `?` fails. For the end user on stable, `?` might as well be a compiler intrinsic, so we remove that note to avoid further confusion and allowing other parts of the error to be more prominent.
```
error[E0277]: `?` couldn't convert the error to `u8`
--> $DIR/bad-interconversion.rs:4:20
|
LL | fn result_to_result() -> Result<u64, u8> {
| --------------- expected `u8` because of this
LL | Ok(Err(123_i32)?)
| ------------^ the trait `From<i32>` is not implemented for `u8`
| |
| this can't be annotated with `?` because it has type `Result<_, i32>`
|
= note: the question mark operation (`?`) implicitly performs a conversion on the error value using the `From` trait
= help: the following other types implement trait `From<T>`:
`u8` implements `From<Char>`
`u8` implements `From<bool>`
```
Add a bullet point to `std::fs::copy`
I needed to copy a file but I got the following error:
```
Os { code: 2, kind: NotFound, message: "No such file or directory" }
```
After read the documentation, I though the error was generated by the `from` parameter, forgetting the `to` part. Anyway, I got the error because the parent folder of `to` didn't exist.
Even if the documentation explicitly saying `but is not limited to just these cases`, I would like to add this case because I spent 3 hours around it.
This PR just wants to put a mention about it.
Added project-specific Zed IDE settings
This repository currently has project-specific VS Code IDE settings in `.vscode` and `compiler/rustc_codegen_cranelift/.vscode`. Now there are equivalent project-specific Zed IDE settings alongside those.
This fixes `rust-analyzer` not being able to properly handle this project.
Note that:
1. The contents of `src/tools/rust-analyzer/.vscode` could not be translated to Zed, as they aren't basic IDE settings.
2. One of the VS Code settings in `.vscode` has no corresponding setting in Zed, and so this has been noted like this:
```json
"_settings_only_in_vs_code_not_yet_in_zed": {
"git.detectSubmodulesLimit": 20
},
```
improve cold_path()
#120370 added a new instrinsic `cold_path()` and used it to fix `likely` and `unlikely`
However, in order to limit scope, the information about cold code paths is only used in 2-target switch instructions. This is sufficient for `likely` and `unlikely`, but limits usefulness of `cold_path` for idiomatic rust. For example, code like this:
```
if let Some(x) = y { ... }
```
may generate 3-target switch:
```
switch y.discriminator:
0 => true branch
1 = > false branch
_ => unreachable
```
and therefore marking a branch as cold will have no effect.
This PR improves `cold_path()` to work with arbitrary switch instructions.
Note that for 2-target switches, we can use `llvm.expect`, but for multiple targets we need to manually emit branch weights. I checked Clang and it also emits weights in this situation. The Clang's weight calculation is more complex that this PR, which I believe is mainly because `switch` in `C/C++` can have multiple cases going to the same target.
Rollup of 7 pull requests
Successful merges:
- #137095 (Replace some u64 hashes with Hash64)
- #137100 (HIR analysis: Remove unnecessary abstraction over list of clauses)
- #137105 (Restrict DerefPure for Cow<T> impl to T = impl Clone, [impl Clone], str.)
- #137120 (Enable `relative-path-include-bytes-132203` rustdoc-ui test on Windows)
- #137125 (Re-add missing empty lines in the releases notes)
- #137145 (use add-core-stubs / minicore for a few more tests)
- #137149 (Remove SSE ABI from i586-pc-windows-msvc)
r? `@ghost`
`@rustbot` modify labels: rollup
Restrict DerefPure for Cow<T> impl to T = impl Clone, [impl Clone], str.
Fixes#136046
`feature(deref_patterns)` tracking issue: https://github.com/rust-lang/rust/issues/87121
`Cow<'_, T>` should only implement `DerefPure` if its `Deref` impl is pure, which requires `<T::Owned as Borrow<T>>::borrow` to be pure. This PR restricts `impl DerefPure for Cow<'_, T>` to `T: Sized + Clone`, `T = [U: Clone]`, and `T = str` (for all of whom `<T::Owned as Borrow<T>>::borrow` is implemented in the stdlib and is pure).
cc ``@Nadrieril``
------
An alternate approach would be to introduce a new `unsafe trait BorrowPure<T>` analogous to `DerefPure` that could be implemented for `T: Sized`, `&T`, `&mut T`, `String`, `Vec`, `Box`, `PathBuf`, `OsString`, etc. https://github.com/rust-lang/rust/compare/master...zachs18:borrow-pure-trait
HIR analysis: Remove unnecessary abstraction over list of clauses
`rustc_hir_analysis::bounds::Bounds` with its methods is nowadays a paper-thin wrapper around `Vec<(Clause, Span)>`s and `Vec::push` essentially.
Its existence slightly annoyed me (and I keep opening its corresp. file instead of the identically named `bounds.rs` in `hir_ty_lowering/` that I actually want most of the time :P).
Opening to check if you agree with inlining it.
r? compiler-errors or reassign
Replace some u64 hashes with Hash64
I introduced the Hash64 and Hash128 types in https://github.com/rust-lang/rust/pull/110083, essentially as a mechanism to prevent hashes from landing in our leb128 encoding paths. If you just have a u64 or u128 field in a struct then derive Encodable/Decodable, that number gets leb128 encoding. So if you need to store a hash or some other value which behaves very close to a hash, don't store it as a u64.
This reverts part of https://github.com/rust-lang/rust/pull/117603, which turned an encoded Hash64 into a u64.
Based on https://github.com/rust-lang/rust/pull/110083, I don't expect this to be perf-sensitive on its own, though I expect that it may help stabilize some of the small rmeta size fluctuations we currently see in perf reports.
Fix const items not being allowed to be called `r#move` or `r#static`
Because of an ambiguity with const closures, the parser needs to ensure that for a const item, the `const` keyword isn't followed by a `move` or `static` keyword, as that would indicate a const closure:
```rust
fn main() {
const move // ...
}
```
This check did not take raw identifiers into account, therefore being unable to distinguish between `const move` and `const r#move`. The latter is obviously not a const closure, so it should be allowed as a const item.
This fixes the check in the parser to only treat `const ...` as a const closure if it's followed by the *proper keyword*, and not a raw identifier.
Additionally, this adds a large test that tests for all raw identifiers in all kinds of positions, including `const`, to prevent issues like this one from occurring again.
fixes#137128
Use `const_error!` when possible
Replace usages of `io::Error::new(io::ErrorKind::Variant, "constant string")` with `io::const_error!(io::ErrorKind::Variant, "constant string")` to avoid allocations when possible. Additionally, fix `&&str` error messages in SGX and missing/misplaced trailing commas in `const_error!`.
Pattern Migration 2024: clean up and comment
This follows up on #136577 by moving the pattern migration logic to its own module, removing a bit of unnecessary complexity, and adding comments. Since there's quite a bit of pattern migration logic now (and potentially more in #136496), I think it makes sense to keep it separate from THIR construction, at least as much as is convenient.
r? ``@Nadrieril``
Overhaul `rustc_middle::limits`
In particular, to make `pattern_complexity` work more like other limits, which then enables some other simplifications.
r? ``@Nadrieril``
Start removing `rustc_middle::hir::map::Map`
`rustc_middle::hir::map::Map` is now just a low-value wrapper around `TyCtxt`. This PR starts removing it.
r? `@cjgillot`
The end goal is to eliminate `Map` altogether.
I added a `hir_` prefix to all of them, that seemed simplest. The
exceptions are `module_items` which became `hir_module_free_items` because
there was already a `hir_module_items`, and `items` which became
`hir_free_items` for consistency with `hir_module_free_items`.
rustdoc: improve refdef handling in the unresolved link lint
This commit takes advantage of a feature in pulldown-cmark that makes the list of link definitions available to the consuming application. It produces unresolved link warnings for refdefs that aren't used, and can now produce exact spans for the dest even when it has escapes.
Closes#133150 since this lint would have caught the mistake in that issue, and, along with https://github.com/rust-lang/rust-clippy/pull/13707, most mistakes in this class should produce a warning from one of them.
Rollup of 8 pull requests
Successful merges:
- #127581 (Fix crate name validation)
- #136490 (Do not allow attributes on struct field rest patterns)
- #136808 (Try to recover from path sep error in type parsing)
- #137055 (rustdoc: Properly restore search input placeholder)
- #137068 (fix(rustdoc): Fixed `Copy Item Path` in rust doc)
- #137070 (Do not generate invalid links in job summaries)
- #137074 (compiletest: add `{ignore,only}-rustc_abi-x86-sse2` directives)
- #137076 (triagebot.toml: ping me on changes to `tests/rustdoc-json`)
r? `@ghost`
`@rustbot` modify labels: rollup