Skip to content

Conversation

RalfJung
Copy link
Member

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

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 17, 2019
Copy link
Contributor

@Centril Centril left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like a great improvement!

@Centril
Copy link
Contributor

Centril commented Oct 17, 2019

This does not yet edit Arc as I first wanted to be sure we agree on the terminology the way it actually ends up.

We do agree. :)

@RalfJung
Copy link
Member Author

I did a few more edits on Rc; please check 52a31f7.

And then I did all the same things with Arc. At least I hope it is consistent...

@@ -1172,6 +1177,8 @@ impl<T: ?Sized + PartialEq> RcEqIdent<T> for Rc<T> {
/// store large values, that are slow to clone, but also heavy to check for equality, causing this
/// cost to pay off more easily. It's also more likely to have two `Rc` clones, that point to
/// the same value, than two `&T`s.
///
/// We can only do this when `T: Eq` as a `PartialEq` might be deliberately irreflexive.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is what I concluded after some thinking. It is also in line with this comment by @alexcrichton:

According to Eq's own documentation it signifies the reflexive property (a == a) which I believe means that this is a semantically correct implementation.

So, seems like just a missing comment to me.

@Centril
Copy link
Contributor

Centril commented Oct 19, 2019

Thanks! @bors r+ rollup

@bors
Copy link
Collaborator

bors commented Oct 19, 2019

📌 Commit 1b38463 has been approved by Centril

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 19, 2019
Centril added a commit to Centril/rust that referenced this pull request Oct 19, 2019
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 added a commit to Centril/rust that referenced this pull request Oct 19, 2019
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
bors added a commit that referenced this pull request Oct 19, 2019
Rollup of 5 pull requests

Successful merges:

 - #64007 (Add check for overlapping ranges to unreachable patterns lint)
 - #65192 (Use structured suggestion for restricting bounds)
 - #65226 (BTreeSet symmetric_difference & union optimized)
 - #65448 (rustc_codegen_ssa: remove some unnecessary Box special-casing.)
 - #65505 (Rc: value -> allocation)

Failed merges:

r? @ghost
@bors bors merged commit 1b38463 into rust-lang:master Oct 19, 2019
@RalfJung RalfJung deleted the rc branch October 20, 2019 09:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
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.

4 participants