|
12 | 12 |
|
13 | 13 | //! Single-threaded reference-counting pointers.
|
14 | 14 | //!
|
15 |
| -//! The type [`Rc<T>`][rc] provides shared ownership of a value of type `T`, |
16 |
| -//! allocated in the heap. Invoking [`clone`][clone] on `Rc` produces a new |
17 |
| -//! pointer to the same value in the heap. When the last `Rc` pointer to a |
| 15 | +//! The type [`Rc<T>`][`Rc`] provides shared ownership of a value of type `T`, |
| 16 | +//! allocated in the heap. Invoking [`clone()`][clone] on [`Rc`] produces a new |
| 17 | +//! pointer to the same value in the heap. When the last [`Rc`] pointer to a |
18 | 18 | //! given value is destroyed, the pointed-to value is also destroyed.
|
19 | 19 | //!
|
20 | 20 | //! Shared references in Rust disallow mutation by default, and `Rc` is no
|
21 |
| -//! exception. If you need to mutate through an `Rc`, use [`Cell`][cell] or |
22 |
| -//! [`RefCell`][refcell]. |
| 21 | +//! exception. If you need to mutate through an [`Rc`], use [`Cell`] or |
| 22 | +//! [`RefCell`]. |
23 | 23 | //!
|
24 |
| -//! `Rc` uses non-atomic reference counting. This means that overhead is very |
25 |
| -//! low, but an `Rc` cannot be sent between threads, and consequently `Rc` |
| 24 | +//! [`Rc`] uses non-atomic reference counting. This means that overhead is very |
| 25 | +//! low, but an [`Rc`] cannot be sent between threads, and consequently [`Rc`] |
26 | 26 | //! does not implement [`Send`][send]. As a result, the Rust compiler
|
27 |
| -//! will check *at compile time* that you are not sending `Rc`s between |
| 27 | +//! will check *at compile time* that you are not sending [`Rc`]s between |
28 | 28 | //! threads. If you need multi-threaded, atomic reference counting, use
|
29 | 29 | //! [`sync::Arc`][arc].
|
30 | 30 | //!
|
31 |
| -//! The [`downgrade`][downgrade] method can be used to create a non-owning |
32 |
| -//! [`Weak`][weak] pointer. A `Weak` pointer can be [`upgrade`][upgrade]d |
33 |
| -//! to an `Rc`, but this will return [`None`][option] if the value has |
| 31 | +//! The [`downgrade()`][downgrade] method can be used to create a non-owning |
| 32 | +//! [`Weak`] pointer. A [`Weak`] pointer can be [`upgrade`][upgrade]d |
| 33 | +//! to an [`Rc`], but this will return [`None`] if the value has |
34 | 34 | //! already been dropped.
|
35 | 35 | //!
|
36 |
| -//! A cycle between `Rc` pointers will never be deallocated. For this reason, |
37 |
| -//! `Weak` is used to break cycles. For example, a tree could have strong |
38 |
| -//! `Rc` pointers from parent nodes to children, and `Weak` pointers from |
| 36 | +//! A cycle between [`Rc`] pointers will never be deallocated. For this reason, |
| 37 | +//! [`Weak`] is used to break cycles. For example, a tree could have strong |
| 38 | +//! [`Rc`] pointers from parent nodes to children, and [`Weak`] pointers from |
39 | 39 | //! children back to their parents.
|
40 | 40 | //!
|
41 |
| -//! `Rc<T>` automatically dereferences to `T` (via the [`Deref`][deref] trait), |
42 |
| -//! so you can call `T`'s methods on a value of type `Rc<T>`. To avoid name |
43 |
| -//! clashes with `T`'s methods, the methods of `Rc<T>` itself are [associated |
| 41 | +//! `Rc<T>` automatically dereferences to `T` (via the [`Deref`] trait), |
| 42 | +//! so you can call `T`'s methods on a value of type [`Rc<T>`][`Rc`]. To avoid name |
| 43 | +//! clashes with `T`'s methods, the methods of [`Rc<T>`][`Rc`] itself are [associated |
44 | 44 | //! functions][assoc], called using function-like syntax:
|
45 | 45 | //!
|
46 | 46 | //! ```
|
|
50 | 50 | //! Rc::downgrade(&my_rc);
|
51 | 51 | //! ```
|
52 | 52 | //!
|
53 |
| -//! `Weak<T>` does not auto-dereference to `T`, because the value may have |
| 53 | +//! [`Weak<T>`][`Weak`] does not auto-dereference to `T`, because the value may have |
54 | 54 | //! already been destroyed.
|
55 | 55 | //!
|
56 |
| -//! [rc]: struct.Rc.html |
57 |
| -//! [weak]: struct.Weak.html |
58 |
| -//! [clone]: ../../std/clone/trait.Clone.html#tymethod.clone |
59 |
| -//! [cell]: ../../std/cell/struct.Cell.html |
60 |
| -//! [refcell]: ../../std/cell/struct.RefCell.html |
61 |
| -//! [send]: ../../std/marker/trait.Send.html |
62 |
| -//! [arc]: ../../std/sync/struct.Arc.html |
63 |
| -//! [deref]: ../../std/ops/trait.Deref.html |
64 |
| -//! [downgrade]: struct.Rc.html#method.downgrade |
65 |
| -//! [upgrade]: struct.Weak.html#method.upgrade |
66 |
| -//! [option]: ../../std/option/enum.Option.html |
67 |
| -//! [assoc]: ../../book/method-syntax.html#associated-functions |
68 |
| -//! |
69 | 56 | //! # Examples
|
70 | 57 | //!
|
71 | 58 | //! Consider a scenario where a set of `Gadget`s are owned by a given `Owner`.
|
72 | 59 | //! We want to have our `Gadget`s point to their `Owner`. We can't do this with
|
73 | 60 | //! unique ownership, because more than one gadget may belong to the same
|
74 |
| -//! `Owner`. `Rc` allows us to share an `Owner` between multiple `Gadget`s, |
| 61 | +//! `Owner`. [`Rc`] allows us to share an `Owner` between multiple `Gadget`s, |
75 | 62 | //! and have the `Owner` remain allocated as long as any `Gadget` points at it.
|
76 | 63 | //!
|
77 | 64 | //! ```
|
|
127 | 114 | //! ```
|
128 | 115 | //!
|
129 | 116 | //! If our requirements change, and we also need to be able to traverse from
|
130 |
| -//! `Owner` to `Gadget`, we will run into problems. An `Rc` pointer from `Owner` |
| 117 | +//! `Owner` to `Gadget`, we will run into problems. An [`Rc`] pointer from `Owner` |
131 | 118 | //! to `Gadget` introduces a cycle between the values. This means that their
|
132 | 119 | //! reference counts can never reach 0, and the values will remain allocated
|
133 |
| -//! forever: a memory leak. In order to get around this, we can use `Weak` |
| 120 | +//! forever: a memory leak. In order to get around this, we can use [`Weak`] |
134 | 121 | //! pointers.
|
135 | 122 | //!
|
136 | 123 | //! Rust actually makes it somewhat difficult to produce this loop in the first
|
137 | 124 | //! place. In order to end up with two values that point at each other, one of
|
138 |
| -//! them needs to be mutable. This is difficult because `Rc` enforces |
| 125 | +//! them needs to be mutable. This is difficult because [`Rc`] enforces |
139 | 126 | //! memory safety by only giving out shared references to the value it wraps,
|
140 | 127 | //! and these don't allow direct mutation. We need to wrap the part of the
|
141 |
| -//! value we wish to mutate in a [`RefCell`][refcell], which provides *interior |
| 128 | +//! value we wish to mutate in a [`RefCell`], which provides *interior |
142 | 129 | //! mutability*: a method to achieve mutability through a shared reference.
|
143 |
| -//! `RefCell` enforces Rust's borrowing rules at runtime. |
| 130 | +//! [`RefCell`] enforces Rust's borrowing rules at runtime. |
144 | 131 | //!
|
145 | 132 | //! ```
|
146 | 133 | //! use std::rc::Rc;
|
|
214 | 201 | //! // Gadget Man, so he gets destroyed as well.
|
215 | 202 | //! }
|
216 | 203 | //! ```
|
| 204 | +//! |
| 205 | +//! [`Rc`]: struct.Rc.html |
| 206 | +//! [`Weak`]: struct.Weak.html |
| 207 | +//! [clone]: ../../std/clone/trait.Clone.html#tymethod.clone |
| 208 | +//! [`Cell`]: ../../std/cell/struct.Cell.html |
| 209 | +//! [`RefCell`]: ../../std/cell/struct.RefCell.html |
| 210 | +//! [send]: ../../std/marker/trait.Send.html |
| 211 | +//! [arc]: ../../std/sync/struct.Arc.html |
| 212 | +//! [`Deref`]: ../../std/ops/trait.Deref.html |
| 213 | +//! [downgrade]: struct.Rc.html#method.downgrade |
| 214 | +//! [upgrade]: struct.Weak.html#method.upgrade |
| 215 | +//! [`None`]: ../../std/option/enum.Option.html#variant.None |
| 216 | +//! [assoc]: ../../book/method-syntax.html#associated-functions |
217 | 217 |
|
218 | 218 | #![stable(feature = "rust1", since = "1.0.0")]
|
219 | 219 |
|
@@ -251,9 +251,11 @@ struct RcBox<T: ?Sized> {
|
251 | 251 | /// See the [module-level documentation](./index.html) for more details.
|
252 | 252 | ///
|
253 | 253 | /// The inherent methods of `Rc` are all associated functions, which means
|
254 |
| -/// that you have to call them as e.g. `Rc::get_mut(&value)` instead of |
255 |
| -/// `value.get_mut()`. This avoids conflicts with methods of the inner |
| 254 | +/// that you have to call them as e.g. [`Rc::get_mut(&value)`][get_mut] instead of |
| 255 | +/// `value.get_mut()`. This avoids conflicts with methods of the inner |
256 | 256 | /// type `T`.
|
| 257 | +/// |
| 258 | +/// [get_mut]: #method.get_mut |
257 | 259 | #[stable(feature = "rust1", since = "1.0.0")]
|
258 | 260 | pub struct Rc<T: ?Sized> {
|
259 | 261 | ptr: Shared<RcBox<T>>,
|
@@ -337,10 +339,10 @@ impl<T> Rc<T> {
|
337 | 339 | }
|
338 | 340 |
|
339 | 341 | /// Checks whether [`Rc::try_unwrap`][try_unwrap] would return
|
340 |
| - /// [`Ok`][result]. |
| 342 | + /// [`Ok`]. |
341 | 343 | ///
|
342 | 344 | /// [try_unwrap]: struct.Rc.html#method.try_unwrap
|
343 |
| - /// [result]: ../../std/result/enum.Result.html |
| 345 | + /// [`Ok`]: ../../std/result/enum.Result.html#variant.Ok |
344 | 346 | ///
|
345 | 347 | /// # Examples
|
346 | 348 | ///
|
@@ -543,14 +545,14 @@ impl<T: ?Sized> Rc<T> {
|
543 | 545 | /// Returns a mutable reference to the inner value, if there are
|
544 | 546 | /// no other `Rc` or [`Weak`][weak] pointers to the same value.
|
545 | 547 | ///
|
546 |
| - /// Returns [`None`][option] otherwise, because it is not safe to |
| 548 | + /// Returns [`None`] otherwise, because it is not safe to |
547 | 549 | /// mutate a shared value.
|
548 | 550 | ///
|
549 | 551 | /// See also [`make_mut`][make_mut], which will [`clone`][clone]
|
550 | 552 | /// the inner value when it's shared.
|
551 | 553 | ///
|
552 | 554 | /// [weak]: struct.Weak.html
|
553 |
| - /// [option]: ../../std/option/enum.Option.html |
| 555 | + /// [`None`]: ../../std/option/enum.Option.html#variant.None |
554 | 556 | /// [make_mut]: struct.Rc.html#method.make_mut
|
555 | 557 | /// [clone]: ../../std/clone/trait.Clone.html#tymethod.clone
|
556 | 558 | ///
|
|
0 commit comments