Rustc pull #2263
Merged
Rustc pull #2263
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add amdgpu target Add amdgpu target to rustc and enable the LLVM target. Fix compiling `core` with the amdgpu: The amdgpu backend makes heavy use of different address spaces. This leads to situations, where a pointer in one addrspace needs to be casted to a pointer in a different addrspace. `bitcast` is invalid for this case, `addrspacecast` needs to be used. Fix compilation failures that created bitcasts for such cases by creating pointer casts (which creates an `addrspacecast` under the hood) instead. MCP: rust-lang/compiler-team#823 Tracking issue: #135024 Kinda related to the original amdgpu tracking issue #51575 (though that one has been closed for a while).
…-18, r=workingjubilee Portable SIMD subtree update r? `@workingjubilee`
…imulacrum,jieyouxu Always set the deployment target when building std `cc` has [a bug/feature](rust-lang/cc-rs#1171) (I guess depending on how you look at it) where the default deployment target is taken from the SDK instead of from `rustc`. This causes `compiler-builtins` to build `compiler-rt` with the wrong deployment target on iOS. I've been meaning to change how `cc` works in this regard, but that's a lengthy process, so let's fix it in bootstrap for now. The behaviour can be seen locally with `./x build library --set build.optimized-compiler-builtins=true` for various target triples, and then inspecting with `otool -l build/host/stage1/lib/rustlib/*/lib/libcompiler_builtins-*.rlib | rg 'minos|version'`. I have added a rmake test that ensures that we now have the same version everywhere. Fixes rust-lang/rust#128419 Fixes rust-lang/compiler-builtins#650 Fixes rust-lang/rust#136523 See also rust-lang/cargo#13115, rust-lang/cc-rs#1171, rust-lang/rust#136113 See rust-lang/rust#133092 (comment) for a description of how the change works. try-job: i686-gnu-1 try-job: i686-gnu-2 try-job: x86_64-apple-1 try-job: aarch64-apple try-job: dist-apple-various try-job: dist-aarch64-apple try-job: dist-various-2 try-job: x86_64-fuchsia
It seems it is left-over after some refactoring
…seems they are left-over after my PR)
…ulacrum ci: use ubuntu 24 for x86 large runners try-job: dist-powerpc64le-linux try-job: x86_64-gnu-debug try-job: dist-arm-linux try-job: x86_64-fuchsia try-job: x86_64-gnu-distcheck try-job: dist-x86_64-linux try-job: dist-x86_64-linux-alt
Only apply LTO to rustdoc at stage 2 It doesn't make much sense at stage 1, and it was broken anyway. This was implemented in rust-lang/rust#135832. The issue with LTO and stage 1 rustdoc was reported [here](https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/x.20test.20with.20lto.20.3D.20.22thin.22.20fails.20to.20build.20rustdoc.3F). r? `@onur-ozkan`
chore: update rustc-hash 2.1.0 to 2.1.1 This PR updates the rustc-hash crate to include a palliative fix for #135477. The discussion for this can be found in the issue and on rust-lang/rustc-hash#55. This PR is the output of running `cargo +nightly update [email protected]`. I ran all tests locally and they all seem to pass, with the exception of `tests/ui/process/nofile-limit.rs` which always fails on my setup. `@steffahn` `@orlp` and `@Noratrieb` all have full context on this, I'm opening the pull request trying to be helpful. I'm not sure if anything else needs to be done, like documentation I'm not aware of or running any special CIs but if I can do anything else please let me know!
Replace i686-unknown-redox target with i586-unknown-redox This change is related to rust-lang/rust#136495
Rustc dev guide subtree update r? ``@ghost``
…=oli-obk compiler: replace `ExternAbi::name` calls with formatters Most of these just format the ABI string, so... just format ExternAbi? This makes it more consistent and less jank when we can do it.
Put kobzol back on review rotation r? ``@ghost``
documentation fix: `f16` and `f128` are not double-precision
Rollup of 8 pull requests Successful merges: - #134981 ( Explain that in paths generics can't be set on both the enum and the variant) - #136698 (Replace i686-unknown-redox target with i586-unknown-redox) - #136767 (improve host/cross target checking) - #136829 ([rustdoc] Move line numbers into the `<code>` directly) - #136875 (Rustc dev guide subtree update) - #136900 (compiler: replace `ExternAbi::name` calls with formatters) - #136913 (Put kobzol back on review rotation) - #136915 (documentation fix: `f16` and `f128` are not double-precision) r? `@ghost` `@rustbot` modify labels: rollup
clarify and document needs-dynamic-linking try-job: test-various
… r=saethlin tests: `-Copt-level=3` instead of `-O` in assembly tests An effective blocker for redefining the meaning of `-O` is to stop reusing this somewhat ambiguous alias in our own assembly test suite. The choice between `-Copt-level=2` and `-Copt-level=3` is arbitrary for most of our tests. In most cases it makes no difference, so I set most of them to `-Copt-level=3`, as it will lead to slightly more "normalized" assembly.
…n-tests, r=saethlin tests: `-Copt-level=3` instead of `-O` in codegen tests An effective blocker for redefining the meaning of `-O` is to stop reusing this somewhat ambiguous alias in our own codegen test suite. The choice between `-Copt-level=2` and `-Copt-level=3` is arbitrary for most of our tests. In most cases it makes no difference, so I set most of them to `-Copt-level=3`, as it will lead to slightly more "normalized" codegen. try-job: test-various try-job: arm-android try-job: armhf-gnu try-job: i686-gnu-1 try-job: i686-gnu-2 try-job: i686-mingw try-job: i686-msvc-1 try-job: i686-msvc-2 try-job: aarch64-apple try-job: aarch64-gnu
…=GuillaumeGomez Nuke `Buffer` abstraction from `librustdoc`, take 2 💣 In rust-lang/rust#136656 I found out that the for_html field in the Buffer struct was never read, and pondered if Buffer had any utility at all. `@GuillaumeGomez` said he agrees that it can be just removed. So this PR is me removing it. So, r? `@aDotInTheVoid` , maybe? Supersedes #136748
Check whole `Unsize` predicate for escaping bound vars Fixes #136799
…til-cache, r=clubby789 add docs and ut for bootstrap util cache This PR adds doc and unit test for bootstrap utils/cache module
dev-guide: Link to `t-lang` procedures for new features I was confused in rust-lang/rust#136867, because while I did remember that such a procedure existed, but I couldn't seem to find it in the dev guide.
Change swap_nonoverlapping from lang to library UB The implementation of ptr::swap_nonoverlapping does not always escalate its safety contract to language UB, so it should be `check_library_ub`. Fixes rust-lang/miri#4188
…forever, r=compiler-errors compiler: give `ExternAbi` truly stable `Hash` and `Ord` Currently, `ExternAbi` has a bunch of code to handle the reality that, as an enum, adding more variants to it will risk it hashing differently. It forces all of those variants to be added in a fixed order, except this means that the order of the variants doesn't correspond to any logical order except "historical accident". This is all to avoid having to rebless two tests. Perhaps there were more, once upon a time? But then we invented normalization in our test suite to handle exactly this sort of issue in a more general way. There are two options here: - Get rid of all the logical overhead and shrug, embracing blessing a couple of tests sometimes - Change `ExternAbi` to have an ordering and hash that doesn't depend on the number of variants As `ExternAbi` is essentially a strongly-typed string, and thus no two strings can be identical, this implements the second of the two by hand-implementing `Ord` and `Hash` to make the hashing and comparison based on the string! This will diff the current hashes, but they will diff no more after this.
…piler-errors compiler: Make middle errors `pub(crate)` and bury the dead code
use cc archiver as default in `cc2ar` We should remove entire `cc2ar` but `cc` doesn't seem to cover all the conditions that `cc2ar` handles. For now, I replaced the `else` logic only, which is a bit hacky and unstable. Fixes #136759
Rollup of 10 pull requests Successful merges: - #136758 (tests: `-Copt-level=3` instead of `-O` in assembly tests) - #136761 (tests: `-Copt-level=3` instead of `-O` in codegen tests) - #136784 (Nuke `Buffer` abstraction from `librustdoc`, take 2 💣) - #136838 (Check whole `Unsize` predicate for escaping bound vars) - #136848 (add docs and ut for bootstrap util cache) - #136871 (dev-guide: Link to `t-lang` procedures for new features) - #136890 (Change swap_nonoverlapping from lang to library UB) - #136901 (compiler: give `ExternAbi` truly stable `Hash` and `Ord`) - #136907 (compiler: Make middle errors `pub(crate)` and bury the dead code) - #136916 (use cc archiver as default in `cc2ar`) r? `@ghost` `@rustbot` modify labels: rollup
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>`
```
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`.
Rollup of 9 pull requests Successful merges: - #127793 (Added project-specific Zed IDE settings) - #134995 (Stabilize const_slice_flatten) - #136301 (Improve instant docs) - #136347 (Add a bullet point to `std::fs::copy`) - #136794 (Stabilize file_lock) - #137094 (x86_win64 ABI: do not use xmm0 with softfloat ABI) - #137227 (docs(dev): Update the feature-gate instructions) - #137232 (Don't mention `FromResidual` on bad `?`) - #137251 (coverage: Get hole spans from nested items without fully visiting them) r? `@ghost` `@rustbot` modify labels: rollup
…m-ou-se 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.
…tr-select, r=thomcc 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`.
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. https://github.com/rust-lang/rust/blob/4fd3cf96a1db7771ef4f332b9eb1ad17fa0fd091/src/ci/scripts/install-msys2.sh#L11-L13 Fixes #136795 try-job: dist-i686-mingw
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.
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``````
Rollup of 8 pull requests Successful merges: - #120580 (Add `MAX_LEN_UTF8` and `MAX_LEN_UTF16` Constants) - #132268 (Impl TryFrom<Vec<u8>> for String) - #136093 (Match Ergonomics 2024: update old-edition behavior of feature gates) - #136344 (Suggest replacing `.` with `::` in more error diagnostics.) - #136690 (Use more explicit and reliable ptr select in sort impls) - #136815 (CI: Stop /msys64/bin from being prepended to PATH in msys2 shell) - #136923 (Lint `#[must_use]` attributes applied to methods in trait impls) - #137155 (Organize `OsString`/`OsStr` shims) r? `@ghost` `@rustbot` modify labels: rollup
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 (rust-lang/rust#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. rust-lang/rust#133076 previously tried to update the version to 0.3 (CC `@klensy)` r? `@marcoieni`
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
Simplify `slice::Iter::next` enough that it inlines Inspired by this zulip conversation: <https://rust-lang.zulipchat.com/#narrow/channel/189540-t-compiler.2Fwg-mir-opt/topic/Feedback.20on.20a.20MIR.20optimization.20idea/near/498579990> ~~Draft for now because it needs #136735 to get the codegen tests to pass.~~
Remove obsolete Windows ThinLTO+TLS workaround The bug #109797 has been fixed by #129079, so this workaround is no longer needed.
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`
Update host LLVM to 20.1 on CI r? `@ghost`
…u,Kobzol stabilize stage management for rustc tools rust-lang/rust#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~~
[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
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
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.
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
Master bootstrap update https://forge.rust-lang.org/release/process.html#master-bootstrap-update-tuesday r? `@Mark-Simulacrum`
vectorcall ABI: require SSE2 According to the official docs at https://learn.microsoft.com/en-us/cpp/cpp/vectorcall, SSE2 is required for this ABI. Add a check that enforces this. I put this together with the other checks ensuring the target features required for a function are present... however, since the ABI is known pre-monomorphization, it would be possible to do this check earlier, which would have the advantage of checking even in `cargo check`. It would have the disadvantage of spreading this code in yet more places. The first commit just does a little refactoring of the mono-time ABI check to make it easier to add the new check. Cc `@workingjubilee` try-job: dist-i586-gnu-i586-i686-musl
Emit getelementptr inbounds nuw for pointer::add() Lower pointer::add (via intrinsic::offset with unsigned offset) to getelementptr inbounds nuw on LLVM versions that support it. This lets LLVM make use of the pre-condition that the offset addition does not wrap in an unsigned sense. Together with inbounds, this also implies that the offset is non-negative. Fixes rust-lang/rust#137217.
…llaumeGomez librustdoc: Use `pulldown-cmark-escape` for HTML escaping Implementation of `@notriddle` 's [suggestion](rust-lang/rust#137274 (comment)). Somewhat related to #137274 , but the two PRs should be complementary. Local perf results look like a nice improvement! (so would love a perf run on the CI)
Make `#[used]` work when linking with `ld64` To make `#[used]` work in static libraries, we use the `symbols.o` trick introduced in rust-lang/rust#95604. However, the linker shipped with Xcode, ld64, works a bit differently from other linkers; in particular, [it completely ignores undefined symbols by themselves](https://github.com/apple-oss-distributions/ld64/blob/ld64-954.16/src/ld/parsers/macho_relocatable_file.cpp#L2455-L2468), and only consider them if they have relocations (something something atoms something fixups, I don't know the details). So to make the `symbols.o` file work on ld64, we need to actually insert a relocation. That's kinda cumbersome to do though, since the relocation must be valid, and hence must point to a valid piece of machine code, and is hence very architecture-specific. Fixes rust-lang/rust#133491, see that for investigation. --- Another option would be to pass `-u _foo` to the final linker invocation. This has the problem that `-u` causes the linker to not be able to dead-strip the symbol, which is undesirable. (If we did this, we would possibly also want to do it by putting the arguments in a file by itself, and passing that file via ``@`,` e.g. ``@undefined_symbols.txt`,` similar to rust-lang/rust#52699, though that [is only supported since Xcode 12](https://developer.apple.com/documentation/xcode-release-notes/xcode-12-release-notes#Linking), and I'm not sure we wanna bump that). Various other options that are probably all undesirable as they affect link time performance: - Pass `-all_load` to the linker. - Pass `-ObjC` to the linker (the Objective-C support in the linker has different code paths that load more of the binary), and instrument the binaries that contain `#[used]` symbols. - Pass `-force_load` to libraries that contain `#[used]` symbols. Failed attempt: Embed `-u _foo` in the object file with `LC_LINKER_OPTION`, akin to rust-lang/rust#121293. Doesn't work, both because `ld64` doesn't read that from archive members unless it already has a reason to load the member (which is what this PR is trying to make it do), and because `ld64` only support the `-l`, `-needed-l`, `-framework` and `-needed_framework` flags in there. --- TODO: - [x] Support all Apple architectures. - [x] Ensure that this works regardless of the actual type of the symbol. - [x] Write up more docs. - [x] Wire up a few proper tests. `@rustbot` label O-apple
BoxyUwU
commented
Feb 25, 2025
Comment on lines
79
to
-80
| if let rustc_hir::ItemKind::Fn { body, .. } = item.kind { | ||
| let expr = &tcx.hir().body(body).value; |
There was a problem hiding this comment.
this was the merge conflict
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.