Skip to content

Rollup of 9 pull requests #145074

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

Merged
merged 43 commits into from
Aug 8, 2025
Merged

Rollup of 9 pull requests #145074

merged 43 commits into from
Aug 8, 2025

Conversation

tgross35
Copy link
Contributor

@tgross35 tgross35 commented Aug 8, 2025

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

tgross35 and others added 30 commits July 21, 2025 12:18
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.
Add dynamic support for aarch64 LSE atomic ops on linux targets
when optimized-compiler-builtins is not enabled.

A hook, __enable_rust_lse, is provided for the runtime to enable
them if available. A future patch will use this to enable them
if available.

The resulting asm should exactly match that of LLVM's compiler-rt
builtins, though the symbol naming for the support function and
global does not.
Create a private module to hold the bootstrap code needed enable LSE
at startup on aarch64-*-linux-* targets when rust implements the
intrinsics.

This is a bit more heavyweight than compiler-rt's LSE initialization,
but has the benefit of initializing the aarch64 cpu feature detection
for other uses.

Using the rust initialization code does use some atomic operations,
that's OK. Mixing LSE and non-LSE operations should work while the
update flag propagates.
Currently we run the `rustc` from the `RUSTC` environment variable to
figure out whether or not to enable `f16` and `f128`, based on the
`target_has_reliable_{f16,f128}` config. However, this does not know
about the codegen backend used, and the backend isn't trivial to check
in a build script (usually it gets set via `RUSTFLAGS`).

It turns out we don't actually need to run `rustc` here: Cargo
unconditionally emits all config from the relevant compiler as
`CARGO_CFG_*` variables, regardless of whether or not they are known
options. Switch to checking these for setting config rather than
invoking `rustc`.

As an added advantage, this will work with target.json files without any
special handling.

Fixes: ed17b95715dd ("Use the compiler to determine whether or not to enable `f16` and `f128`")
It is essentially a RustcPrivate tool, so it should be treated as such using the new `RustcPrivateCompilers` infra.
… r=GuillaumeGomez

doc(library): Fix Markdown in `Iterator::by_ref`

This patch fixes the Markdown formatting in `std::core::iter::Iterator::by_ref`. Code is used inside a link without the backticks around the code.
Fix doc comment of File::try_lock and File::try_lock_shared

The doc comments of functions `File::try_lock` and `File::try_lock_shared` stabilized today in version 1.89.0 document an incorrect type of `Ok`.

The result type was changed in rust-lang#139343 after the latest change to the doc comments in rust-lang#136876.
@rustbot rustbot added A-attributes Area: Attributes (`#[…]`, `#![…]`) A-compiler-builtins Area: compiler-builtins (https://github.com/rust-lang/compiler-builtins) 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. rollup A PR which is a rollup labels Aug 8, 2025
@tgross35
Copy link
Contributor Author

tgross35 commented Aug 8, 2025

Recreated from #145063

@bors r+ rollup=never p=5

@bors
Copy link
Collaborator

bors commented Aug 8, 2025

📌 Commit 338a3e0 has been approved by tgross35

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 8, 2025
@bors
Copy link
Collaborator

bors commented Aug 8, 2025

⌛ Testing commit 338a3e0 with merge 67d45f4...

@bors
Copy link
Collaborator

bors commented Aug 8, 2025

☀️ Test successful - checks-actions
Approved by: tgross35
Pushing 67d45f4 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Aug 8, 2025
@bors bors merged commit 67d45f4 into rust-lang:master Aug 8, 2025
11 checks passed
@rustbot rustbot added this to the 1.91.0 milestone Aug 8, 2025
@rust-timer
Copy link
Collaborator

📌 Perf builds for each rolled up PR:

PR# Message Perf Build Sha
#144705 compiler-builtins: plumb LSE support for aarch64 on linux/g… 2b719f6f4f7fa4f46b344e58798935509e722b3b (link)
#144857 Port #[allow_internal_unsafe] to the new attribute system ae1487aa9922de7642c448cc0908584026699e1c (link)
#144900 Stabilize unsigned_signed_diff feature a5285b4fbb82a25158e344190acca7759ecf4d68 (link)
#144903 Rename begin_panic_handler to panic_handler 4a5b3fdb9cbb0eb479d0abcf54252c2edb23a2db (link)
#144974 compiler-builtins subtree update c2b481d4315030760ae95e30d749a1a8da4c6ba7 (link)
#145007 Fix build/doc/test of error index generator e28716655e9e1bd86cc3ac7e4ac0261727d1595f (link)
#145018 Derive Hash for rustc_public types 8d3bdf1b7cccd562b787be90a9aa6f607b9a9b3a (link)
#145045 doc(library): Fix Markdown in Iterator::by_ref 288ea4a18d71b42cb8baa8e3366e9fe85389e627 (link)
#145046 Fix doc comment of File::try_lock and File::try_lock_shared d42d1adffd5ae3f0586b20c54bd08f42d02431be (link)

previous master: a980cd4311

In the case of a perf regression, run the following command for each PR you suspect might be the cause: @rust-timer build $SHA

Copy link
Contributor

github-actions bot commented Aug 8, 2025

What is this? This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing a980cd4 (parent) -> 67d45f4 (this PR)

Test differences

Show 66 test diffs

Stage 0

  • core::builder::tests::defaults::doc_default: pass -> [missing] (J0)
  • core::builder::tests::dist::doc_ci: pass -> [missing] (J0)
  • core::builder::tests::snapshot::build_error_index: [missing] -> pass (J0)
  • core::builder::tests::snapshot::doc_all: [missing] -> pass (J0)

Stage 1

  • errors::verify_passes_allow_internal_unstable_80: pass -> [missing] (J0)
  • errors::verify_passes_macro_only_attribute_80: [missing] -> pass (J0)

Additionally, 60 doctest diffs were found. These are ignored, as they are noisy.

Job group index

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard 67d45f49e09cb8f355df2ffae22cfc3d7ee6c278 --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

  1. aarch64-apple: 6972.1s -> 4910.3s (-29.6%)
  2. pr-check-2: 2157.0s -> 2700.8s (25.2%)
  3. dist-aarch64-apple: 7082.0s -> 5372.6s (-24.1%)
  4. pr-check-1: 1453.1s -> 1796.0s (23.6%)
  5. dist-x86_64-apple: 11888.7s -> 9452.6s (-20.5%)
  6. x86_64-apple-1: 6526.5s -> 7749.9s (18.7%)
  7. aarch64-gnu-llvm-19-1: 3167.5s -> 3681.5s (16.2%)
  8. x86_64-gnu-llvm-19: 2480.7s -> 2881.2s (16.1%)
  9. x86_64-rust-for-linux: 2555.7s -> 2948.0s (15.3%)
  10. i686-gnu-nopt-1: 7307.2s -> 8241.6s (12.8%)
How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (67d45f4): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Our benchmarks found a performance regression caused by this PR.
This might be an actual regression, but it can also be just noise.

Next Steps:

  • If the regression was expected or you think it can be justified,
    please write a comment with sufficient written justification, and add
    @rustbot label: +perf-regression-triaged to it, to mark the regression as triaged.
  • If you think that you know of a way to resolve the regression, try to create
    a new PR with a fix for the regression.
  • If you do not understand the regression or you think that it is just noise,
    you can ask the @rust-lang/wg-compiler-performance working group for help (members of this group
    were already notified of this PR).

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

mean range count
Regressions ❌
(primary)
0.8% [0.1%, 4.3%] 126
Regressions ❌
(secondary)
0.6% [0.1%, 1.5%] 39
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-1.8% [-2.9%, -0.1%] 9
All ❌✅ (primary) 0.8% [0.1%, 4.3%] 126

Max RSS (memory usage)

Results (primary 3.5%, secondary -0.3%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)
3.5% [3.5%, 3.5%] 1
Regressions ❌
(secondary)
1.2% [1.0%, 1.4%] 2
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-3.4% [-3.4%, -3.4%] 1
All ❌✅ (primary) 3.5% [3.5%, 3.5%] 1

Cycles

Results (primary 2.5%, secondary 1.4%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)
2.5% [2.2%, 3.0%] 3
Regressions ❌
(secondary)
3.3% [2.1%, 4.5%] 2
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-2.5% [-2.5%, -2.5%] 1
All ❌✅ (primary) 2.5% [2.2%, 3.0%] 3

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 465.2s -> 464.119s (-0.23%)
Artifact size: 377.41 MiB -> 377.50 MiB (0.02%)

@lqd
Copy link
Member

lqd commented Aug 8, 2025

I'm putting money on #144857

@tgross35 tgross35 deleted the rollup-0tillrm branch August 8, 2025 08:23
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-testsuite Area: The testsuite used to check the correctness of rustc merged-by-bors This PR was explicitly merged by bors. perf-regression Performance regression. rollup A PR which is a rollup S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. 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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.