-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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 7 pull requests #106319
Rollup of 7 pull requests #106319
Conversation
Monomorphise `#[repr(transparent)]` parameterized ADTs before turning them into an Itanium mangled String. `#[repr(transparent)]` ADTs currently use the single field to represent them in their CFI type ID to ensure that they are compatible. However, if that type involves a type parameter instantiated at the ADT level, as in `ManuallyDrop`, this will currently ICE as the `Parameter` type cannot be mangled. Since this happens at lowering time, it should always be concrete after substitution. Fixes rust-lang#106230
Previously, clean only supported `--stage 0` for specific crates. The new `crate_description` function generates a string that looks like ``` : {rustc_query_impl} ```
Before: ``` Testing ["rustc_interface"] stage0 (aarch64-unknown-linux-gnu -> aarch64-unknown-linux-gnu) ``` After: ``` Testing {rustc_interface} stage0 (aarch64-unknown-linux-gnu -> aarch64-unknown-linux-gnu) ``` Note there is a slight consistency between `build` and `test`: The former doesn't print "compiler artifacts". It would be annoying to fix and doesn't hurt anything, so I left it be. ``` ; x t rustc_interface --stage 0 --dry-run Testing {rustc_interface} stage0 (aarch64-unknown-linux-gnu -> aarch64-unknown-linux-gnu) ; x b rustc_interface --stage 0 --dry-run Building {rustc_interface} stage0 compiler artifacts (aarch64-unknown-linux-gnu -> aarch64-unknown-linux-gnu) ```
This makes it easier to see them (and makes people go owo).
CFI: Monomorphize transparent ADTs before typeid Monomorphise `#[repr(transparent)]` parameterized ADTs before turning them into an Itanium mangled String. `#[repr(transparent)]` ADTs currently use the single field to represent them in their CFI type ID to ensure that they are compatible. However, if that type involves a type parameter instantiated at the ADT level, as in `ManuallyDrop`, this will currently ICE as the `Parameter` type cannot be mangled. Since this happens at lowering time, it should always be concrete after substitution. Fixes rust-lang#106230
Merge multiple mutable borrows of immutable binding errors Fix rust-lang#53466.
Make tidy errors red This makes it easier to see them (and makes people go owo). I also changes the error codes check to not print too many things and use `tidy_error`. r? ``@jyn514``
…ples-layout-test, r=notriddle Extend scraped examples layout GUI test for position of buttons This is a regression test for rust-lang#106279. r? ```@notriddle```
bootstrap: Get rid of tail_args in stream_cargo Based on rust-lang#106303 for convenience. r? ```@Mark-Simulacrum```
Dont use `--merge-base` during bootstrap formatting subcommand I use a development image with Ubuntu 20.04 LTS, which has git 2.25. Recently, `./x.py test tidy --bless` regressed in rust-lang#105702 because it uses the `--merge-base` option on `diff-index`, which was only introduced in git 2.30 (git/git@0f5a1d4). Luckily, it can be replicated via two calls to `git merge-base` + `git diff-index`, so let's just use that.
Fix panic on `x build --help` Fixes rust-lang#106313. This avoids trying to run `get_help` unless we actually need to see the paths that are available for the subcommand. This originally regressed in rust-lang#106166.
⌛ Testing commit b58e611 with merge 6d71e52e2ff3e0031141e63f8c0a161b28fcc075... |
💔 Test failed - checks-actions |
err hmm, that error looks like 4839886, not anything in this PR 🤔
|
@bors r+ |
💡 This pull request was already approved, no need to approve it again.
|
🌲 The tree is currently closed for pull requests below priority 500. This pull request will be tested once the tree is reopened. |
The job Click to see the possible cause of the failure (guessed by this bot)
|
@bors treeclosed- |
⌛ Testing commit b58e611 with merge 5e5ef50482e13f2ef4bf67b24e22e6a0f95d3a82... |
💔 Test failed - checks-actions |
The job Click to see the possible cause of the failure (guessed by this bot)
|
The job Click to see the possible cause of the failure (guessed by this bot)
|
☔ The latest upstream changes (presumably #106245) made this pull request unmergeable. Please resolve the merge conflicts. |
Enable triagebot no-merges check Follow-up on rust-lang/triagebot#1704 ### Motivation Occasionally, a merge commit like rust-lang@cb5c011 makes it past manual review and gets merged into master. At one point, we tried adding a check to CI to prevent this from happening (rust-lang#105058), but that ended up [problematic](rust-lang#106319 (comment)) and was [reverted](rust-lang#106320). This kind of check is simply too fragile for CI, and there must be a way for a human to override the bot's decision. The capability to detect and warn about merge commits has been present in triagebot for quite some time, but was never enabled at rust-lang/rust, possibly due to concerns about false positives on rollup and subtree sync PRs. This PR intends to alleviate those concerns. ### Configuration This configuration will exclude rollup PRs and subtree sync PRs from merge commit detection, and it will post the default warning message and add the `has-merge-commits` and `S-waiting-on-author` labels when merge commits are detected on other PRs. The eventual vision is to have bors refuse to merge if the `has-merge-commits` label is present. A reviewer can still force the merge by removing that label if they so wish. ### Note for contributors The rollup tool should add that label automatically, but anyone performing subtree updates should begin including "subtree update" in the titles of those PRs, to avoid false positives. r? infra ## Open Questions 1. This configuration uses the default message that's built into triagebot: > There are merge commits (commits with multiple parents) in your changes. We have a [no merge policy](https://rustc-dev-guide.rust-lang.org/git.html#no-merge-policy) so these commits will need to be removed for this pull request to be merged. > > You can start a rebase with the following commands: > ```shell-session > $ # rebase > $ git rebase -i master > $ # delete any merge commits in the editor that appears > $ git push --force-with-lease > ``` Any changes to this are easy, I'll just have to add a `message` option. Should we mention the excluded titles in the message?
Rollup merge of rust-lang#114157 - pitaj:triagebot_no-merges, r=ehuss Enable triagebot no-merges check Follow-up on rust-lang/triagebot#1704 ### Motivation Occasionally, a merge commit like rust-lang@cb5c011 makes it past manual review and gets merged into master. At one point, we tried adding a check to CI to prevent this from happening (rust-lang#105058), but that ended up [problematic](rust-lang#106319 (comment)) and was [reverted](rust-lang#106320). This kind of check is simply too fragile for CI, and there must be a way for a human to override the bot's decision. The capability to detect and warn about merge commits has been present in triagebot for quite some time, but was never enabled at rust-lang/rust, possibly due to concerns about false positives on rollup and subtree sync PRs. This PR intends to alleviate those concerns. ### Configuration This configuration will exclude rollup PRs and subtree sync PRs from merge commit detection, and it will post the default warning message and add the `has-merge-commits` and `S-waiting-on-author` labels when merge commits are detected on other PRs. The eventual vision is to have bors refuse to merge if the `has-merge-commits` label is present. A reviewer can still force the merge by removing that label if they so wish. ### Note for contributors The rollup tool should add that label automatically, but anyone performing subtree updates should begin including "subtree update" in the titles of those PRs, to avoid false positives. r? infra ## Open Questions 1. This configuration uses the default message that's built into triagebot: > There are merge commits (commits with multiple parents) in your changes. We have a [no merge policy](https://rustc-dev-guide.rust-lang.org/git.html#no-merge-policy) so these commits will need to be removed for this pull request to be merged. > > You can start a rebase with the following commands: > ```shell-session > $ # rebase > $ git rebase -i master > $ # delete any merge commits in the editor that appears > $ git push --force-with-lease > ``` Any changes to this are easy, I'll just have to add a `message` option. Should we mention the excluded titles in the message?
Successful merges:
--merge-base
during bootstrap formatting subcommand #106310 (Dont use--merge-base
during bootstrap formatting subcommand)x build --help
#106314 (Fix panic onx build --help
)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup