Skip to content

Rollup of 4 pull requests - #65596

Closed
Centril wants to merge 27 commits into
rust-lang:masterfrom
Centril:rollup-xnfvaw6
Closed

Rollup of 4 pull requests#65596
Centril wants to merge 27 commits into
rust-lang:masterfrom
Centril:rollup-xnfvaw6

Conversation

@Centril

Copy link
Copy Markdown
Contributor

Successful merges:

Failed merges:

r? @ghost

estebankand others added 27 commits October 15, 2019 13:55
When a trait bound is not met and restricting a type parameter would
make the restriction hold, use a structured suggestion pointing at an
appropriate place (type param in param list or `where` clause).
Account for opaque parameters where instead of suggesting extending
the `where` clause, we suggest appending the new restriction:
`fn foo(impl Trait + UnmetTrait)`.
…asper
Use structured suggestion for restricting bounds
When a trait bound is not met and restricting a type parameter would
make the restriction hold, use a structured suggestion pointing at an
appropriate place (type param in param list or `where` clause).
Account for opaque parameters where instead of suggesting extending
the `where` clause, we suggest appending the new restriction:
`fn foo(impl Trait + UnmetTrait)`. Fixrust-lang#64565, fixrust-lang#41817, fixrust-lang#24354,
cc rust-lang#26026, cc rust-lang#37808, cc rust-lang#24159, fixrust-lang#37138, fixrust-lang#24354, cc rust-lang#20671.
BTreeSet symmetric_difference & union optimized
No scalability changes, but:
- Grew the cmp_opt function (shared by symmetric_difference & union) into a MergeIter, with less memory overhead than the pairs of Peekable iterators now, speeding up ~20% on my machine (not so clear on Travis though, I actually switched it off there because it wasn't consistent about identical code). Mainly meant to improve readability by sharing code, though it does end up using more lines of code. Extending and reusing the MergeIter in btree_map might be better, but I'm not sure that's possible or desirable. This MergeIter probably pretends to be more generic than it is, yet doesn't declare to be an iterator because there's no need to, it's only there to help construct genuine iterators SymmetricDifference & Union.
- Compact the code of rust-lang#64820 by moving if/else into match guards.
r? @bluss
Rc: value -> allocation
See rust-lang#64484. This does not yet edit `Arc` as I first wanted to be sure we agree on the terminology the way it actually ends up. "value" as a term appears a lot in this file, and sometimes it refers to the value stored inside the `RcBox` while sometimes it refers to the `RcBox` itself. I tried to properly tease these apart but may have made some mistakes. The former should now always be called "inner value" and the latter "allocation".
One area where I was very unsure of which terminology is dropping: the `value` field of the `RcBox` will get dropped *earlier* than the `RcBox` itself if there are weak references. I decided that "dropping the value stored in the allocation" refers to dropping the value field, while "destroying the allocation" refers to actually freeing its backing memory.
r? @Centril
@Centril

Copy link
Copy Markdown
ContributorAuthor

@bors r+ rollup=never

@bors

bors commented Oct 19, 2019

Copy link
Copy Markdown
Collaborator

📌 Commit a9d40b4 has been approved by Centril

@borsbors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Oct 19, 2019
@CentrilCentril closed this Oct 19, 2019
@Centril
Centril deleted the rollup-xnfvaw6 branch October 19, 2019 14:01
@CentrilCentril added the rollup A PR which is a rollup label Oct 24, 2019
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

rollupA PR which is a rollupS-waiting-on-borsStatus: 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.

5 participants

@Centril@bors@estebank@RalfJung@ssomers