Skip to content

Rollup of 20 pull requests #145039

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 104 commits into from
Closed

Conversation

Zalathar
Copy link
Contributor

@Zalathar Zalathar commented Aug 7, 2025

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

dianne and others added 30 commits June 25, 2025 13:02
We are getting warnings in CI about unsupported features. There isn't
any reason to use stable rustfmt so switch the channel here.
We now have access to native runners, so make use of them for these
architectures. The existing ppc64le Docker job is kept for now.
This includes a qemu update from 8.2.2 to 9.2.1 which should hopefully
fix some bugs we have encountered.

PowerPC64LE is skipped for now because the new version seems to cause a
number of new SIGILLs.
Wasm support has since been released, so we no longer need to depend on
a git version of `object`.
We pretty often get at least one job failed because of failure to pull
the musl git repo. Switch this to the unofficial mirror [1] which should
be more reliable.

Link: https://github.com/kraj/musl [1]
Update the last remaining image.

For this to work, the `QEMU_CPU=POWER8` configuration needed to be
dropped to avoid a new SIGILL. Doing some debugging locally, the crash
comes from an `extswsli` (per `powerpc:common64` in gdb-multiarch) in
the `ld64.so` available with PowerPC, which qemu rejects when set to
power8. Testing a build with `+crt-static` hits the same issue at a
`maddld` in `__libc_start_main_impl`.

Rust isn't needed to reproduce this:

    $ cat a.c
    #include <stdio.h>

    int main() {
            printf("Hello, world!\n");
    }
    $ powerpc64le-linux-gnu-gcc a.c
    $ QEMU_CPU=power8 QEMU_LD_PREFIX=/usr/powerpc64le-linux-gnu/ ./a.out
    qemu: uncaught target signal 4 (Illegal instruction) - core dumped
    Illegal instruction

So the cross toolchain provided by Debian must have a power9 baseline
rather than rustc's power8. Alternatively, qemu may be incorrectly
rejecting these instructions (I can't find a source on whether or not
they should be available for power8). Testing instead with the `-musl`
toolchain and ppc linker from musl.cc works correctly.

In any case, things work with the default qemu config so it seems fine
to drop. The env was originally added in 5d164a4edafb ("fix the
powerpc64le target") but whatever the problem was there appears to no
longer be relevant.
Most of these were skipped because of a bug with the platform
implementation, or some kind of crash unwinding. Since the upgrade to
Ubuntu 25.04, these all seem to be resolved with the exception of a bug
in the host `__floatundisf` [1].

[1] rust-lang/compiler-builtins#384 (comment)
The LLVM issue was resolved a while ago, these should no longer be a
problem.
The fix has since made it to nightly, so the skips here can be removed.
Emit `x86_no_sse` in the compiler-builtins (and builtins-test) build
script, and use it to simplify `all(target_arch = "x86",
not(target_fefature = "sse))` configuration.
Silence the approximate constant lint because it is noisy and not always
correct. `single_component_path_imports` is also not accurate when built
as part of `compiler-builtins`, so that needs to be `allow`ed as well.
Possible workaround for
rust-lang/compiler-builtins#976 (comment)

Inline assembly in the body of a function currently causes the compiler
to consider that function possibly unwinding, even if said asm
originated from inlining an `extern "C"` function. This patch wraps the
problematic callsite with `#[inline(never)]`.
Assembly-related configuration was added in 1621c6dbf9eb ("Use
`specialized-div-rem` 1.0.0 for division algorithms") to account for
Cranelift not yet supporting assembly. This hasn't been relevant for a
while, so we no longer need to gate `asm!` behind this configuration.
Thus, remove `cfg(not(feature = "no-asm"))` in places where there is no
generic fallback.

There are other cases, however, where setting the `no-asm` configuration
enables testing of generic version of builtins when there are platform-
specific implementations available; these cases are left unchanged. This
could be improved in the future by exposing both versions for testing
rather than using a configuration and running the entire testsuite
twice.

This is the compiler-builtins portion of
rust-lang#144471.
So there will no longer be the need to close and reopen sync PRs in
order for CI to run.
Rather than setting an environment variable in the workflow job based on
whether or not the environment is non-MinGW Windows, we can just check
this in the ci script.

This was originally added in b0f19660f0 ("Add tests for UNC paths on
windows builds") and its followup commits.
Replace the current system with something that is more structured and
will also catch unknown directives.
Use `tee` rather than printing to both stdout and stderr.
Introduce a new directive `ci: test-libm` to ensure tests run.
Currently, a failure in `ci-util.py` does not cause the job to fail
because the pipe eats the failure status . Set pipefail to fix this.

Fixes: ff2cc0e38e3e ("ci: Don't print output twice in `ci-util`")
Currently, attributes for `no-panic` are gated behind both the `test`
config and `assert_no_panic`, because `no-panic` is a dev dependency (so
only available with test configuration). However, we only emit
`assert_no_panic` when the test config is also set anyway, so there
isn't any need to gate on both.

Replace gates on `all(test, assert_no_panic)` with only
`assert_no_panic`. This is simpler, and also has the benefit that
attempting to check for panics without `--test` errors.
We noticed when building rustc multiple time in a roll, some files
will not be consistent across the build despite the fact that they
are built from same source under the same environment. This patch
addresses the inconsistency issue we found on libunwind.a by sorting
the order of the files passed to the linker.
@rustbot rustbot added A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. A-run-make Area: port run-make Makefiles to rmake.rs A-testsuite Area: The testsuite used to check the correctness of rustc S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-release Relevant to the release subteam, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Aug 7, 2025
@Zalathar
Copy link
Contributor Author

Zalathar commented Aug 7, 2025

Derived from #145034, minus:

@bors r+ rollup=never p=5

@bors
Copy link
Collaborator

bors commented Aug 7, 2025

📌 Commit a2974c3 has been approved by Zalathar

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 7, 2025
@bors
Copy link
Collaborator

bors commented Aug 7, 2025

⌛ Testing commit a2974c3 with merge 5f76d77...

bors added a commit that referenced this pull request Aug 7, 2025
Rollup of 20 pull requests

Successful merges:

 - #137831 (Tweak auto trait errors)
 - #143028 (emit `StorageLive` and schedule `StorageDead` for `let`-`else`'s bindings after matching)
 - #143764 (lower pattern bindings in the order they're written and base drop order on primary bindings' order)
 - #143808 (Port `#[should_panic]` to the new attribute parsing infrastructure )
 - #143906 (Miri: non-deterministic floating point operations in `foreign_items`)
 - #143929 (Mark all deprecation lints in name resolution as deny-by-default and report-in-deps)
 - #144133 (Stabilize const TypeId::of)
 - #144439 (Introduce ModernIdent type to unify macro 2.0 hygiene handling)
 - #144473 (Address libunwind.a inconsistency issues in the bootstrap program)
 - #144659 (bootstrap: refactor mingw dist and fix gnullvm)
 - #144705 (compiler-builtins: plumb LSE support for aarch64 on linux/gnu when optimized-compiler-builtins not enabled)
 - #144807 (Streamline config in bootstrap)
 - #144900 (Stabilize `unsigned_signed_diff` feature)
 - #144903 (Rename `begin_panic_handler` to `panic_handler`)
 - #144931 ([win][arm64ec] Fix msvc-wholearchive for Arm64EC)
 - #144974 (compiler-builtins subtree update)
 - #144997 (bump bootstrap compiler to 1.90 beta)
 - #145004 (Couple of minor cleanups)
 - #145009 (A couple small changes for rust-analyzer next-solver work)
 - #145014 (Revert "Preserve the .debug_gdb_scripts section")

r? `@ghost`
`@rustbot` modify labels: rollup
@klensy
Copy link
Contributor

klensy commented Aug 7, 2025

#145014 reverts perf regression, is it ok for rollup?

@rust-log-analyzer
Copy link
Collaborator

The job armhf-gnu failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)
failures:

---- [ui] tests/ui/consts/control-flow/drop-pass.rs#stock stdout ----

error in revision `stock`: test did not exit with success! code=Some(101) so test would pass with `run-fail`
status: exit status: 101
command: RUSTC="/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" RUST_TEST_THREADS="4" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/remote-test-client" "run" "0" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/consts/control-flow/drop-pass.stock/a"
--- stdout -------------------------------
uploaded "/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/consts/control-flow/drop-pass.stock/a", waiting for result
------------------------------------------

@bors
Copy link
Collaborator

bors commented Aug 7, 2025

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Aug 7, 2025
@Zalathar
Copy link
Contributor Author

Zalathar commented Aug 7, 2025

Oh, this could also be flakiness, so let's try to reproduce here:

@bors try jobs=armhf-gnu

@rust-bors
Copy link

rust-bors bot commented Aug 7, 2025

⌛ Trying commit a2974c3 with merge c4f0751

To cancel the try build, run the command @bors try cancel.

rust-bors bot added a commit that referenced this pull request Aug 7, 2025
Rollup of 20 pull requests

try-job: armhf-gnu
@rust-bors
Copy link

rust-bors bot commented Aug 7, 2025

☀️ Try build successful (CI)
Build commit: c4f0751 (c4f0751fc2d3e1746620d8a8a687726ce22b974d, parent: 61cb1e97fcf954c37d0a457a8084ed9ad8b3cb82)

@Zalathar
Copy link
Contributor Author

Zalathar commented Aug 7, 2025

OK, the failure is flakiness. Anyhow, this rollup is now stale.

@Zalathar Zalathar closed this Aug 7, 2025
@rustbot rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Aug 7, 2025
@Zalathar Zalathar deleted the rollup-98v9fbg branch August 7, 2025 09:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-attributes Area: Attributes (`#[…]`, `#![…]`) A-compiler-builtins Area: compiler-builtins (https://github.com/rust-lang/compiler-builtins) A-compiletest Area: The compiletest test runner A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. A-run-make Area: port run-make Makefiles to rmake.rs A-testsuite Area: The testsuite used to check the correctness of rustc rollup A PR which is a rollup T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-release Relevant to the release subteam, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.