Skip to content

Rollup of 12 pull requests #142220

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 29 commits into from
Jun 9, 2025
Merged

Conversation

workingjubilee
Copy link
Member

@workingjubilee workingjubilee commented Jun 9, 2025

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

heiher and others added 29 commits June 5, 2025 07:59
And consistently use try_canonicalize rather than canonicalize.
Before this change we had two different ways to attempt to locate the
sysroot which are inconsistently used:
* get_or_default_sysroot which tries to locate based on the 0th cli
  argument and if that doesn't work falls back to locating it using the
  librustc_driver.so location and returns a single path.,
* sysroot_candidates which takes the former and additionally does
  another attempt at locating using librustc_driver.so except without
  linux multiarch handling and then returns both paths.,

The latter was originally introduced to be able to locate the codegen
backend back when cg_llvm was dynamically linked even for a custom
driver when the --sysroot passed in does not contain a copy of cg_llvm.
Back then get_or_default_sysroot did not attempt to locate the sysroot
based on the location of librustc_driver.so yet. Because that is now
done, the only case where removing sysroot_candidates can break things
is if you have a custom driver inside what looks like a sysroot
including the lib/rustlib directory, but which is missing some parts of
the full sysroot like eg rust-lld.
Same reason as it is on Option's.
It's not needed an it slows down the job considerably.

Signed-off-by: Jakub Beránek <[email protected]>
In PR 90877 T-lang decided not to remove `intrinsics::pref_align_of`.
However, the intrinsic and its supporting code
1.  is a nightly feature, so can be removed at compiler/libs discretion
2.  requires considerable effort in the compiler to support, as it
    necessarily complicates every single site reasoning about alignment
3.  has been justified based on relevance to codegen, but it is only a
    requirement for C++ (not C, not Rust) stack frame layout for AIX,
    in ways Rust would not consider even with increased C++ interop
4.  is only used by rustc to overalign some globals, not correctness
5.  can be adequately replaced by other rules for globals, as it mostly
    affects alignments for a few types under 16 bytes of alignment
6.  has only one clear benefactor: automating C -> Rust translation
    for GNU extensions like `__alignof`
7.  such code was likely intended to be `alignof` or `_Alignof`,
    because the GNU extension is a "false friend" of the C keyword,
    which makes the choice to support such a mapping very questionable
8.  makes it easy to do incorrect codegen in the compiler by its mere
    presence as usual Rust rules of alignment (e.g. `size == align * N`)
    do not hold with preferred alignment

The implementation is clearly damaging the code quality of the compiler.
Thus it is within the compiler team's purview to simply rip it out.
If T-lang wishes to have this intrinsic restored for c2rust's benefit,
it would have to use a radically different implementation that somehow
does not cause internal incorrectness.

Until then, remove the intrinsic and its supporting code, as one tool
and an ill-considered GCC extension cannot justify risking correctness.

Because we touch a fair amount of the compiler to change this at all,
and unfortunately the duplication of AbiAndPrefAlign is deep-rooted,
we keep an "AbiAlign" type which we can wean code off later.
We will want to remove many cases of `.abi`, including `.abi.thing`,
so this may simplify future PRs and certainly doesn't hurt.

We omit DerefMut because mutation is much rarer and localized.
…r=bjorn3

Remove rustc's notion of "preferred" alignment AKA `__alignof`

In PR rust-lang#90877 T-lang decided not to remove `intrinsics::pref_align_of`. However, the intrinsic and its supporting code
1.  is a nightly feature, so can be removed at compiler/libs discretion
2.  requires considerable effort in the compiler to support, as it necessarily complicates every single site reasoning about alignment
3.  has been justified based on relevance to codegen, but it is only a requirement for C++ (not C, not Rust) stack frame layout for AIX[^1], in ways Rust would not consider even with increased C++ interop
4.  is only used by rustc to overalign some globals, not correctness[^2]
5.  can be adequately replaced by other rules for globals, as it mostly affects alignments for a few types under 16 bytes of alignment
6.  has only one clear beneficiary: automating C -> Rust translation for GNU extensions like `__alignof`[^3]
7.  such code was likely intended to be `alignof` or `_Alignof`, because the GNU extension is a "false friend" of the C keyword, which makes the choice to support such a mapping very questionable
8.  makes it easy to do incorrect codegen in the compiler by its mere presence as usual Rust rules of alignment (e.g. `size == align * N`) do not hold with preferred alignment[^4]

Despite an automated translation tool like c2rust using it, we have made multiple attempts to find a crate that actually has been committed to public repositories, like GitHub or crates.io, using such translated code. We have found none. While it is possible someone privately uses this intrinsic, it seems unlikely, and it is behind a feature gate that will warn about using the internal features of rustc.

The implementation is clearly damaging the code quality of the compiler. Thus it is within the compiler team's purview to simply rip it out. If T-lang wishes to have this intrinsic restored for c2rust's benefit, it would have to use a radically different implementation that somehow does not cause internal incorrectness.

Until then, remove the intrinsic and its supporting code, as one tool and an ill-considered GCC extension cannot justify risking correctness.

Because we touch a fair amount of the compiler to change this at all, and unfortunately the duplication of AbiAndPrefAlign is deep-rooted, we keep an "AbiAlign" type which we can wean code off later.

[^1]: rust-lang#91971 (comment)
[^2]: as viewable in the code altered by this PR
[^3]: c2rust: https://github.com/immunant/c2rust/blame/3b1ec86b9b0cf363adfd3178cc45a891a970eef2/c2rust-transpile/src/translator/mod.rs#L3175
[^4]: rust-lang/rustc_codegen_cranelift#1560
Add new Tier-3 targets: `loongarch32-unknown-none*`

MCP: rust-lang/compiler-team#865

NOTE: LoongArch32 ELF object support is available starting with object v0.37.0.
…r=petrochenkov

Replace all uses of sysroot_candidates with get_or_default_sysroot

Before this change we had two different ways to attempt to locate the sysroot which are inconsistently used:
* `get_or_default_sysroot` which tries to locate based on the 0th cli argument and if that doesn't work falls back to locating it using the librustc_driver.so location and returns a single path.,
* `sysroot_candidates` which takes the former and additionally does another attempt at locating using `librustc_driver.so` except without linux multiarch handling and then returns both paths.,

The latter was originally introduced to be able to locate the codegen backend back when cg_llvm was dynamically linked even for a custom driver when the `--sysroot` passed in does not contain a copy of cg_llvm. Back then `get_or_default_sysroot` did not attempt to locate the sysroot based on the location of librustc_driver.so yet. Because that is now done, the only case where removing `sysroot_candidates` can break things is if you have a custom driver inside what looks like a sysroot including the `lib/rustlib` directory, but which is missing some parts of the full sysroot like eg rust-lld.

Follow up to rust-lang#138404
…-map, r=jieyouxu

compiler: Add track_caller to AbiMapping::unwrap

Same reason as it is on Option's.
`tests/ui`: A New Order [6/N]

> [!NOTE]
>
> Intermediate commits are intended to help review, but will be squashed prior to merge.

Some `tests/ui/` housekeeping, to trim down number of tests directly under `tests/ui/`. Part of rust-lang#133895.

r? `````@jieyouxu`````

auxiliary tag means some changes in realted auxiliary file for test
…ingjubilee,traviscross

UnsafePinned: update get() docs and signature to allow shared mutation

Follow-up to rust-lang#140638, making `get` consistent with the fact that there's an `UnsafeCell` inside this type now by returning `*mut T` instead of `*const T`.

Cc ``@rust-lang/libs-api``
Tracking issue: rust-lang#125735
`tests/ui`: A New Order [7/N]

> [!NOTE]
>
> Intermediate commits are intended to help review, but will be squashed prior to merge.

Some `tests/ui/` housekeeping, to trim down number of tests directly under `tests/ui/`. Part of rust-lang#133895.
… r=workingjubilee

store `target.min_global_align` as an `Align`

Parse the alignment properly when the target is defined/parsed, and error out on invalid alignment values. That means this work doesn't need to happen for every global in each backend.
Added test for 30904

Test that was deleted by mistake in this commit
rust-lang@564c78a#diff-85d65712084246fc61f287664eef63b0b25ba0a5c8b69a4a59a9454b6a3ebac4

The original issue is still open and the problem is not solved (if this is even a problem, but the error is still here at least)
…ieyouxu

Remove all unused feature gates from the compiler
…acrum

Do not free disk space in the `mingw-check-tidy` job

It's not needed an it slows down the job considerably. It took ~2 minutes out of the total 8-9 minutes of running `mingw-check-tidy`.
…mulacrum

Run `mingw-check-tidy` on auto builds

This has two advantages:
- It moves `auto` builds closer to being a superset of PR CI builds
- It allows us to reuse the Docker cache for the job in PR CI, thus speeding up the job in PR CI considerably

Discussed [here](https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/PR.20ci.20seems.20much.20to.20slow).

r? ``@Mark-Simulacrum``
@rustbot rustbot added the A-compiletest Area: The compiletest test runner label Jun 9, 2025
@rustbot rustbot added A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. A-query-system Area: The rustc query system (https://rustc-dev-guide.rust-lang.org/query.html) A-testsuite Area: The testsuite used to check the correctness of rustc A-translation Area: Translation infrastructure, and migrating existing diagnostics to SessionDiagnostic O-linux Operating system: Linux 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-infra Relevant to the infrastructure 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-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Jun 9, 2025
@workingjubilee
Copy link
Member Author

@bors r+ rollup=never p=5

@bors
Copy link
Collaborator

bors commented Jun 9, 2025

📌 Commit e91f985 has been approved by workingjubilee

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

bors commented Jun 9, 2025

⌛ Testing commit e91f985 with merge 334ba81...

@bors
Copy link
Collaborator

bors commented Jun 9, 2025

☀️ Test successful - checks-actions
Approved by: workingjubilee
Pushing 334ba81 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jun 9, 2025
@bors bors merged commit 334ba81 into rust-lang:master Jun 9, 2025
11 checks passed
@rustbot rustbot added this to the 1.89.0 milestone Jun 9, 2025
Copy link
Contributor

github-actions bot commented Jun 9, 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 c31cccb (parent) -> 334ba81 (this PR)

Test differences

Show 854 test diffs

Stage 1

  • [assembly] tests/assembly/targets/targets-elf.rs#loongarch32_unknown_none: [missing] -> pass (J0)
  • [assembly] tests/assembly/targets/targets-elf.rs#loongarch32_unknown_none_softfloat: [missing] -> pass (J0)
  • [ui] tests/ui/attributes/attr_unknown_custom_attr.rs: [missing] -> pass (J0)
  • [ui] tests/ui/attributes/crate-name-attr-validation.rs: [missing] -> pass (J0)
  • [ui] tests/ui/attributes/crate-name-mismatch.rs: [missing] -> pass (J0)
  • [ui] tests/ui/attributes/custom_attr_multisegment_error.rs: [missing] -> pass (J0)
  • [ui] tests/ui/complex.rs: pass -> [missing] (J0)
  • [ui] tests/ui/conservative_impl_trait.rs: pass -> [missing] (J0)
  • [ui] tests/ui/constructor-lifetime-args.rs: pass -> [missing] (J0)
  • [ui] tests/ui/crate-leading-sep.rs: pass -> [missing] (J0)
  • [ui] tests/ui/crate-method-reexport-grrrrrrr.rs: pass -> [missing] (J0)
  • [ui] tests/ui/crate-name-attr-used.rs: pass -> [missing] (J0)
  • [ui] tests/ui/crate-name-mismatch.rs: pass -> [missing] (J0)
  • [ui] tests/ui/crate_type_flag.rs: pass -> [missing] (J0)
  • [ui] tests/ui/cross-crate/cross-crate-method-reexport.rs: [missing] -> pass (J0)
  • [ui] tests/ui/custom-attribute-multisegment.rs: pass -> [missing] (J0)
  • [ui] tests/ui/custom-test-frameworks-simple.rs: pass -> [missing] (J0)
  • [ui] tests/ui/custom_attribute.rs: pass -> [missing] (J0)
  • [ui] tests/ui/deep.rs: pass -> [missing] (J0)
  • [ui] tests/ui/default-method-parsing.rs: pass -> [missing] (J0)
  • [ui] tests/ui/default-method-simple.rs: pass -> [missing] (J0)
  • [ui] tests/ui/diagnostic-width/impl-trait-invalid-iterator-error.rs: [missing] -> pass (J0)
  • [ui] tests/ui/imports/global-path-resolution-drop.rs: [missing] -> pass (J0)
  • [ui] tests/ui/lifetimes/constructor-lifetime-early-binding-error.rs: [missing] -> pass (J0)
  • [ui] tests/ui/linking/crate-type-invalid-flag-error.rs: [missing] -> pass (J0)
  • [ui] tests/ui/runtime/deep_recursion.rs: [missing] -> pass (J0)
  • [ui] tests/ui/test-attrs/custom_test_frameworks_simple.rs: [missing] -> pass (J0)
  • [ui] tests/ui/traits/default_method_simple.rs: [missing] -> pass (J0)
  • [ui] tests/ui/unboxed-closures/fn-traits-hrtb-coercion.rs: [missing] -> pass (J0)
  • spec::tests::loongarch32_unknown_none: [missing] -> pass (J1)
  • spec::tests::loongarch32_unknown_none_softfloat: [missing] -> pass (J1)

Stage 2

  • [ui] tests/ui/attributes/attr_unknown_custom_attr.rs: [missing] -> pass (J2)
  • [ui] tests/ui/attributes/crate-name-attr-validation.rs: [missing] -> pass (J2)
  • [ui] tests/ui/attributes/crate-name-mismatch.rs: [missing] -> pass (J2)
  • [ui] tests/ui/attributes/custom_attr_multisegment_error.rs: [missing] -> pass (J2)
  • [ui] tests/ui/complex.rs: pass -> [missing] (J2)
  • [ui] tests/ui/conservative_impl_trait.rs: pass -> [missing] (J2)
  • [ui] tests/ui/constructor-lifetime-args.rs: pass -> [missing] (J2)
  • [ui] tests/ui/crate-leading-sep.rs: pass -> [missing] (J2)
  • [ui] tests/ui/crate-method-reexport-grrrrrrr.rs: pass -> [missing] (J2)
  • [ui] tests/ui/crate-name-attr-used.rs: pass -> [missing] (J2)
  • [ui] tests/ui/crate-name-mismatch.rs: pass -> [missing] (J2)
  • [ui] tests/ui/crate_type_flag.rs: pass -> [missing] (J2)
  • [ui] tests/ui/cross-crate/cross-crate-method-reexport.rs: [missing] -> pass (J2)
  • [ui] tests/ui/custom-attribute-multisegment.rs: pass -> [missing] (J2)
  • [ui] tests/ui/custom-test-frameworks-simple.rs: pass -> [missing] (J2)
  • [ui] tests/ui/custom_attribute.rs: pass -> [missing] (J2)
  • [ui] tests/ui/deep.rs: pass -> [missing] (J2)
  • [ui] tests/ui/default-method-parsing.rs: pass -> [missing] (J2)
  • [ui] tests/ui/default-method-simple.rs: pass -> [missing] (J2)
  • [ui] tests/ui/diagnostic-width/impl-trait-invalid-iterator-error.rs: [missing] -> pass (J2)
  • [ui] tests/ui/imports/global-path-resolution-drop.rs: [missing] -> pass (J2)
  • [ui] tests/ui/lifetimes/constructor-lifetime-early-binding-error.rs: [missing] -> pass (J2)
  • [ui] tests/ui/linking/crate-type-invalid-flag-error.rs: [missing] -> pass (J2)
  • [ui] tests/ui/runtime/deep_recursion.rs: [missing] -> pass (J2)
  • [ui] tests/ui/test-attrs/custom_test_frameworks_simple.rs: [missing] -> pass (J2)
  • [ui] tests/ui/traits/default_method_simple.rs: [missing] -> pass (J2)
  • [ui] tests/ui/unboxed-closures/fn-traits-hrtb-coercion.rs: [missing] -> pass (J2)
  • [assembly] tests/assembly/targets/targets-elf.rs#loongarch32_unknown_none: [missing] -> pass (J3)
  • [assembly] tests/assembly/targets/targets-elf.rs#loongarch32_unknown_none_softfloat: [missing] -> pass (J3)

Additionally, 794 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 334ba812755b974ecc46713fcdd38836b6182746 --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. x86_64-apple-2: 4551.8s -> 7012.5s (54.1%)
  2. x86_64-apple-1: 5872.2s -> 8050.9s (37.1%)
  3. dist-apple-various: 5738.1s -> 7628.9s (33.0%)
  4. mingw-check-1: 1604.1s -> 1972.6s (23.0%)
  5. i686-gnu-2: 5463.0s -> 6329.6s (15.9%)
  6. aarch64-apple: 3955.7s -> 4524.6s (14.4%)
  7. x86_64-gnu-llvm-19-1: 3277.3s -> 3722.5s (13.6%)
  8. mingw-check-2: 1873.0s -> 2106.3s (12.5%)
  9. x86_64-rust-for-linux: 2503.4s -> 2800.2s (11.9%)
  10. dist-x86_64-apple: 7491.9s -> 8376.1s (11.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

📌 Perf builds for each rolled up PR:

PR# Message Perf Build Sha
#141803 Remove rustc's notion of "preferred" alignment AKA `__align… 9e617df2a02b54addd75ec04eacda3c7535b53d5 (link)
#142053 Add new Tier-3 targets: loongarch32-unknown-none* ab0a33a473b1ca89246304fcb3011901b5f8af9e (link)
#142089 Replace all uses of sysroot_candidates with get_or_default_… 96766a4c35023b6ca43c3a0dc4f70adf8f258edd (link)
#142108 compiler: Add track_caller to AbiMapping::unwrap 1f092aa33b306e28bccc131e7cb1db27c49fc9eb (link)
#142132 tests/ui: A New Order [6/N] 1ded95411952579a9290f5bb039714d3e8bf7d6e (link)
#142162 UnsafePinned: update get() docs and signature to allow shar… 46b495c5672ab3fac3edf1214b8776b520209d43 (link)
#142171 tests/ui: A New Order [7/N] 602a2ffe1fed042f8c1314d20c28ea0671b8d866 (link)
#142179 store target.min_global_align as an Align d4e4e9f834b9a751da630d3344c583550071d155 (link)
#142183 Added test for 30904 f650e0d0065dfc91995ce1f26878953253e55722 (link)
#142194 Remove all unused feature gates from the compiler 92f0e039d3d40e0194725b3e9a9acba2bb976025 (link)
#142199 Do not free disk space in the mingw-check-tidy job d75eedb37aeeef22eea53c0be6adf6489074e94c (link)
#142210 Run mingw-check-tidy on auto builds eadeb0dff35f607a229ce12a1ef07915281adaaf (link)

previous master: c31cccb7b5

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

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (334ba81): comparison URL.

Overall result: ❌✅ regressions and improvements - no action needed

@rustbot label: -perf-regression

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
0.4% [0.2%, 0.5%] 2
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-0.5% [-0.5%, -0.5%] 1
All ❌✅ (primary) - - 0

Max RSS (memory usage)

Results (primary 2.3%, secondary -5.2%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
2.3% [2.3%, 2.3%] 1
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-5.2% [-8.7%, -2.6%] 3
All ❌✅ (primary) 2.3% [2.3%, 2.3%] 1

Cycles

Results (secondary 6.4%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
6.4% [6.4%, 6.4%] 1
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) - - 0

Binary size

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

Bootstrap: 751.176s -> 755.214s (0.54%)
Artifact size: 372.27 MiB -> 372.33 MiB (0.02%)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-compiletest Area: The compiletest test runner A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. A-query-system Area: The rustc query system (https://rustc-dev-guide.rust-lang.org/query.html) A-testsuite Area: The testsuite used to check the correctness of rustc A-translation Area: Translation infrastructure, and migrating existing diagnostics to SessionDiagnostic merged-by-bors This PR was explicitly merged by bors. O-linux Operating system: Linux 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-infra Relevant to the infrastructure 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-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants