Rollup of 10 pull requests #138007
Closed
Rollup of 10 pull requests #138007
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
`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).
To make the error cases easier to spot on a quick glance.
This overrides the test=false flag in Cargo.toml and it shouldn't be necessary as --tests is already passed.
It is reasonable to expect that ./x.py test core is enough to run tests when you are working on core. In addition it seems like CI for wasm32 at least doesn't run coretests currently, which this commit fixes.
This will help stabilization of lld.
Includes a change to make a subset of math symbols available on all platforms [1], and disables `f16` on aarch64 without neon [2]. [1]: rust-lang/compiler-builtins#763 [2]: rust-lang/compiler-builtins#775
It has served us well, but it's time to retire the `Makefile` support file since this is no longer needed.
And remove outdated requirements to run `run-make` tests on Windows.
No longer needed.
This is to make test stderr insensitive to compare-mode / debugger that changes the test build dir output name. Previously, this normalized paths up to test-suite-specific build root, e.g. `/path/to/build/test/ui/`. Now, this normalizes up to test-specific build root, e.g. `/path/to/build/test/ui/subdir/$name.$revision.$mode.$debugger/`.
Retire the legacy `Makefile`-based `run-make` test infra The final piece of [porting run-make tests to use Rust rust-lang#121876](rust-lang#121876). Closes rust-lang#121876. Closes rust-lang#40713. Closes rust-lang#81791 (no longer using `wc`). Closes rust-lang#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 rust-lang#121876. **Thanks to everyone who helped in this effort to modernize the `run-make` test infra and test suite!** r? bootstrap
…de, r=lqd Perform deeper compiletest path normalization for `$TEST_BUILD_DIR` to account for compare-mode/debugger cases, and normalize long type file filename hashes Fixes rust-lang#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#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.
…mulacrum 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 rust-lang#137230.
…gillot Remove `MaybeForgetReturn` suggestion rust-lang#115196 implemented a suggestion to add a missing `return` when there is an ambiguity error, when that ambiguity error could be constrained by the return type of the function. I initially reviewed it and thought it could be useful; however, looking back at that code now, I feel like it's a bit too much of a hack to be worth keeping around in typeck, especially given how rare it's expected to fire in practice. This is especially true because it depends on `StashKey::MaybeForgetReturn`, which is only stashed when we have *Sized* obligation ambiguity errors. Let's remove it for now. I'd like to note that it's basically impossible to get this suggestion to apply in its current state except for what I'd consider somewhat artificial examples, involving no generic trait bounds. For example, it's not triggered for: ```rust struct W<T>(T); fn bar<T: Default>() -> W<T> { todo!() } fn foo() -> W<i32> { if true { bar(); } W(0) } ``` Nor is it triggered for: ``` fn foo() -> i32 { if true { Default::default(); } 0 } ``` It's basically only triggered iff there's only one ambiguity error on the type, which is `Sized`. Generally, suggesting something that affects control flow is a pretty dramatic suggestion; therefore, both the accuracy and precision of this diagnostic should be pretty high. One other, somewhat unrelated observation is that this might be using stashed diagnostics incorrectly (or at least unnecessarily). Stashed diagnostics are used when error detection is fragmented over several major stages of the compiler, like a parse or resolver error which later can be recovered in typeck. However, this one is a bit different since it is fully handled within typeck -- perhaps that suggests that if this were to be reimplemented, it wouldn't need to be so complicated of an implementation.
Update `compiler-builtins` to 0.1.149 Includes a change to make a subset of math symbols available on all platforms [1], and disables `f16` on aarch64 without neon [2]. [1]: rust-lang/compiler-builtins#763 [2]: rust-lang/compiler-builtins#775 try-job: aarch64-gnu try-job: aarch64-gnu-debug try-job: armhf-gnu try-job: dist-various-1 try-job: dist-various-2 try-job: dist-aarch64-linux try-job: dist-arm-linux try-job: dist-armv7-linux try-job: dist-x86_64-linux try-job: test-various
…ieyouxu,onur-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#136642 migrates the liballoc tests into a separate package. The second commit fixes rust-lang#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.
self-contained linker: conservatively default to `-znostart-stop-gc` To help stabilization, this PR disables an LLD optimization with respect to `--gc-sections` and encapsulation symbols: it will reduce the number of crates needing to opt-out of lld due to this bfd / lld difference. For example, all the people using [linkme](https://github.com/dtolnay/linkme), which [doesn't work with lld](dtolnay/linkme#63) or on nightly, need to disable lld. More information about all this, and the historical differences, can be found in: - https://maskray.me/blog/2021-01-31-metadata-sections-comdat-and-shf-link-order - https://lld.llvm.org/ELF/start-stop-gc This optimization has [no visible impact](rust-lang#137685 (comment)) on our benchmarks, so we can use it by default and have a safer/more conservative starting point to remove friction during migration. We can them emit an FCW for the cases where lld detects reliance on encapsulation symbols without `-znostart-stop-gc`, and then revert back to lld's default after a while. No one compiling on nightly relies on this difference, obviously, so doing an FCW is not necessary until after lld is used on stable. I've tested that this correctly links on `linkme` examples. I've also quickly tried to crate an rmake test but the setup with encapsulation symbols is annoying to reproduce: a few link section/name attributes is not enough, we also need to collect symbols between the encapsulation symbols, without referencing them in code, for `-znostart-stop-gc` to only impact this... It should of course be doable though, maybe `@Kobzol` will look into it if they have time. r? `@petrochenkov` try-job: dist-apple-various
…heemdev Stabilize `box_uninit_write` Closes: rust-lang#129397.
Do not install rustup on Rust for Linux job Trying to fix the RfL job after the recent rustup update. r? `@ghost` try-job: x86_64-rust-for-linux
rustbot
added
A-compiletest
|
@bors r+ rollup=never p=5 |
bors
added
S-waiting-on-bors
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Mar 4, 2025
Rollup of 10 pull requests Successful merges: - rust-lang#136581 (Retire the legacy `Makefile`-based `run-make` test infra) - rust-lang#136865 (Perform deeper compiletest path normalization for `$TEST_BUILD_DIR` to account for compare-mode/debugger cases, and normalize long type file filename hashes) - rust-lang#136975 (Look for `python3` first on MacOS, not `py`) - rust-lang#137240 (Slightly reformat `std::fs::remove_dir_all` error docs) - rust-lang#137303 (Remove `MaybeForgetReturn` suggestion) - rust-lang#137634 (Update `compiler-builtins` to 0.1.149) - rust-lang#137679 (Various coretests improvements) - rust-lang#137685 (self-contained linker: conservatively default to `-znostart-stop-gc`) - rust-lang#137850 (Stabilize `box_uninit_write`) - rust-lang#137947 (Do not install rustup on Rust for Linux job) r? `@ghost` `@rustbot` modify labels: rollup
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
|
It looks like #137685 failed this rollup, Jubilee already left a note. |
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.
Successful merges:
Makefile-basedrun-maketest infra #136581 (Retire the legacyMakefile-basedrun-maketest infra)$TEST_BUILD_DIRto account for compare-mode/debugger cases, and normalize long type file filename hashes #136865 (Perform deeper compiletest path normalization for$TEST_BUILD_DIRto account for compare-mode/debugger cases, and normalize long type file filename hashes)python3first on MacOS, notpy#136975 (Look forpython3first on MacOS, notpy)std::fs::remove_dir_allerror docs #137240 (Slightly reformatstd::fs::remove_dir_allerror docs)MaybeForgetReturnsuggestion #137303 (RemoveMaybeForgetReturnsuggestion)compiler-builtinsto 0.1.149 #137634 (Updatecompiler-builtinsto 0.1.149)-znostart-stop-gcon x64 linux #137685 (self-contained linker: conservatively default to-znostart-stop-gc)box_uninit_write#137850 (Stabilizebox_uninit_write)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup