Skip to content
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 5 pull requests #132420

Closed
wants to merge 14 commits into from

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
Contributor

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
Contributor

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
Contributor

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
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