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 12 pull requests #78334

Merged
merged 57 commits into from
Oct 25, 2020
Merged

Rollup of 12 pull requests #78334

merged 57 commits into from
Oct 25, 2020

Conversation

jonas-schievink
Copy link
Contributor

Successful merges:

Failed merges:

r? @ghost

stlankes and others added 30 commits October 11, 2020 11:53
#77147 simplifies things by splitting this Mutex type
into two types matching the two use cases: StaticMutex and MovableMutex.
To support the behavior of StaticMutex, we move part of the mutex
implementation into libstd.
the commit avoid an alignement issue in Mutex implementation
This deconfuses the comparison of floats, that currently mixed ranges
and non-ranges.
This makes it consistent with std::panic!("message"), which also throws
a &str, not a String.
It now throws a &str instead of a String.
…tion

The optimization introduces additional uses of the discriminant operand, but
does not ensure that it is still valid to evaluate it or that it still
evaluates to the same value.

Evaluate it once at original position, and store the result in a new temporary.
This issue was accidentally fixed recently, probably by #70743
const_evaluatable_checked: deal with unused nodes + div

r? @oli-obk
TyCtxt: generate single impl block with `slice_interners` macro

Reduces the work needed to check overlapping impls a bit.
resolve: Relax macro resolution consistency check to account for any errors

The check was previously omitted only when ambiguity errors or `Res::Err` were encountered, but the "macro-expanded `extern crate` items cannot shadow..." error (at least) can cause same inconsistencies as well.

Fixes #78325
@jonas-schievink
Copy link
Contributor Author

@bors r+ rollup=never p=12

@rustbot modify labels: rollup

@bors
Copy link
Contributor

bors commented Oct 24, 2020

📌 Commit 58ae889 has been approved by jonas-schievink

@rustbot rustbot added the rollup A PR which is a rollup label Oct 24, 2020
@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 Oct 24, 2020
@bors
Copy link
Contributor

bors commented Oct 24, 2020

⌛ Testing commit 58ae889 with merge f58ffc9...

@bors
Copy link
Contributor

bors commented Oct 25, 2020

☀️ Test successful - checks-actions
Approved by: jonas-schievink
Pushing f58ffc9 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Oct 25, 2020
@bors bors merged commit f58ffc9 into rust-lang:master Oct 25, 2020
@rustbot rustbot added this to the 1.49.0 milestone Oct 25, 2020
@rust-highfive
Copy link
Collaborator

📣 Toolstate changed by #78334!

Tested on commit f58ffc9.
Direct link to PR: #78334

💔 miri on windows: test-pass → test-fail (cc @oli-obk @eddyb @RalfJung).
💔 miri on linux: test-pass → test-fail (cc @oli-obk @eddyb @RalfJung).
💔 rls on windows: test-pass → build-fail (cc @Xanewok).
💔 rls on linux: test-pass → build-fail (cc @Xanewok).
💔 rustfmt on windows: test-pass → build-fail (cc @topecongiro @calebcartwright).
💔 rustfmt on linux: test-pass → build-fail (cc @topecongiro @calebcartwright).

rust-highfive added a commit to rust-lang-nursery/rust-toolstate that referenced this pull request Oct 25, 2020
Tested on commit rust-lang/rust@f58ffc9.
Direct link to PR: <rust-lang/rust#78334>

💔 miri on windows: test-pass → test-fail (cc @oli-obk @eddyb @RalfJung).
💔 miri on linux: test-pass → test-fail (cc @oli-obk @eddyb @RalfJung).
💔 rls on windows: test-pass → build-fail (cc @Xanewok).
💔 rls on linux: test-pass → build-fail (cc @Xanewok).
💔 rustfmt on windows: test-pass → build-fail (cc @topecongiro @calebcartwright).
💔 rustfmt on linux: test-pass → build-fail (cc @topecongiro @calebcartwright).
@Mark-Simulacrum
Copy link
Member

This had some effect on compiler performance; I'm not sure which PRs were responsible. I suspect #78072 and #78191.

cc @Nadrieril @tmiasko -- do those perf results look like they could be because of those PRs? I think a good next step is probably to post reverts of each so that we can see if they were the cause.

@jonas-schievink
Copy link
Contributor Author

I think #78191 only touches a disabled optimization

@Nadrieril
Copy link
Member

@Mark-Simulacrum Ah yeah that very much looks like the effect of changes to match checking. My PR was based on #77390 which was a perf improvement so I didn't think to check.

@Nadrieril
Copy link
Member

I have a followup PR (#78430) which I measured to be a large perf improvement, and would compensate the regression from #78072. If that's not enough I can bisect #78072, but that's more work

@Mark-Simulacrum
Copy link
Member

Yeah, no worries, that sounds fine. Just wanted to make sure we had a clear idea of the cause. I don't think the regression(s) are bad enough to warrant doing more work here, especially as you have followup improvements that outweigh them.

@jonas-schievink jonas-schievink deleted the rollup-z0gzbmm branch October 27, 2020 21:23
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. rollup A PR which is a rollup 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.