minor: Sync from downstream #19331
Merged
minor: Sync from downstream #19331
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
These aren't supported anymore, and are already rejected in type checking.
…rkingjubilee Remove layouting dead code for non-array SIMD types. These aren't supported anymore, and are already rejected in type checking.
…-obk Fix pretty printing of unsafe binders We used to render `unsafe<> i32` as `i32`, and `unsafe<'a> &'a i32` as `for<'a> &'a i32`. r? oli-obk Review with whitespace b/c adding a new argument changes some the wrapping of some function calls.
…obzol do not build additional stage on compiler paths When calling `x build compiler (or rustc) --stage N` bootstrap builds stage N+1 compiler, which is clearly not what we requested. This doesn't happen when running `x build --stage N` without explicitly targeting the compiler. The changes applied fix this issue. r? ghost
Revert "store ScalarPair via memset when one side is undef and the other side can be memset" cc #137892 reverts #135335 r? oli-obk
…-errors Make `ast::TokenKind` more like `lexer::TokenKind` This is step 2 of rust-lang/compiler-team#831. r? `@spastorino`
Subtree update of `rust-analyzer` r? `@ghost`
A few cleanups after the removal of `cfg(not(parallel))` I noticed a few small things that are no longer needed after the removal of `cfg(not(parallel))` in #132282. One of the later changes adjusts several imports, so viewing the changes individually is recommended. r? SparrowLii (or reroll)
fix order on shl impl this doesn't fix any bugs, it makes shl_impl_all! look more consistent with the other impl's in core/ops/bit.rs
Fix docker run-local docs This fixes the docker run-local docs to have a valid cargo command.
…TheVoid,jieyouxu Always allow rustdoc-json tests to contain long lines The rustdoc-json test syntax often requires very long lines, so the checks for long lines aren't really useful. `@aDotInTheVoid` told me she'd like this and r? jieyouxu you're gonna tell me that the implementation is terrible. at least the performance seems reasonable: 2.5s after and 2.5s before.
…ouxu triagebot.toml: Don't label `test/rustdoc-json` as A-rustdoc-search This happened because `test/rustdoc-js` is a prefix of `test/rustdoc-json`, and triagebot works on prefixes. Maybe this should be fixed in triagebot, but this works now. This happened on #137956 and #137955.
Rollup of 12 pull requests Successful merges: - #135767 (Future incompatibility warning `unsupported_fn_ptr_calling_conventions`: Also warn in dependencies) - #137852 (Remove layouting dead code for non-array SIMD types.) - #137863 (Fix pretty printing of unsafe binders) - #137882 (do not build additional stage on compiler paths) - #137894 (Revert "store ScalarPair via memset when one side is undef and the other side can be memset") - #137902 (Make `ast::TokenKind` more like `lexer::TokenKind`) - #137921 (Subtree update of `rust-analyzer`) - #137922 (A few cleanups after the removal of `cfg(not(parallel))`) - #137939 (fix order on shl impl) - #137946 (Fix docker run-local docs) - #137955 (Always allow rustdoc-json tests to contain long lines) - #137958 (triagebot.toml: Don't label `test/rustdoc-json` as A-rustdoc-search) r? `@ghost` `@rustbot` modify labels: rollup
Support raw-dylib link kind on ELF raw-dylib is a link kind that allows rustc to link against a library without having any library files present. This currently only exists on Windows. rustc will take all the symbols from raw-dylib link blocks and put them in an import library, where they can then be resolved by the linker. While import libraries don't exist on ELF, it would still be convenient to have this same functionality. Not having the libraries present at build-time can be convenient for several reasons, especially cross-compilation. With raw-dylib, code linking against a library can be cross-compiled without needing to have these libraries available on the build machine. If the libc crate makes use of this, it would allow cross-compilation without having any libc available on the build machine. This is not yet possible with this implementation, at least against libc's like glibc that use symbol versioning. The raw-dylib kind could be extended with support for symbol versioning in the future. This implementation is very experimental and I have not tested it very well. I have tested it for a toy example and the lz4-sys crate, where it was able to successfully link a binary despite not having a corresponding library at build-time. I was inspired by Björn's comments in https://internals.rust-lang.org/t/bundle-zig-cc-in-rustup-by-default/22096/27 Tracking issue: #135694 r? bjorn3 try-job: aarch64-apple try-job: x86_64-msvc-1 try-job: x86_64-msvc-2 try-job: test-various
mgca: Lower all const paths as `ConstArgKind::Path` When `#![feature(min_generic_const_args)]` is enabled, we now lower all const paths in generic arg position to `hir::ConstArgKind::Path`. We then lower assoc const paths to `ty::ConstKind::Unevaluated` since we can no longer use the anon const expression lowering machinery. In the process of implementing this, I factored out `hir_ty_lowering` code that is now shared between lowering assoc types and assoc consts. This PR also introduces a `#[type_const]` attribute for trait assoc consts that are allowed as const args. However, we still need to implement code to check that assoc const definitions satisfy `#[type_const]` if present (basically is it a const path or a monomorphic anon const). r? `@BoxyUwU`
dec2flt: Clean up float parsing modules This is the first portion of my work adding support for parsing and printing `f16`. Changes in `float.rs` replace the magic constants with expressions and add some use of generics to better support the new float types. Everything else is related to documentation or naming; there are no functional changes in this PR. This can be reviewed by commit.
Retire the legacy `Makefile`-based `run-make` test infra The final piece of [porting run-make tests to use Rust #121876](rust-lang/rust#121876). Closes #121876. Closes #40713. Closes #81791 (no longer using `wc`). Closes #56475 (no longer a problem in current form of that test; we don't ignore the test on `aarch64-unknown-linux-gnu`). ### Summary This PR removes the legacy `Makefile`-based `run-make` test infra which has served us well over the years. The legacy infra is no longer needed since we ported all of `Makefile`-based `run-make` tests to the new `rmake.rs` infra. Additionally, this PR: - Removes `tests/run-make/tools.mk` since no more `Makefile`-based tests remain. - Updates `tests/run-make/README.md` and rustc-dev-guide docs to remove mention about `Makefile`-based `run-make` tests - Update test suite requirements in rustc-dev-guide on Windows to no longer need MSYS2 (they should also now run successfully on native Windows MSVC). - Update `triagebot.toml` to stop backlinking to #121876. **Thanks to everyone who helped in this effort to modernize the `run-make` test infra and test suite!** r? bootstrap
…u-se Count char width at most once in `Formatter::pad` When both width and precision flags are specified, then `Formatter::pad` counts the character width twice. Instead, record the character width when truncating it to the precision, so it does not need to be recomputed. Simplify control flow so the cases are more clear. Related: - 6c9e708f4be (`fmt::Formatter::pad`: don't call chars().count() more than one time, 2021-09-01): Reduce counting chars from thrice to twice in worst case - ede39ae (feat: reinterpret `precision` field for strings, 2016-06-29): Change meaning of precision for strings - b820748 (Implement formatting arguments for strings and integers, 2013-08-10): Implement `Formatter::pad`
…ject-hard-error, r=oli-obk Make `ptr_cast_add_auto_to_object` lint into hard error In Rust 1.81, we added a FCW lint (including linting in dependencies) against pointer casts that add an auto trait to dyn bounds. This was part of work making casts of pointers involving trait objects stricter, and was part of the work needed to restabilize trait upcasting. We considered just making this a hard error, but opted against it at that time due to breakage found by crater. This breakage was mostly due to the `anymap` crate which has been a persistent problem for us. It's now a year later, and the fact that this is not yet a hard error is giving us pause about stabilizing arbitrary self types and `derive(CoercePointee)`. So let's see about making a hard error of this. r? ghost cc ```@adetaylor``` ```@Darksonn``` ```@BoxyUwU``` ```@RalfJung``` ```@compiler-errors``` ```@oli-obk``` ```@WaffleLapkin``` Related: - rust-lang/rust#135881 - rust-lang/rust#136702 - rust-lang/rust#136776 Tracking: - rust-lang/rust#127323 - rust-lang/rust#44874 - rust-lang/rust#123430
Added documentation for flushing per #74348 Resolves #74348
Perform deeper compiletest path normalization for `$TEST_BUILD_DIR` to account for compare-mode/debugger cases, and normalize long type file filename hashes Fixes #136510. ### Summary - Whereas previously `$TEST_BUILD_DIR` is a normalization of `/path/to/build/test/<test_suite_name>/`, we now more deeply normalize. `$TEST_BUILD_DIR` now becomes a normalization of `/path/to/build/test/<test_suite_name>/<subdirs>/$name.$revision.$compare_mode.$debugger/` to normalize away path name differences when `--compare-mode` and/or `--debugger` are specified. - We also centralize the normalization of long type name hashes cf. rust-lang/rust#136328 (comment). ### Review advice - Best reviewed commit-by-commit. - Split into 3 commits: - **Commit 1**: compiletest changes to have `$TEST_BUILD_DIR` more deeply normalize. - **Commit 2**: remove per-test hacks for long type path hash normalizations, and rebless tests *specifically* affected by that. - **Commit 3**: rebless other tests that were changed as a side-effect of deeper `$TEST_BUILD_DIR` normalizations. **Commit 2** is created via first finding tests that try to perform long type file hash normalizations on an ad hoc, per-test basis: ``` rg --no-ignore -l --no-ignore -F -e "long-type" tests/ui/**/*.rs ``` <details> <summary>Tests with ad hoc long-type hash normalizations</summary> ``` tests/ui/type_length_limit.rs tests/ui/traits/on_unimplemented_long_types.rs tests/ui/regions/issue-102374.rs tests/ui/recursion/recursion.rs tests/ui/recursion/issue-83150.rs tests/ui/recursion/issue-23122-2.rs tests/ui/methods/inherent-bound-in-probe.rs tests/ui/issues/issue-67552.rs tests/ui/issues/issue-37311-type-length-limit/issue-37311.rs tests/ui/issues/issue-20413.rs tests/ui/issues/issue-8727.rs tests/ui/infinite/infinite-instantiation.rs tests/ui/infinite/infinite-instantiation-struct-tail-ice-114484.rs tests/ui/higher-ranked/trait-bounds/hrtb-doesnt-borrow-self-1.rs tests/ui/higher-ranked/trait-bounds/hrtb-doesnt-borrow-self-2.rs tests/ui/higher-ranked/trait-bounds/hang-on-deeply-nested-dyn.rs tests/ui/error-codes/E0275.rs tests/ui/diagnostic-width/secondary-label-with-long-type.rs tests/ui/diagnostic-width/long-e0277.rs tests/ui/diagnostic-width/non-copy-type-moved.rs tests/ui/diagnostic-width/long-E0308.rs tests/ui/diagnostic-width/E0271.rs tests/ui/diagnostic-width/binop.rs ``` </details> These ad hoc normalizations were removed, and they are reblessed. r? `````@lqd`````
Look for `python3` first on MacOS, not `py` `py` is not installed by default *and* trying to run it results in a popup asking if you want to install it. `python3` is installed by default. This hopefully should not be too disruptive to people on Windows, since they should be going through `x.ps1` instead anyway. Just in case, I've added a check for Cygwin and Msys (i'm not sure how else you'd get a bash shell on windows). I've tested this on macOS, WSL, "git bash" (which appears to be MSYS), and MSVC with `bash -c ./x` (which runs in WSL, but differently than interactive bash 🙃). I haven't tested Cygwin, which is unsupported anyway, but the code tries to make it work.
Slightly reformat `std::fs::remove_dir_all` error docs To make the error cases easier to spot on a quick glance, as I've been bitten by this a couple of times already 💀 cc #137230.
Check signature WF when lowering MIR body Alternative to #137233. rust-lang/rust#137233 (comment) Fixes rust-lang/rust#137186 We do this check in `mir_drops_elaborated_and_const_checked` and not during `mir_promoted` because that may result in borrowck cycles if WF requires looking into an opaque hidden type. This causes some TAIT tests to fail unnecessarily. r? lcnr try-job: test-various
…lacrum [illumos] attempt to use posix_spawn to spawn processes illumos has `posix_spawn`, and the very newest versions also have `_addchdir`, so use that. POSIX standardized this function so I also added a weak symbol lookup for the non `_np` version. (illumos has both.) This probably also works on Solaris, but I don't have access to an installation to validate this so I decided to focus on illumos instead. This is a nice ~4x performance improvement for process creation. My go-to as usual is nextest against the clap repo, which acts as a stress test for process creation -- with [this commit]: ```console $ cargo nextest run -E 'not test(ui_tests) and not test(example_tests)' before: Summary [ 1.747s] 879 tests run: 879 passed, 2 skipped after: Summary [ 0.445s] 879 tests run: 879 passed, 2 skipped ``` [this commit]: clap-rs/clap@fde45f9
uefi: Add Service Binding Protocol abstraction - Some UEFI protocols such as TCP4, TCP6, UDP4, UDP6, etc are managed by service binding protocol. - A new instance of such protocols is created and destroyed using the corresponding service binding protocol. - This PR adds abstractions to make using such protocols simpler using Rust Drop trait. - The reason to add these abstractions in a seperate PR from TCP4 Protocol is to make review easier. [EFI_SERVICE_BINDING_PROTCOL](https://uefi.org/specs/UEFI/2.11/11_Protocols_UEFI_Driver_Model.html#efi-service-binding-protocol) cc ````@nicholasbishop````
Stabilize `string_extend_from_within` FCP'd here: rust-lang/rust#103806 (comment). Closes #103806.
…nur-ozkan Various coretests improvements The first commit is not yet strictly necessary as directly testing libcore works though useless work, but will be necessary once rust-lang/rust#136642 migrates the liballoc tests into a separate package. The second commit fixes rust-lang/rust#137478 and ensures that coretests actually gets tested on all CI job. The third commit fixes an error that didn't get caught because coretests doesn't run on the wasm32 CI job.
Remove unsizing coercions for tuples See rust-lang/rust#42877 (comment) and below comments for justification. Tracking issue: #42877 Fixes: #135217
...either as: - methods on LayoutCalculator, for faillible operations; - constructors on LayoutData, for infaillible ones.
Use `trunc nuw`+`br` for 0/1 branches even in optimized builds Rather than needing to use `switch` for them to include the `unreachable` arm.
…li-obk Don't include global asm in `mir_keys`, fix error body synthesis r? oli-obk Fixes #137470 Fixes #137471 Fixes #137472 Fixes #137473 try-job: test-various try-job: x86_64-apple-2
Don't re-`assume` in `transmute`s that don't change niches I noticed in nightly 2025-02-21 that `transmute` is emitting way more `assume`s than necessary for newtypes. For example, the three transmutes in <https://rust.godbolt.org/z/fW1KaTc4o> emits ```rust define noundef range(i32 1, 0) i32 `@repeatedly_transparent_transmute(i32` noundef range(i32 1, 0) %_1) unnamed_addr { start: %0 = sub i32 %_1, 1 %1 = icmp ule i32 %0, -2 call void `@llvm.assume(i1` %1) %2 = sub i32 %_1, 1 %3 = icmp ule i32 %2, -2 call void `@llvm.assume(i1` %3) %4 = sub i32 %_1, 1 %5 = icmp ule i32 %4, -2 call void `@llvm.assume(i1` %5) %6 = sub i32 %_1, 1 %7 = icmp ule i32 %6, -2 call void `@llvm.assume(i1` %7) %8 = sub i32 %_1, 1 %9 = icmp ule i32 %8, -2 call void `@llvm.assume(i1` %9) %10 = sub i32 %_1, 1 %11 = icmp ule i32 %10, -2 call void `@llvm.assume(i1` %11) ret i32 %_1 } ``` But those are all just newtypes that don't change size or niches, so none of it's needed. After this PR it's down to just ```rust define noundef range(i32 1, 0) i32 `@repeatedly_transparent_transmute(i32` noundef range(i32 1, 0) %_1) unnamed_addr { start: ret i32 %_1 } ``` because none of those `assume`s in the original actually did anything. (Transmuting to something with a difference niche, though, still has the assumes -- the other tests continue to pass checking that.)
add `tool::CargoClippy` and `tool::Cargofmt` binary to target sysroot When running `x build clippy`, we expect `stage1-tool-bin/cargo-clippy` and `stage2/bin/cargo-clippy` to be the same, but they aren't. This happens because `tool::CargoClippy` doesn't place its binary in the `stage2` directory. As a result, `stage1-tool-bin/cargo-clippy` comes from `tool::CargoClippy`, while `stage2/bin/cargo-clippy` comes from `tool::Cargo`. Same applies for `tool::Cargofmt`. This PR fixes the issue by adding `tool::CargoClippy` and ``tool::Cargofmt`` binaries to the expected sysroot and makes sure both directories share the same binary. To test this, run `x build --stage 2 compiler clippy rustfmt`, link the stage2 sysroot with rustup, and then call `cargo +stage2 fmt` and `cargo +stage2 clippy` on any rust project (it wouldn't work without this PR).
Change TaskDeps to start preallocated with 128 capacity This is a tiny change that makes `TaskDeps::read_set` start preallocated with capacity for 128 elements. From local profiling, it looks like `TaskDeps::read_set` is one of the most-often resized hash-sets in `rustc`.
Turn order dependent trait objects future incompat warning into a hard error fixes #56484 r? ``@ghost`` will FCP when we have a crater result
tidy: add triagebot checks Validates triagebot.toml to have existing paths: `[mentions."*"]` sections, i.e. ```toml [mentions."compiler/rustc_const_eval/src/"] ``` or ```toml [assign.owners] "/.github/workflows" = ["infra-ci"] ``` or ```toml trigger_files = [ "src/librustdoc/html/static/js/search.js", "tests/rustdoc-js", "tests/rustdoc-js-std", ] ``` Looked at #137876 and implemented check.
…=compiler-errors
compiler: Use `size_of` from the prelude instead of imported
Use `std::mem::{size_of, size_of_val, align_of, align_of_val}` from the prelude instead of importing or qualifying them. Apply this change across the compiler.
These functions were added to all preludes in Rust 1.80.
r? ``@compiler-errors``
…jubilee Move more layouting logic to `rustc_abi` Move all `LayoutData`-constructing code to `rustc_abi`: - Infaillible operations get a new `LayoutData` constructor method; - Faillible ones get a new method on `LayoutCalculator`.
depend more on attr_data_structures and move find_attr! there r? ``@oli-obk`` This should be an easy one. It just moves some imports around. This is necessary for other changes that I'm working on not to have import cycles. However, it's an easy one to just merge on its own.
crashes: couple more tests try-job: aarch64-apple try-job: x86_64-msvc-1 try-job: x86_64-gnu try-job: dist-i586-gnu-i586-i686-musl
bootstrap: Fix stack printing when a step cycle is detected
When bootstrap detects a step dependency cycle (which represents a bootstrap bug), it is supposed to print out the contents of the step stack as part of its panic message.
However, while investigating #138205 it was found that bootstrap was actually printing out several copies of `Any { .. }`, because that is the Debug implementation for `dyn Any`. This is sadly not very helpful.
This PR fixes that problem by introducing a `trait AnyDebug: Any + Debug` that delegates to the underlying type's Debug implementation, while still allowing downcasting via Any.
---
The fixed behaviour can be verified manually (and is tested automatically) via a new dummy command, `./x run cyclic-step`:
```
$ x run cyclic-step
Building bootstrap
Finished `dev` profile [unoptimized] target(s) in 0.02s
thread 'main' panicked at src/bootstrap/src/core/builder/mod.rs:1521:17:
Cycle in build detected when adding CyclicStep { n: 0 }
CyclicStep { n: 0 }
CyclicStep { n: 1 }
CyclicStep { n: 2 }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Build completed unsuccessfully in 0:00:00
```
Reduce verbosity of GCC build log It was a bit too spammy before. Fixes: rust-lang/rust#138213 r? ``@GuillaumeGomez``
Revert "Don't test new error messages with the stage 0 compiler"
Rollup of 12 pull requests Successful merges: - #136127 (Allow `*const W<dyn A> -> *const dyn A` ptr cast) - #136968 (Turn order dependent trait objects future incompat warning into a hard error) - #137319 (Stabilize `const_vec_string_slice`) - #137885 (tidy: add triagebot checks) - #138040 (compiler: Use `size_of` from the prelude instead of imported) - #138084 (Use workspace lints for crates in `compiler/`) - #138158 (Move more layouting logic to `rustc_abi`) - #138160 (depend more on attr_data_structures and move find_attr! there) - #138192 (crashes: couple more tests) - #138216 (bootstrap: Fix stack printing when a step cycle is detected) - #138232 (Reduce verbosity of GCC build log) - #138242 (Revert "Don't test new error messages with the stage 0 compiler") r? `@ghost` `@rustbot` modify labels: rollup
Split the `Edges` iterator. Some nice performance wins here, mostly on the `wg-grammar` benchmark. r? `@lcnr`
…thlin Always inline `query_get_at`. r? `@saethlin`
rustbot
added
the
S-waiting-on-review
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.