Auto merge of #29070 - Manishearth:rollup, r=Manishearth

- Successful merges: #28906, #29022, #29047, #29058, #29059, #29060, #29062, #29066, #29068
- Failed merges:

Author: bors

COMPILER_TESTS.md

@@ -1,6 +1,6 @@
 # Compiler Test Documentation
 
-In the Rust project, we use a special set of comands embedded in
+In the Rust project, we use a special set of commands embedded in
 comments to test the Rust compiler. There are two groups of commands:
 
 1. Header commands

src/doc/complement-lang-faq.md

@@ -76,7 +76,7 @@ Cleanup through RAII-style destructors is more likely to work than in catch bloc
 
 ## Why aren't modules type-parametric?
 
-We want to maintain the option to parametrize at runtime. We may eventually change this limitation, but initially this is how type parameters were implemented.
+We want to maintain the option to parameterize at runtime. We may eventually change this limitation, but initially this is how type parameters were implemented.
 
 ## Why aren't values type-parametric? Why only items?
 

src/doc/nomicon/casts.md

@@ -52,7 +52,7 @@ For numeric casts, there are quite a few cases to consider:
     * zero-extend if the source is unsigned
     * sign-extend if the source is signed
 * casting from a float to an integer will round the float towards zero
-    * **[NOTE: currently this will cause Undefined Behaviour if the rounded
+    * **[NOTE: currently this will cause Undefined Behavior if the rounded
       value cannot be represented by the target integer type][float-int]**.
       This includes Inf and NaN. This is a bug and will be fixed.
 * casting from an integer to float will produce the floating point
@@ -61,7 +61,7 @@ For numeric casts, there are quite a few cases to consider:
 * casting from an f32 to an f64 is perfect and lossless
 * casting from an f64 to an f32 will produce the closest possible value
   (rounding strategy unspecified)
-    * **[NOTE: currently this will cause Undefined Behaviour if the value
+    * **[NOTE: currently this will cause Undefined Behavior if the value
       is finite but larger or smaller than the largest or smallest finite
       value representable by f32][float-float]**. This is a bug and will
       be fixed.

src/doc/nomicon/dropck.md

@@ -6,7 +6,7 @@ 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
 gets dropped at the same time as another, right? This is why we used the
-following desugarring of `let` statements:
+following desugaring of `let` statements:
 
 ```rust,ignore
 let x;

src/doc/nomicon/exotic-sizes.md

@@ -20,7 +20,7 @@ information that "completes" them (more on this below).
 There are two major DSTs exposed by the language: trait objects, and slices.
 
 A trait object represents some type that implements the traits it specifies.
-The exact original type is *erased* in favour of runtime reflection
+The exact original type is *erased* in favor of runtime reflection
 with a vtable containing all the information necessary to use the type.
 This is the information that completes a trait object: a pointer to its vtable.
 
@@ -128,7 +128,7 @@ But neither of these tricks work today, so all Void types get you is
 the ability to be confident that certain situations are statically impossible.
 
 One final subtle detail about empty types is that raw pointers to them are
-actually valid to construct, but dereferencing them is Undefined Behaviour
+actually valid to construct, but dereferencing them is Undefined Behavior
 because that doesn't actually make sense. That is, you could model C's `void *`
 type with `*const Void`, but this doesn't necessarily gain anything over using
 e.g. `*const ()`, which *is* safe to randomly dereference.

src/doc/nomicon/leaking.md

@@ -90,7 +90,7 @@ let mut vec = vec![Box::new(0); 4];
 println!("{}", vec[0]);
 ```
 
-This is pretty clearly Not Good. Unfortunately, we're kind've stuck between a
+This is pretty clearly Not Good. Unfortunately, we're kind of stuck between a
 rock and a hard place: maintaining consistent state at every step has an
 enormous cost (and would negate any benefits of the API). Failing to maintain
 consistent state gives us Undefined Behavior in safe code (making the API
@@ -248,4 +248,4 @@ let mut data = Box::new(0);
 ```
 
 Dang. Here the destructor running was pretty fundamental to the API, and it had
-to be scrapped in favour of a completely different design.
+to be scrapped in favor of a completely different design.

src/doc/nomicon/meet-safe-and-unsafe.md

@@ -26,7 +26,7 @@ do some really crazy unsafe things.
 
 Safe Rust is the *true* Rust programming language. If all you do is write Safe
 Rust, you will never have to worry about type-safety or memory-safety. You will
-never endure a null or dangling pointer, or any of that Undefined Behaviour
+never endure a null or dangling pointer, or any of that Undefined Behavior
 nonsense.
 
 *That's totally awesome.*
@@ -52,11 +52,11 @@ The only things that are different in Unsafe Rust are that you can:
 * Mutate statics
 
 That's it. The reason these operations are relegated to Unsafe is that misusing
-any of these things will cause the ever dreaded Undefined Behaviour. Invoking
-Undefined Behaviour gives the compiler full rights to do arbitrarily bad things
-to your program. You definitely *should not* invoke Undefined Behaviour.
+any of these things will cause the ever dreaded Undefined Behavior. Invoking
+Undefined Behavior gives the compiler full rights to do arbitrarily bad things
+to your program. You definitely *should not* invoke Undefined Behavior.
 
-Unlike C, Undefined Behaviour is pretty limited in scope in Rust. All the core
+Unlike C, Undefined Behavior is pretty limited in scope in Rust. All the core
 language cares about is preventing the following things:
 
 * Dereferencing null or dangling pointers
@@ -71,9 +71,9 @@ language cares about is preventing the following things:
 * Unwinding into another language
 * Causing a [data race][race]
 
-That's it. That's all the causes of Undefined Behaviour baked into Rust. Of
+That's it. That's all the causes of Undefined Behavior baked into Rust. Of
 course, unsafe functions and traits are free to declare arbitrary other
-constraints that a program must maintain to avoid Undefined Behaviour. However,
+constraints that a program must maintain to avoid Undefined Behavior. However,
 generally violations of these constraints will just transitively lead to one of
 the above problems. Some additional constraints may also derive from compiler
 intrinsics that make special assumptions about how code can be optimized.

src/doc/nomicon/races.md

@@ -6,7 +6,7 @@ Safe Rust guarantees an absence of data races, which are defined as:
 * one of them is a write
 * one of them is unsynchronized
 
-A data race has Undefined Behaviour, and is therefore impossible to perform
+A data race has Undefined Behavior, and is therefore impossible to perform
 in Safe Rust. Data races are *mostly* prevented through rust's ownership system:
 it's impossible to alias a mutable reference, so it's impossible to perform a
 data race. Interior mutability makes this more complicated, which is largely why
@@ -53,7 +53,7 @@ thread::spawn(move || {
 // bounds checked, and there's no chance of the value getting changed
 // in the middle. However our program may panic if the thread we spawned
 // managed to increment before this ran. A race condition because correct
-// program execution (panicing is rarely correct) depends on order of
+// program execution (panicking is rarely correct) depends on order of
 // thread execution.
 println!("{}", data[idx.load(Ordering::SeqCst)]);
 ```

src/doc/nomicon/safe-unsafe-meaning.md

@@ -41,7 +41,7 @@ Some examples of unsafe functions:
 
 * `slice::get_unchecked` will perform unchecked indexing, allowing memory
   safety to be freely violated.
-* `ptr::offset` is an intrinsic that invokes Undefined Behaviour if it is
+* `ptr::offset` is an intrinsic that invokes Undefined Behavior if it is
   not "in bounds" as defined by LLVM.
 * `mem::transmute` reinterprets some value as having the given type,
   bypassing type safety in arbitrary ways. (see [conversions] for details)
@@ -59,9 +59,9 @@ As of Rust 1.0 there are exactly two unsafe traits:
 The need for unsafe traits boils down to the fundamental property of safe code:
 
 **No matter how completely awful Safe code is, it can't cause Undefined
-Behaviour.**
+Behavior.**
 
-This means that Unsafe Rust, **the royal vanguard of Undefined Behaviour**, has to be
+This means that Unsafe Rust, **the royal vanguard of Undefined Behavior**, has to be
 *super paranoid* about generic safe code. To be clear, Unsafe Rust is totally free to trust
 specific safe code. Anything else would degenerate into infinite spirals of
 paranoid despair. In particular it's generally regarded as ok to trust the standard library

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

@@ -15,7 +15,7 @@ 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
-cause Undefined Behaviour.
+cause Undefined Behavior.
 
 Send and Sync are also automatically derived traits. This means that, unlike
 every other trait, if a type is composed entirely of Send or Sync types, then it