Rollup of 13 pull requests #144520
Closed
Rollup of 13 pull requests #144520
Conversation
This file contains hidden or 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
A recent change altered the definition of the link! macro when the windows_raw_dylib feature is enabled, changing its syntax from pub macro {..} to pub macro($tt:tt) {..} in rust-lang#143592
This change introduced a build failure with the error: "macros that expand to items must be delimited with braces or followed by a semicolon".
We add a semicolon to the line causing the issue as we also modify the non windows_raw_dylib link to make use of the link_dylib macro
They were disabled in bd287fa and haven't been causing problems for a while anymore. The entire testsuite still passes on aarch64-unknown-linux-musl with this feature enabled. Signed-off-by: Jens Reidel <[email protected]>
Since this test is limited to aarch64 and linux hosts, the --target flag is entirely unnecessary and only breaks this on musl hosts. Let the compiler use the default target instead. Signed-off-by: Jens Reidel <[email protected]>
I missed this during review. We cannot declare a `tests` module within `shared_helpers.rs` itself, as shim binaries that tries to include the `shared_helpers` module through `#[path = ".."]` attributes would fail to find it, breaking `./x check bootstrap`. This reverts commit `40c2ca96411caaeab1563ff9041879f742d1d71b`.
This check is relatively cheap, and is a quick way to root out breaking check flow of `bootstrap` itself.
Since rust-lang/rust be35d37 ("Use the compiler to determine whether or not to enable f16 and f128"), `compiler-builtins` relies on `rustc` to report whether or not `f16` and `f128` are supported, which is reported by the backend. This means that there should no longer be any need to unconditionally disable the types for clif in Bootstrap. Backend config: https://github.com/rust-lang/rust/blob/a955f1cd09a027363729ceed919952d09f76f28e/compiler/rustc_codegen_cranelift/src/lib.rs#L224-L233
… codegen" This reverts commit f877aa7.
…r-errors add codegen test for variadics This is a part of rust-lang#144066 that can land without FCP.
…-multiple-abis, r=RalfJung test using multiple c-variadic ABIs in the same program tracking issue: rust-lang#100189 Check that multiple c-variadic calling conventions can be used in the same program. Clang and gcc reject defining functions with a non-default calling convention and a variable argument list, so C programs that use multiple c-variadic calling conventions are unlikely to come up. Here we validate that our codegen backends do in fact generate correct code. (CI will not run this test because it runs on aarch64, I would like to at least test that this runs on windows) try-job: `x86_64-gnu` try-job: `x86_64-msvc-*` try-job: `x86_64-apple-2`
…li-obk disable cfg.has_reliable_f128 on amdgcn I was experimenting with compiling a few kernels for amd while working on std::offload. It seems like the logic in rust-lang/compiler-builtins#737 got removed, so I re-introduce it here. Probably should have a test to avoid another regression and make sure that f128 doesn't show up as target feature for amdgcn. It looks like currently we neither check that for nvptx, nor amdgpu. Maybe I could add two revisions to https://github.com/rust-lang/rust/blob/master/tests/ui/float/target-has-reliable-nightly-float.rs? r? ```@Flakebi``` fixes: rust-lang#144381
…ly-abort, r=oli-obk Stop compilation early if macro expansion failed Fixes rust-lang#116180. So there isn't really a type that is central for macro expansion and some errors are actually emitted (because the resolution happens after the expansion I suppose) after the expansion pass (like "not found macro"). Sometimes, errors are only emitted on the second "try" (to improve error output). So I couldn't reach a similar solution than what was done in rust-lang#133937 and suggested by ```@estebank``` in rust-lang#116180 (comment). But maybe I missed something? So in the end, I realized that there is method called every time (except one, described below) a macro error is actually emitted: `ExtCtxt::trace_macros_diag`. Considering I updated what it did, I renamed it into `macro_error_and_trace_macros_diag` to better reflect it. There is only one call of `trace_macros_diag` which isn't reporting an error but just used for `macro_trace` feature, so I kept it as is. r? ```@oli-obk```
library/windows_targets: Fix macro expansion error in 'link' macro
A recent change altered the definition of the link! macro when the windows_raw_dylib feature is enabled, changing its syntax from pub macro {..} to pub macro($tt:tt) {..} in rust-lang#143592
This change introduced a build failure with the error: "macros that expand to items must be delimited with braces or followed by a semicolon".
We add a semicolon to the line causing the issue as we also modify the non windows_raw_dylib link to make use of the link_dylib macro
…musl, r=Amanieu Enable outline-atomics for aarch64-unknown-linux-musl They were disabled in bd287fa and haven't been causing problems for a while anymore, see rust-lang#89626 for details. The entire testsuite still passes on `aarch64-unknown-linux-musl` with this feature enabled.
…target, r=Noratrieb tests: aarch64-outline-atomics: Remove hardcoded target Since this test is limited to aarch64 and linux hosts, the `--target` flag is entirely unnecessary and only breaks this on musl hosts. Let the compiler use the default target instead.
…ts, r=Kobzol Fix `./x check bootstrap` (again) Redoes rust-lang#134883 and reverts 40c2ca9 from rust-lang#142416. Unfortunately I missed this during review. - Commit 1: Reverts 40c2ca9 and re-applies rust-lang#134883. - Commit 2: Check `./x check bootstrap` in `pr-check-1` to catch "obvious" problems like this. r? Kobzol
… r=jieyouxu canonicalize build root in `tests/run-make/linker-warning` r? jieyouxu This is similar to rust-lang#139823 -- the test fails for me because my build dir is a symlink.
Only run bootstrap tests in `x test` on CI Discussed at https://rust-lang.zulipchat.com/#narrow/channel/122652-new-members/topic/Linux.20Distribution/with/530839642. The bootstrap tests can be sensitive of the environment where they are executed. And now that they are executed very early in the test pipeline, it can be annoying for people who just try to do `x test` when it fails on bootstrap tests. We could move the bootstrap tests back to the end of the `x test` pipeline, but then it would just fail later. I'd prefer to only run them on CI by default. Fixes: rust-lang#143973
…r=bjorn3 clif: Don't set the `compiler-builtins-no-f16-f128` feature Since rust-lang/rust be35d37 ("Use the compiler to determine whether or not to enable f16 and f128"), `compiler-builtins` relies on `rustc` to report whether or not `f16` and `f128` are supported, which is reported by the backend. This means that there should no longer be any need to unconditionally disable the types for clif in Bootstrap. Backend config: https://github.com/rust-lang/rust/blob/a955f1cd09a027363729ceed919952d09f76f28e/compiler/rustc_codegen_cranelift/src/lib.rs#L224-L233
…thar Revert "coverage: Enlarge empty spans during MIR instrumentation, not codegen" Surprisingly, rust-lang#144298 alone (extracted from rust-lang#140847) was enough to re-trigger the failures observed in rust-lang#141577 (comment). --- This reverts commit f877aa7. --- r? ghost
bump cargo_metadata Bumps cargo_metadata. Change that required fixes is: oli-obk/cargo_metadata@e3373d0
rustbot
added
A-LLVM
|
@bors r+ rollup=never p=5 |
bors
added
S-waiting-on-bors
bors
added a commit
that referenced
this pull request
Jul 27, 2025
Rollup of 13 pull requests Successful merges: - #144359 (add codegen test for variadics) - #144379 (test using multiple c-variadic ABIs in the same program) - #144383 (disable cfg.has_reliable_f128 on amdgcn) - #144409 (Stop compilation early if macro expansion failed) - #144422 (library/windows_targets: Fix macro expansion error in 'link' macro) - #144429 (Enable outline-atomics for aarch64-unknown-linux-musl) - #144430 (tests: aarch64-outline-atomics: Remove hardcoded target) - #144445 (Fix `./x check bootstrap` (again)) - #144453 (canonicalize build root in `tests/run-make/linker-warning`) - #144464 (Only run bootstrap tests in `x test` on CI) - #144470 (clif: Don't set the `compiler-builtins-no-f16-f128` feature) - #144480 (Revert "coverage: Enlarge empty spans during MIR instrumentation, not codegen") - #144495 (bump cargo_metadata) r? `@ghost` `@rustbot` modify labels: rollup
|
The job Click to see the possible cause of the failure (guessed by this bot) |
Merged
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:
./x check bootstrap(again) #144445 (Fix./x check bootstrap(again))tests/run-make/linker-warning#144453 (canonicalize build root intests/run-make/linker-warning)x teston CI #144464 (Only run bootstrap tests inx teston CI)compiler-builtins-no-f16-f128feature #144470 (clif: Don't set thecompiler-builtins-no-f16-f128feature)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup