-
Notifications
You must be signed in to change notification settings - Fork 13.4k
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
Rollup of 13 pull requests #142213
Conversation
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`
@bors r+ p=5 |
@bors rollup=never |
🔒 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
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 Sometimes step 4 will complete without asking for resolution. This is usually due to difference between how Error message
|
☔ The latest upstream changes (presumably #141700) made this pull request unmergeable. Please resolve the merge conflicts. |
Successful merges:
__alignof
#141803 (Remove rustc's notion of "preferred" alignment AKA__alignof
)loongarch32-unknown-none*
#142053 (Add new Tier-3 targets:loongarch32-unknown-none*
)tests/ui
: A New Order [6/N] #142132 (tests/ui
: A New Order [6/N])tests/ui
: A New Order [7/N] #142171 (tests/ui
: A New Order [7/N])target.min_global_align
as anAlign
#142179 (storetarget.min_global_align
as anAlign
)mingw-check-tidy
job #142199 (Do not free disk space in themingw-check-tidy
job)mingw-check-tidy
on auto builds #142210 (Runmingw-check-tidy
on auto builds)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup