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 8 pull requests #62253

Merged
merged 20 commits into from
Jul 1, 2019
Merged

Rollup of 8 pull requests #62253

merged 20 commits into from
Jul 1, 2019

Conversation

Centril
Copy link
Contributor

@Centril Centril commented Jun 30, 2019

Successful merges:

Failed merges:

r? @ghost

euclio and others added 20 commits June 26, 2019 21:15
Currently, dataflow begins by visiting each block in order of ID
(`BasicBlock(0)`, `BasicBlock(1)`, etc.). This PR changes that initial
iteration to reverse post-order. This ensures that the effects of all
predecessors will be applied before a basic block is visited if the CFG
has no back-edges, and should result in less total iterations even when
back-edges exist. This should not change the results of dataflow
analysis.

The current ordering for basic blocks is pretty close to RPO
already--`BasicBlock(0)` is already the start block, so the gains from
this are pretty small, especially since we need to do an extra traversal
up front.

Note that some basic blocks are unreachable from the `START_BLOCK`
during dataflow. We add these blocks to the work queue as well to
preserve the original behavior.
This applies the same basic principle as rust-lang#62062 to the reverse dataflow
analysis used to compute liveness information. It is functionally
equivalent, except that post-order is used instead of reverse post-order.

Some `mir::Body`s contain basic blocks which are not reachable from the
`START_BLOCK`. We need to add them to the work queue as well to preserve
the original semantics.
Fix a typo in `libcore/char/methods.rs`
…gisa

Use a more efficient iteration order for forward dataflow

Currently, dataflow begins by visiting each block in order of ID (`BasicBlock(0)`, `BasicBlock(1)`, etc.). This PR changes that initial iteration to reverse post-order (see [this blog post](https://eli.thegreenplace.net/2015/directed-graph-traversal-orderings-and-applications-to-data-flow-analysis/#data-flow-analysis) for more info). This ensures that the effects of all predecessors will be applied before a basic block is visited if the CFG has no back-edges, and should result in less total iterations even when back-edges exist. This should not change the results of dataflow analysis.

The current ordering for basic blocks may be pretty close to RPO already--`BasicBlock(0)` is already the start block--in which case the cost of doing the traversal up front will outweigh the efficiency gains.
A perf run is needed to check this.

r? @pnkfelix (I think).
…der, r=nagisa

Use a more efficient iteration order for backward dataflow

This applies the same basic principle as rust-lang#62062 to the reverse dataflow analysis used to compute liveness information. It is functionally equivalent, except that post-order is used instead of reverse post-order.

In the long-term, `BitDenotation` should probably be extended to support both forward and backward dataflow, but there's some more work needed to get to that point.
…omez

rustdoc: remove unused derives and variants

Though many structs in rustdoc derive `RustcEncodable` and `RustcDecodable`, the impls do not appear to be used by the crate or its dependents. Removing them revealed some enum variants that are never constructed, too.

r? @GuillaumeGomez
…tril

Extend the #[must_use] lint to boxed types

Fixes rust-lang#55506 (comment) (cc @Nemo157).

This should have been included as part of rust-lang#55663, but was overlooked.
…entril

Extend the `#[must_use]` lint to arrays

Based on top of rust-lang#62228.

r? @Centril
…kennytm

Fix a typo

The definition of 京 seems to be capital, but not capitol.
[reference](https://en.wiktionary.org/wiki/%E4%BA%AC#Etymology_1)
[another reference](https://jisho.org/word/%E4%BA%AC)
…etrochenkov

Always parse 'async unsafe fn' + properly ban in 2015

Parse `async unsafe fn` not `unsafe async fn` in implementations. We also take the opportunity to properly ban `async fn` in Rust 2015 when they are inside implementations.

Closes rust-lang#62232.

cc rust-lang#61319, rust-lang#62121, and rust-lang#62149.

r? @petrochenkov
…lacrum

before_exec actually will only get deprecated with 1.37

Not sure if we usually fix old release notes, but I just found this when scrolling over them.
@Centril
Copy link
Contributor Author

Centril commented Jun 30, 2019

@bors r+ p=8 rollup=never

@bors
Copy link
Contributor

bors commented Jun 30, 2019

📌 Commit 1abbf4b has been approved by Centril

@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 30, 2019
@bors
Copy link
Contributor

bors commented Jul 1, 2019

⌛ Testing commit 1abbf4b with merge 765eebf...

bors added a commit that referenced this pull request Jul 1, 2019
Rollup of 8 pull requests

Successful merges:

 - #62062 (Use a more efficient iteration order for forward dataflow)
 - #62063 (Use a more efficient iteration order for backward dataflow)
 - #62224 (rustdoc: remove unused derives and variants)
 - #62228 (Extend the #[must_use] lint to boxed types)
 - #62235 (Extend the `#[must_use]` lint to arrays)
 - #62239 (Fix a typo)
 - #62241 (Always parse 'async unsafe fn' + properly ban in 2015)
 - #62248 (before_exec actually will only get deprecated with 1.37)

Failed merges:

r? @ghost
@bors
Copy link
Contributor

bors commented Jul 1, 2019

☀️ Test successful - checks-azure, checks-travis, status-appveyor
Approved by: Centril
Pushing 765eebf to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jul 1, 2019
@bors bors merged commit 1abbf4b into rust-lang:master Jul 1, 2019
@Centril Centril deleted the rollup-115uuuq branch July 1, 2019 13:35
@Centril Centril added the rollup A PR which is a rollup label Oct 2, 2019
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.

6 participants