Skip to content

Commit 6210dcd

Browse files
committed
Auto merge of #27530 - Manishearth:rollup, r=Manishearth
- Successful merges: #27519, #27521, #27525, #27527, #27528 - Failed merges:
2 parents 76ff835 + eee286d commit 6210dcd

11 files changed

+151
-148
lines changed

src/doc/nomicon/atomics.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -127,7 +127,7 @@ fundamentally unsynchronized and compilers are free to aggressively optimize
127127
them. In particular, data accesses are free to be reordered by the compiler on
128128
the assumption that the program is single-threaded. The hardware is also free to
129129
propagate the changes made in data accesses to other threads as lazily and
130-
inconsistently as it wants. Mostly critically, data accesses are how data races
130+
inconsistently as it wants. Most critically, data accesses are how data races
131131
happen. Data accesses are very friendly to the hardware and compiler, but as
132132
we've seen they offer *awful* semantics to try to write synchronized code with.
133133
Actually, that's too weak.

src/doc/nomicon/concurrency.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -7,7 +7,7 @@ an abstraction over them in a relatively uncontroversial way. Message passing,
77
green threads, and async APIs are all diverse enough that any abstraction over
88
them tends to involve trade-offs that we weren't willing to commit to for 1.0.
99

10-
However the way Rust models concurrency makes it relatively easy design your own
10+
However the way Rust models concurrency makes it relatively easy to design your own
1111
concurrency paradigm as a library and have everyone else's code Just Work
1212
with yours. Just require the right lifetimes and Send and Sync where appropriate
1313
and you're off to the races. Or rather, off to the... not... having... races.

src/doc/nomicon/destructors.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -120,7 +120,7 @@ enum Link {
120120
will have its inner Box field dropped if and only if an instance stores the
121121
Next variant.
122122

123-
In general this works really nice because you don't need to worry about
123+
In general this works really nicely because you don't need to worry about
124124
adding/removing drops when you refactor your data layout. Still there's
125125
certainly many valid usecases for needing to do trickier things with
126126
destructors.

src/doc/nomicon/drop-flags.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
11
% Drop Flags
22

33
The examples in the previous section introduce an interesting problem for Rust.
4-
We have seen that's possible to conditionally initialize, deinitialize, and
4+
We have seen that it's possible to conditionally initialize, deinitialize, and
55
reinitialize locations of memory totally safely. For Copy types, this isn't
66
particularly notable since they're just a random pile of bits. However types
77
with destructors are a different story: Rust needs to know whether to call a

src/doc/nomicon/dropck.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
11
% Drop Check
22

33
We have seen how lifetimes provide us some fairly simple rules for ensuring
4-
that never read dangling references. However up to this point we have only ever
4+
that we never read dangling references. However up to this point we have only ever
55
interacted with the *outlives* relationship in an inclusive manner. That is,
66
when we talked about `'a: 'b`, it was ok for `'a` to live *exactly* as long as
77
`'b`. At first glance, this seems to be a meaningless distinction. Nothing ever

src/doc/nomicon/send-and-sync.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -3,15 +3,15 @@
33
Not everything obeys inherited mutability, though. Some types allow you to
44
multiply alias a location in memory while mutating it. Unless these types use
55
synchronization to manage this access, they are absolutely not thread safe. Rust
6-
captures this with through the `Send` and `Sync` traits.
6+
captures this through the `Send` and `Sync` traits.
77

88
* A type is Send if it is safe to send it to another thread.
99
* A type is Sync if it is safe to share between threads (`&T` is Send).
1010

1111
Send and Sync are fundamental to Rust's concurrency story. As such, a
1212
substantial amount of special tooling exists to make them work right. First and
1313
foremost, they're [unsafe traits][]. This means that they are unsafe to
14-
implement, and other unsafe code can that they are correctly
14+
implement, and other unsafe code can assume that they are correctly
1515
implemented. Since they're *marker traits* (they have no associated items like
1616
methods), correctly implemented simply means that they have the intrinsic
1717
properties an implementor should have. Incorrectly implementing Send or Sync can

src/doc/nomicon/subtyping.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -93,8 +93,8 @@ fn main() {
9393

9494
The signature of `overwrite` is clearly valid: it takes mutable references to
9595
two values of the same type, and overwrites one with the other. If `&mut T` was
96-
variant over T, then `&mut &'a str` would be a subtype of `&mut &'static str`,
97-
since `&'a str` is a subtype of `&'static str`. Therefore the lifetime of
96+
variant over T, then `&mut &'static str` would be a subtype of `&mut &'a str`,
97+
since `&'static str` is a subtype of `&'a str`. Therefore the lifetime of
9898
`forever_str` would successfully be "shrunk" down to the shorter lifetime of
9999
`string`, and `overwrite` would be called successfully. `string` would
100100
subsequently be dropped, and `forever_str` would point to freed memory when we

src/doc/nomicon/unchecked-uninit.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -77,7 +77,7 @@ contain any `Drop` types.
7777
However when working with uninitialized memory you need to be ever-vigilant for
7878
Rust trying to drop values you make like this before they're fully initialized.
7979
Every control path through that variable's scope must initialize the value
80-
before it ends, if has a destructor.
80+
before it ends, if it has a destructor.
8181
*[This includes code panicking](unwinding.html)*.
8282

8383
And that's about it for working with uninitialized memory! Basically nothing

src/doc/reference.md

Lines changed: 3 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -538,8 +538,9 @@ balanced, but they are otherwise not special.
538538
In the matcher, `$` _name_ `:` _designator_ matches the nonterminal in the Rust
539539
syntax named by _designator_. Valid designators are `item`, `block`, `stmt`,
540540
`pat`, `expr`, `ty` (type), `ident`, `path`, `tt` (either side of the `=>`
541-
in macro rules). In the transcriber, the designator is already known, and so
542-
only the name of a matched nonterminal comes after the dollar sign.
541+
in macro rules), and `meta` (contents of an attribute). In the transcriber, the
542+
designator is already known, and so only the name of a matched nonterminal comes
543+
after the dollar sign.
543544

544545
In both the matcher and transcriber, the Kleene star-like operator indicates
545546
repetition. The Kleene star operator consists of `$` and parentheses, optionally

0 commit comments

Comments
 (0)