From 399efd4cdc9a1bc788fa93a21490abc8d904c3e0 Mon Sep 17 00:00:00 2001 From: Ivan Jager Date: Tue, 4 Aug 2015 17:09:44 -0500 Subject: [PATCH] Fix some grammar in The Advanced Rust Programming Language --- atomics.md | 2 +- concurrency.md | 2 +- destructors.md | 2 +- drop-flags.md | 2 +- dropck.md | 2 +- send-and-sync.md | 4 ++-- unchecked-uninit.md | 2 +- 7 files changed, 8 insertions(+), 8 deletions(-) diff --git a/atomics.md b/atomics.md index 2d567e3..d781e59 100644 --- a/atomics.md +++ b/atomics.md @@ -127,7 +127,7 @@ fundamentally unsynchronized and compilers are free to aggressively optimize them. In particular, data accesses are free to be reordered by the compiler on the assumption that the program is single-threaded. The hardware is also free to propagate the changes made in data accesses to other threads as lazily and -inconsistently as it wants. Mostly critically, data accesses are how data races +inconsistently as it wants. Most critically, data accesses are how data races happen. Data accesses are very friendly to the hardware and compiler, but as we've seen they offer *awful* semantics to try to write synchronized code with. Actually, that's too weak. diff --git a/concurrency.md b/concurrency.md index 9dcbecd..802f320 100644 --- a/concurrency.md +++ b/concurrency.md @@ -7,7 +7,7 @@ an abstraction over them in a relatively uncontroversial way. Message passing, green threads, and async APIs are all diverse enough that any abstraction over them tends to involve trade-offs that we weren't willing to commit to for 1.0. -However the way Rust models concurrency makes it relatively easy design your own +However the way Rust models concurrency makes it relatively easy to design your own concurrency paradigm as a library and have everyone else's code Just Work with yours. Just require the right lifetimes and Send and Sync where appropriate and you're off to the races. Or rather, off to the... not... having... races. diff --git a/destructors.md b/destructors.md index 568f7c0..29a8660 100644 --- a/destructors.md +++ b/destructors.md @@ -120,7 +120,7 @@ enum Link { will have its inner Box field dropped if and only if an instance stores the Next variant. -In general this works really nice because you don't need to worry about +In general this works really nicely because you don't need to worry about adding/removing drops when you refactor your data layout. Still there's certainly many valid usecases for needing to do trickier things with destructors. diff --git a/drop-flags.md b/drop-flags.md index 1e81c97..5655c5d 100644 --- a/drop-flags.md +++ b/drop-flags.md @@ -1,7 +1,7 @@ % Drop Flags The examples in the previous section introduce an interesting problem for Rust. -We have seen that's possible to conditionally initialize, deinitialize, and +We have seen that it's possible to conditionally initialize, deinitialize, and reinitialize locations of memory totally safely. For Copy types, this isn't particularly notable since they're just a random pile of bits. However types with destructors are a different story: Rust needs to know whether to call a diff --git a/dropck.md b/dropck.md index df09d1a..98d269f 100644 --- a/dropck.md +++ b/dropck.md @@ -1,7 +1,7 @@ % Drop Check We have seen how lifetimes provide us some fairly simple rules for ensuring -that never read dangling references. However up to this point we have only ever +that we never read dangling references. However up to this point we have only ever interacted with the *outlives* relationship in an inclusive manner. That is, when we talked about `'a: 'b`, it was ok for `'a` to live *exactly* as long as `'b`. At first glance, this seems to be a meaningless distinction. Nothing ever diff --git a/send-and-sync.md b/send-and-sync.md index 334d5c9..8724b97 100644 --- a/send-and-sync.md +++ b/send-and-sync.md @@ -3,7 +3,7 @@ Not everything obeys inherited mutability, though. Some types allow you to multiply alias a location in memory while mutating it. Unless these types use synchronization to manage this access, they are absolutely not thread safe. Rust -captures this with through the `Send` and `Sync` traits. +captures this through the `Send` and `Sync` traits. * A type is Send if it is safe to send it to another thread. * A type is Sync if it is safe to share between threads (`&T` is Send). @@ -11,7 +11,7 @@ captures this with through the `Send` and `Sync` traits. Send and Sync are fundamental to Rust's concurrency story. As such, a substantial amount of special tooling exists to make them work right. First and foremost, they're [unsafe traits][]. This means that they are unsafe to -implement, and other unsafe code can that they are correctly +implement, and other unsafe code can assume that they are correctly implemented. Since they're *marker traits* (they have no associated items like methods), correctly implemented simply means that they have the intrinsic properties an implementor should have. Incorrectly implementing Send or Sync can diff --git a/unchecked-uninit.md b/unchecked-uninit.md index da9fb29..5ae1818 100644 --- a/unchecked-uninit.md +++ b/unchecked-uninit.md @@ -77,7 +77,7 @@ contain any `Drop` types. However when working with uninitialized memory you need to be ever-vigilant for Rust trying to drop values you make like this before they're fully initialized. Every control path through that variable's scope must initialize the value -before it ends, if has a destructor. +before it ends, if it has a destructor. *[This includes code panicking](unwinding.html)*. And that's about it for working with uninitialized memory! Basically nothing