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

Update Arc docs to match new Rc docs #36665

Merged
merged 2 commits into from
Oct 7, 2016
Merged

Conversation

kmcallister
Copy link
Contributor

Rc docs were updated in #36571. This applies similar changes to Arc docs.

r? @GuillaumeGomez

///
// See comment at the top of this file for why the test is no_run
// Note that we **do not** run these tests here. The windows builders get super
// unhappy of a thread outlives the main thread and then exits at the same time
Copy link
Member

Choose a reason for hiding this comment

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

s/of/if/

Copy link
Member

Choose a reason for hiding this comment

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

This still needs to be addressed.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed.

//!
//! `Weak<T>` is a weak reference to the `Arc<T>` box, and it is created by
Copy link
Member

@GuillaumeGomez GuillaumeGomez Sep 23, 2016

Choose a reason for hiding this comment

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

Why removing these lines? We generally have an example at the module level as well. I don't mind changing it but I don't like it to get completely removed.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It seems redundant. Isn't a link to the Arc docs good enough? Besides, the module-level docs are only visible if you're looking at the alloc crate directly and not std.

@GuillaumeGomez
Copy link
Member

Before r+, what do you think of this @steveklabnik?

//!
//! `Weak<T>` is a weak reference to the `Arc<T>` box, and it is created by
Copy link
Member

Choose a reason for hiding this comment

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

So, it's true that duplication isn't great. Usually, module-level docs should have an overview of the whole module, but with modules like these, it's just a container for Arc/Weak, and nothing else. As such, I think I'm fine with removing this in this instance. Especially given the alloc/std split as you mentioned.

Copy link
Member

@steveklabnik steveklabnik left a comment

Choose a reason for hiding this comment

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

Thanks so much for this! This PR is great, but I have a few nits.

///
// See comment at the top of this file for why the test is no_run
// Note that we **do not** run these tests here. The windows builders get super
// unhappy of a thread outlives the main thread and then exits at the same time
Copy link
Member

Choose a reason for hiding this comment

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

This still needs to be addressed.

@@ -1,4 +1,4 @@
// Copyright 2012-2014 The Rust Project Developers. See the COPYRIGHT
// Copyright 2012-2016 The Rust Project Developers. See the COPYRIGHT
Copy link
Member

Choose a reason for hiding this comment

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

uuuuuuuuuuuugh these headings.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah... do you want me to leave it alone?

Copy link
Member

Choose a reason for hiding this comment

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

/// does not use atomics, making it both thread-unsafe as well as significantly
/// faster when updating the reference count.
/// The type `Arc<T>` provides shared ownership of a value of type `T`,
/// allocated in the heap. Invoking [`clone`][clone] on `Arc` produces
Copy link
Member

Choose a reason for hiding this comment

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

these links can be changed to drop the [clone]...

Copy link
Contributor Author

@kmcallister kmcallister Sep 27, 2016

Choose a reason for hiding this comment

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

Is that so? I would have to change the link at the bottom to include the backticks, right? And that bugs me personally, although I agree it doesn't really matter.

/// [arc]: struct.Arc.html
/// [weak]: struct.Weak.html
/// [rc]: ../../std/rc/struct.Rc.html
/// [clone]: ../../std/clone/trait.Clone.html#tymethod.clone
Copy link
Member

Choose a reason for hiding this comment

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

.. and then put

[`clone`]

here.

/// instead of `value.get_mut()`. This is so that there are no conflicts with
/// methods on the inner type `T`, which are what you want to call in the
/// majority of cases.
/// Shared pointers in Rust disallow mutation by default, and `Arc` is no
Copy link
Member

Choose a reason for hiding this comment

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

"references" is the proper term.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed.

///
/// ```
/// use std::sync::Arc;
/// use std::thread;
/// # use std::sync::Arc;
Copy link
Member

Choose a reason for hiding this comment

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

I'm a bit torn here. Showing the imports is a bit better, I think: it's less confusing for newer users, and makes it copy/paste able.

Copy link
Member

Choose a reason for hiding this comment

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

I agree.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed.

@kmcallister
Copy link
Contributor Author

I updated the PR. Let me know what you think, and if it's good, I will squash the Arc changes.

@bors
Copy link
Contributor

bors commented Sep 29, 2016

☔ The latest upstream changes (presumably #36818) made this pull request unmergeable. Please resolve the merge conflicts.

@kmcallister
Copy link
Contributor Author

Rebased, and added one more link in Rc docs.

@steveklabnik steveklabnik self-assigned this Oct 4, 2016
@steveklabnik
Copy link
Member

@bors: r+ rollup

Thanks for your patience here @kmcallister

@bors
Copy link
Contributor

bors commented Oct 6, 2016

📌 Commit 29d3e57 has been approved by steveklabnik

@kmcallister
Copy link
Contributor Author

Thanks @steveklabnik! A lot of the delay was on my side, anyway.

GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this pull request Oct 7, 2016
Update Arc docs to match new Rc docs

`Rc` docs were updated in rust-lang#36571. This applies similar changes to `Arc` docs.

r? @GuillaumeGomez
bors added a commit that referenced this pull request Oct 7, 2016
Rollup of 5 pull requests

- Successful merges: #36222, #36665, #36929, #37003, #37008
- Failed merges:
@bors bors merged commit 29d3e57 into rust-lang:master Oct 7, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants