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

Merged
merged 19 commits into from
Jun 7, 2020
Merged

Rollup of 5 pull requests #73081

merged 19 commits into from
Jun 7, 2020

Conversation

Dylan-DPC-zz
Copy link

Successful merges:

Failed merges:

r? @ghost

RalfJung and others added 19 commits May 31, 2020 10:50
We were computing a merge-base between the remote beta and master
branches, but this was giving incorrect answers for the first beta if
the remote hadn't been pushed yet. For instance, `1.45.0-beta.3359`
corresponds to the number of merges since the 1.44 beta, but we really
want just `.1` for the sole 1.45 beta promotion merge.

We don't really need to query the remote beta at all -- `master..HEAD`
suffices if we assume that we're on the intended beta branch already.
…nas-schievink

validate basic sanity for TerminatorKind

r? @jonas-schievink

This mainly checks that all `BasicBlock` actually exist. On top of that, it checks that `Call` actually calls something of `FnPtr`/`FnDef` type, and `Assert` has to work on a `bool`. Also `SwitchInt` cannot have an empty target list.
…jasper

Revert pr 71840

Revert7 PR rust-lang#71840 to fix issue rust-lang#72470

This will need a backport to beta if we do not want rust-lang#72470 to hit stable.
Count the beta prerelease number just from master

We were computing a merge-base between the remote beta and master
branches, but this was giving incorrect answers for the first beta if
the remote hadn't been pushed yet. For instance, `1.45.0-beta.3359`
corresponds to the number of merges since the 1.44 beta, but we really
want just `.1` for the sole 1.45 beta promotion merge.

We don't really need to query the remote beta at all -- `master..HEAD`
suffices if we assume that we're on the intended beta branch already.
@Dylan-DPC-zz
Copy link
Author

@bors r+ rollup=never p=5

@bors
Copy link
Contributor

bors commented Jun 7, 2020

📌 Commit b117a39 has been approved by Dylan-DPC

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Jun 7, 2020
@bors
Copy link
Contributor

bors commented Jun 7, 2020

⌛ Testing commit b117a39 with merge 450abe8...

@bors
Copy link
Contributor

bors commented Jun 7, 2020

☀️ Test successful - checks-azure
Approved by: Dylan-DPC
Pushing 450abe8 to master...

@nnethercote
Copy link
Contributor

This was a small perf loss. Ignore the script-servo-opt change, that one bounces around like crazy. There were some small improvements, but more losses.

@pnkfelix, @RalfJung: your PRs seem the mostly likely causes. Any ideas?

@Dylan-DPC-zz Dylan-DPC-zz deleted the rollup-1aqk215 branch June 9, 2020 00:12
@Dylan-DPC-zz
Copy link
Author

would recommend branching off to a new issue - makes it easier to track than on a merged pr

@RalfJung
Copy link
Member

RalfJung commented Jun 9, 2020

@nnethercote I measured perf impact of MIR validation in #73087, and it came out with "basically no impact". That measurement includes this PR. So I think it's not my PR -- but I might misinterpret.

@pnkfelix
Copy link
Member

I can believe that my revert (PR #72989) of the drop tree reworking (PR #71840) caused regressions.

But that injected bugs, so we have to live with the revert for the short term at least.

@cuviper cuviper added this to the 1.46 milestone May 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants