Skip to content

Rc: value -> allocation - #65505

Merged
bors merged 5 commits into
rust-lang:masterfrom
RalfJung:rc
Oct 19, 2019
Merged

Rc: value -> allocation#65505
bors merged 5 commits into
rust-lang:masterfrom
RalfJung:rc

Conversation

@RalfJung

Copy link
Copy Markdown
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-highfiverust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 17, 2019

@CentrilCentril left a comment

Copy link
Copy Markdown
Contributor

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!

Comment threadsrc/liballoc/rc.rs
Comment threadsrc/liballoc/rc.rs
@Centril

Copy link
Copy Markdown
Contributor

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
Copy Markdown
MemberAuthor

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...

Comment threadsrc/liballoc/rc.rs
/// 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
Copy Markdown
MemberAuthor

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
Copy Markdown
Contributor

Thanks! @bors r+ rollup

@bors

bors commented Oct 19, 2019

Copy link
Copy Markdown
Collaborator

📌 Commit 1b38463 has been approved by Centril

@borsbors 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
@CentrilCentril mentioned this pull request 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
@CentrilCentril mentioned this pull request Oct 19, 2019
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:masterOct 19, 2019
@RalfJung
RalfJung deleted the rc branch October 20, 2019 09:33
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-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.

4 participants

@RalfJung@Centril@bors@rust-highfive