Skip to content

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

madsmtm and others added 14 commits October 3, 2024 00:27
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.
…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.
…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
…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
@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Oct 31, 2024
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=5

@bors
Copy link
Collaborator

bors commented Oct 31, 2024

📌 Commit f7c3fa2 has been approved by matthiaskrgr

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 Oct 31, 2024
@bors
Copy link
Collaborator

bors commented Oct 31, 2024

⌛ Testing commit f7c3fa2 with merge 3de9780...

bors added a commit to rust-lang-ci/rust that referenced this pull request Oct 31, 2024
…iaskrgr

Rollup of 5 pull requests

Successful merges:

 - rust-lang#131168 (Fix `target_os` for `mipsel-sony-psx`)
 - rust-lang#132209 (Fix validation when lowering `?` trait bounds)
 - rust-lang#132357 (Improve missing_abi lint)
 - rust-lang#132385 (compiler: Move `rustc_target::spec::abi::Abi` to `rustc_abi::ExternAbi`)
 - rust-lang#132417 (macOS: Document the difference between Clang's `-darwin` and `-macosx` targets)

r? `@ghost`
`@rustbot` modify labels: rollup
@rust-log-analyzer
Copy link
Collaborator

The job x86_64-msvc-ext failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)
[RUSTC-TIMING] miri test:false 5.655
error: failed to remove file `C:\a\rust\rust\build\x86_64-pc-windows-msvc\stage1-tools\x86_64-pc-windows-msvc\release\miri.exe`

Caused by:
  Access is denied. (os error 5)
Command has failed. Rerun with -v to see more details.
  local time: Thu, Oct 31, 2024 11:29:48 PM
  network time: Thu, 31 Oct 2024 23:29:48 GMT
##[error]Process completed with exit code 1.
Post job cleanup.

@bors
Copy link
Collaborator

bors commented Oct 31, 2024

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Oct 31, 2024
@matthiaskrgr matthiaskrgr added the CI-spurious-fail-msvc CI spurious failure: target env msvc label Nov 2, 2024
@matthiaskrgr matthiaskrgr deleted the rollup-w1vqgx9 branch January 25, 2025 09:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CI-spurious-fail-msvc CI spurious failure: target env msvc rollup A PR which is a rollup S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants