Skip to content

Rollup of 10 pull requests #142342

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

Conversation

matthiaskrgr
Copy link
Member

@matthiaskrgr matthiaskrgr commented Jun 11, 2025

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

NotLebedev and others added 29 commits May 27, 2025 11:12
```
error[E0621]: explicit lifetime required in the type of `x`
  --> $DIR/42701_one_named_and_one_anonymous.rs:10:9
   |
LL |         &*x
   |         ^^^ lifetime `'a` required
   |
help: add explicit lifetime `'a` to the type of `x`
   |
LL | fn foo2<'a>(a: &'a Foo, x: &'a i32) -> &'a i32 {
   |                             ++
```
Lets the test still work on different architectures.
We move the vectorcall ABI tests into their own file which is now
only run on x86-64, while replacing them with rust-cold ABI tests
so that aarch64 hosts continue to test an unstable ABI.

A better solution might be cross-compiling or something but
I really don't have time for that right now.
To centralize this hack in one place with a backlink to the issue
tracking this hack, as this logic is also needed by compiletest to
implement a `//@ needs-target-std` directive.
To support tests to condition their (potentially cross-compile)
execution based on whether the target supports std.
Instead of a jumble of `ignore-$target`s, `ignore-none` and
`ignore-nvptx`.
No changes; just removing the `self` that wasn't needed.
Expose discriminant values in stable_mir

Resolves rust-lang/project-stable-mir#93
* Added `Discr` struct to stable mir as stable version of struct with same name
* Added `discriminant_for_variant`  method to `AdtDef` and `CoroutineDef`
…bzol

Configure bootstrap backport nominations through triagebot

Following the discussion in [#t-infra/bootstrap > ✔ Have triagebot create backport nomination threads?](https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/.E2.9C.94.20Have.20triagebot.20create.20backport.20nomination.20threads.3F/with/521876500) where we noticed that bootstrap backport nominations were difficult to track, since:

- We don't really have a dedicated person / group of people checking for bootstrap backport nominations.
- We don't really have an establish way of handling bootstrap backports.

This PR configures triagebot to open backport nominations threads (indicated for bootstrap team if a given PR has the suitable team label, https://github.com/rust-lang/rust/labels/T-bootstrap) in [#t-infra/bootstrap/backports](https://rust-lang.zulipchat.com/#narrow/channel/507486-t-infra.2Fbootstrap.2Fbackports). The current configuration is such that **the whole bootstrap team will be pinged for bootstrap backport nominations**[^diverges].

### Steps

- [x] ~~Ping members who opt-in subscribe to backport channel, or ping the whole bootstrap team?~~
    - Poll: [#t-infra/bootstrap > Have triagebot create backport nomination threads? @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/Have.20triagebot.20create.20backport.20nomination.20threads.3F/near/522141337)
    - Votes (as of 2025-06-10): 3 votes "no preference", 1 vote "in favor".
- [x] ~~(Best for follow-up) Maybe also document bootstrap team's backport process / decision process in Forge? It's a bit different from [compiler team's backport process](https://forge.rust-lang.org/compiler/backports.html) because we don't have weekly bootstrap triage meetings and thus don't have sync backport decisions.~~
    - Tracked as follow-up in Forge: rust-lang/rust-forge#889.

---

r? Kobzol

[^diverges]: Note that this configuration is similar to the types team backport nominations, but diverges from the compiler team.
…-suggestion, r=compiler-errors

Make E0621 missing lifetime suggestion verbose

```
error[E0621]: explicit lifetime required in the type of `x`
  --> $DIR/42701_one_named_and_one_anonymous.rs:10:9
   |
LL |         &*x
   |         ^^^ lifetime `'a` required
   |
help: add explicit lifetime `'a` to the type of `x`
   |
LL | fn foo2<'a>(a: &'a Foo, x: &'a i32) -> &'a i32 {
   |                             ++
```

Part of rust-lang#141973.
…ts, r=aDotInTheVoid

tests: Change ABIs in tests to more future-resilient ones

Eventually we're going to make these tests not work as they are currently written on HEAD, so change them now to get ahead of that.

r? aDotInTheVoid
Only run `citool` tests on the `auto` branch

Proposed here: [#t-infra > PR ci seems much to slow @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/PR.20ci.20seems.20much.20to.20slow/near/523159583). I haven't yet seen these tests failing on CI, so I think it's a good trade-off.

r? ````@marcoieni````
Implement `//@ needs-target-std` compiletest directive

Closes rust-lang#141863.
Needed to unblock rust-lang#139244 and rust-lang#141856.

### Summary

This PR implements a `//@ needs-target-std` compiletest directive that gates test execution based on whether the target supports std or not. For some cases, this should be preferred over e.g. some combination of `//@ ignore-none`, `//@ ignore-nvptx` and more[^none-limit].

### Implementation limitation

Unfortunately, since there is currently [no reliable way to determine from metadata whether a given target supports std or not](rust-lang#142296), we have to resort to a hack. Bootstrap currently determines whether or not a target supports std by a naive target tuple substring comparison: a target supports std if its target tuple does *not* contain one of `["-none", "nvptx", "switch"]` substrings. This PR simply pulls that hack out into `build_helpers` to avoid reimplementing the same hack in compiletest, and uses that logic to inform `//@ needs-target-std`.

### Auxiliary changes

This PR additionally changes a few run-make tests to use `//@ needs-target-std` over an inconsistent combination of target-based `ignore`s. This should help with rust-lang#139244.

---

r? bootstrap

[^none-limit]: Notably, `target_os = "none"` is **not** a sufficient condition for "target does not support std"
…, r=fee1-dead

Make loongarch-none target maintainers more easily pingable

In the same style as rust-lang#139028.
r? compiler
…nv-query, r=lcnr

Dont unwrap and re-wrap typing envs

Just a tiny tweak to make the query less awkward.

r? lcnr
…gjubilee

Remove unneeded `FunctionCx` from some codegen methods

No changes; just removing the `self` that wasn't needed.

r? workingjubilee
cc rust-lang#138759 (comment)
…, r=tgross35

feat: Add `bit_width` for unsigned integer types

- Accepted ACP: rust-lang/libs-team#598
- Tracking issue: rust-lang#142326

This PR adds methods to the primitive unsigned integer types that return the minimum number of bits required to represent an unsigned integer.
@rustbot rustbot added the A-compiletest Area: The compiletest test runner label Jun 11, 2025
@rustbot rustbot added A-meta Area: Issues & PRs about the rust-lang/rust repository itself A-run-make Area: port run-make Makefiles to rmake.rs A-rustc-dev-guide Area: rustc-dev-guide A-rustdoc-json Area: Rustdoc JSON backend A-testsuite Area: The testsuite used to check the correctness of rustc 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-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. rollup A PR which is a rollup labels Jun 11, 2025
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=5

@bors
Copy link
Collaborator

bors commented Jun 11, 2025

📌 Commit 26a6497 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 Jun 11, 2025
@bors
Copy link
Collaborator

bors commented Jun 11, 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-3o9gaja (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-3o9gaja --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
Auto-merging compiler/rustc_smir/src/stable_mir/ty.rs
CONFLICT (content): Merge conflict in compiler/rustc_smir/src/stable_mir/ty.rs
Auto-merging compiler/rustc_smir/src/stable_mir/compiler_interface.rs
Auto-merging compiler/rustc_smir/src/rustc_smir/context.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 11, 2025
@bors
Copy link
Collaborator

bors commented Jun 11, 2025

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

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-meta Area: Issues & PRs about the rust-lang/rust repository itself A-run-make Area: port run-make Makefiles to rmake.rs A-rustc-dev-guide Area: rustc-dev-guide A-rustdoc-json Area: Rustdoc JSON backend A-testsuite Area: The testsuite used to check the correctness of rustc 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-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.