Skip to content

Rollup of 13 pull requests #142213

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 31 commits into from

Conversation

workingjubilee
Copy link
Member

@workingjubilee workingjubilee commented Jun 8, 2025

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

workingjubilee and others added 30 commits June 4, 2025 13:56
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.
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.
also adjust the wording a little so that we don't say "the error occurred here" for two different spans
It's not needed an it slows down the job considerably.

Signed-off-by: Jakub Beránek <berykubik@gmail.com>
Signed-off-by: Jakub Beránek <berykubik@gmail.com>
…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
…oli-obk

const-eval error: always say in which item the error occurred

I don't see why "is this generic" should make a difference. It may be reasonable to key this on whether the error occurs in a `const fn` that was invoked by a const (making it non-obvious which constant it is) vs inside the body of the const.

r? `````@oli-obk`````
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 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 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. labels Jun 8, 2025
@workingjubilee
Copy link
Member Author

@bors r+ p=5

@rustbot rustbot added the rollup A PR which is a rollup label Jun 8, 2025
@workingjubilee
Copy link
Member Author

@bors rollup=never

@bors
Copy link
Collaborator

bors commented Jun 8, 2025

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

bors commented Jun 8, 2025

🔒 Merge conflict

This pull request and the master branch diverged in a way that cannot be automatically merged. Please rebase on top of the latest master branch, and let the reviewer approve again.

How do I rebase?

Assuming self is your fork and upstream is this repository, you can resolve the conflict following these steps:

  1. git checkout rollup-d6rid73 (switch to your branch)
  2. git fetch upstream master (retrieve the latest master)
  3. git rebase upstream/master -p (rebase on top of it)
  4. Follow the on-screen instruction to resolve conflicts (check git status if you got lost).
  5. git push self rollup-d6rid73 --force-with-lease (update this PR)

You may also read Git Rebasing to Resolve Conflicts by Drew Blessing for a short tutorial.

Please avoid the "Resolve conflicts" button on GitHub. It uses git merge instead of git rebase which makes the PR commit history more difficult to read.

Sometimes step 4 will complete without asking for resolution. This is usually due to difference between how Cargo.lock conflict is handled during merge and rebase. This is normal, and you should still perform step 5 to update this PR.

Error message
Removing tests/ui/default-method-parsing.rs
Removing tests/ui/constructor-lifetime-args.rs
Removing tests/ui/complex.rs
Auto-merging library/core/src/sync/atomic.rs
Auto-merging library/core/src/intrinsics/mod.rs
Auto-merging compiler/rustc_hir_analysis/src/check/intrinsic.rs
CONFLICT (content): Merge conflict in compiler/rustc_hir_analysis/src/check/intrinsic.rs
Auto-merging compiler/rustc_codegen_ssa/src/mir/intrinsic.rs
Auto-merging compiler/rustc_codegen_cranelift/src/intrinsics/mod.rs
Automatic merge failed; fix conflicts and then commit the result.

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jun 8, 2025
@bors
Copy link
Collaborator

bors commented Jun 9, 2025

☔ The latest upstream changes (presumably #141700) made this pull request unmergeable. Please resolve the merge conflicts.

@workingjubilee workingjubilee deleted the rollup-d6rid73 branch June 9, 2025 00:18
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 O-linux Operating system: Linux rollup A PR which is a rollup S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. 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.

9 participants