Rollup of 9 pull requests #132435
Merged
Rollup of 9 pull requests #132435
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Previously set to `target_os = "none"` and `target_env = "psx"`, but although the Playstation 1 is _close_ to a bare metal target in some regards, it's still very much an operating system, so we should set `target_os = "psx"`. This also matches the `mipsel-sony-psp` target, which sets `target_os = "psp"`.
Completely abandon usage of rustc_target in these crates, as they need no special knowledge of rustc's target tuples.
LLVM continues to align more 128-bit integers to 128-bits in the data layout rather than relying on the high level language to do it. Update SPARC target files to match and add a backcompat replacement for current LLVMs. See llvm/llvm-project#106951 for details
…dtwco Fix `target_os` for `mipsel-sony-psx` Previously set to `target_os = "none"` and `target_env = "psx"` in [the PR introducing the target](rust-lang#102689), but although the Playstation 1 is _close_ to a bare metal target in some regards, it's still very much an operating system, so we should instead set `target_os = "psx"`. This also matches the `mipsel-sony-psp` target, which sets `target_os = "psp"`. CC target maintainer ``@ayrtonm.`` If there's any code out there that uses `cfg(target_env = "psx")`, they can use `cfg(any(target_os = "psx", target_env = "psx"))` until they bump their MSRV to a version where this is fully fixed.
Fix validation when lowering `?` trait bounds Pass the unlowered (`rustc_hir`) polarity to `lower_poly_trait_ref`. This allows us to actually *validate* that generic args are actually valid on `?Trait` paths. This actually regressed in rust-lang#113671 because that PR changed the behavior where we were inadvertently re-lowering paths as `BoundPolarity::Positive`, which was also coincidentally the only place we were enforcing the generics on `?Trait` paths were correct.
Bump Fuchsia r? `@Kobzol` try-job: x86_64-fuchsia https://fxbug.dev/376114512
…rrors Improve missing_abi lint This is for the migration lint for rust-lang/rfcs#3722 It is not yet marked as an edition migration lint, because `Edition2027` doesn't exist yet. The lint now includes a machine applicable suggestion: ``` warning: extern declarations without an explicit ABI are deprecated --> src/main.rs:3:1 | 3 | extern fn a() {} | ^^^^^^ help: explicitly specify the C ABI: `extern "C"` | ```
…bi, r=jieyouxu,compiler-errors compiler: Move `rustc_target::spec::abi::Abi` to `rustc_abi::ExternAbi` Lift `enum Abi` from its rather odd place in the middle of rustc_target, and make it available again from rustc_abi. You know, the crate where you would expect the enum that describes all the ABIs to be? The platform-neutral ones, at least. This will help further refactoring of how we handle ABIs in the near future[^0]. Rename `Abi` to `ExternAbi` because quite a lot of the compiler overloads the concept of "ABI" enough that the existing name is imprecise and it is often renamed _anyway_. Often this was to avoid conflicts with the *other* type formerly known as `Abi` (now named BackendRepr[^1]), but sometimes it is just for clarity, and this name seems more self-explanatory. It does get reexported, though, using its old name, to reduce the odds of merge-conflicting over the entire tree. All of `ExternAbi`'s friends come along for the ride, which costs adding some optional dependencies to the rustc_abi crate. However, all of this also allows simply moving three crates entirely off rustc_target: - rustc_hir_pretty - rustc_lint_defs - rustc_mir_build This odd selection is mostly to demonstrate a secondary motivation: The majority of the front-end of the compiler should be as target-agnostic as possible, and it is easier to assure this if they simply don't depend on the crate that describes targets. Note that I didn't migrate crates that don't benefit from it in this way yet, and I didn't survey every last crate. [^0]: This is being undertaken as part of rust-lang#119183 [^1]: rust-lang#132246
continue `TypingMode` refactor There are still quite a few places which (indirectly) rely on the `Reveal` of a `ParamEnv`, but we're slowly getting there r? `@compiler-errors`
…erence, r=jieyouxu macOS: Document the difference between Clang's `-darwin` and `-macosx` targets `rustc`'s `*-apple-darwin` targets are badly named (they should've been called `*-apple-macos`), and this causes confusion wrt. the similarly named but somewhat incompatible Clang targets. So let's document the difference to at least make things a _little_ easier on our users. ``@rustbot`` label O-macos A-docs
…, r=workingjubilee Remove `""` case from RISC-V `llvm_abiname` match statement For RISC-V, `""` isn't the always the same ABI as `"ilp32"`/`"lp64"` (`""` means LLVM will infer the ABI based on the enabled target features), but `create_object_file` currently assumes that it is. Since all RISC-V targets explicitly specify their ABI since rust-lang#131807, this PR removes `""` from the match arm's pattern (meaning an empty string will now fall through to the `_ => bug!` arm). r? `@workingjubilee`
llvm: Match new LLVM 128-bit integer alignment on sparc LLVM continues to align more 128-bit integers to 128-bits in the data layout rather than relying on the high level language to do it. Update SPARC target files to match and add a backcompat replacement for current LLVMs. See llvm/llvm-project#106951 for details `@rustbot` label: +llvm-main r? `@durin42` (Please wait for the LLVM CI to come back before approving), creating this PR to get it tested there.
rustbot
added
A-testsuite
|
@bors r+ rollup=never p=9 |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
📌 Perf builds for each rolled up PR:
previous master: 24254efb43 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
This was referenced Nov 1, 2024
Merged
|
Finished benchmarking commit (a8e1186): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)Results (primary -2.0%, secondary -1.9%)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.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 784.475s -> 782.66s (-0.23%) |
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
target_osformipsel-sony-psx#131168 (Fixtarget_osformipsel-sony-psx)?trait bounds #132209 (Fix validation when lowering?trait bounds)rustc_target::spec::abi::Abitorustc_abi::ExternAbi#132385 (compiler: Moverustc_target::spec::abi::Abitorustc_abi::ExternAbi)TypingModerefactor #132403 (continueTypingModerefactor)-darwinand-macosxtargets #132417 (macOS: Document the difference between Clang's-darwinand-macosxtargets)""case from RISC-Vllvm_abinamematch statement #132421 (Remove""case from RISC-Vllvm_abinamematch statement)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup