Merge branch 'rust-lang:master' into c-unwind-documentation

Author: BatmanAoD

src/attributes/type_system.md

@@ -127,6 +127,14 @@ match message {
 }
 ```
 
+It's also not allowed to cast non-exhaustive types from foreign crates.
+```rust, ignore
+use othercrate::NonExhaustiveEnum;
+
+// Cannot cast a non-exhaustive enum outside of its defining crate.
+let _ = NonExhaustiveEnum::default() as u8;
+```
+
 Non-exhaustive types are always considered inhabited in downstream crates.
 
 [_MetaWord_]: ../attributes.md#meta-item-attribute-syntax

src/comments.md

@@ -34,7 +34,7 @@
 
 ## Non-doc comments
 
-Comments in Rust code follow the general C++ style of line (`//`) and
+Comments follow the general C++ style of line (`//`) and
 block (`/* ... */`) comment forms. Nested block comments are supported.
 
 Non-doc comments are interpreted as a form of whitespace.

src/expressions/array-expr.md

@@ -29,13 +29,6 @@ When the repeat operand is a constant item, it is evaluated the length operand's
 If that value is `0`, then the constant item is not evaluated at all.
 For expressions that are not a constant item, it is evaluated exactly once, and then the result is copied the length operand's value times.
 
-<div class="warning">
-
-Warning: In the case where the length operand is 0, and the repeat operand is a non-constant item, there is currently a bug in `rustc` where the value `a` is evaluated but not dropped, thus causing a leak.
-See [issue #74836](https://github.com/rust-lang/rust/issues/74836).
-
-</div>
-
 ```rust
 [1, 2, 3, 4];
 ["a", "b", "c", "d"];

src/expressions/await-expr.md

@@ -4,17 +4,20 @@
 > _AwaitExpression_ :\
 >    [_Expression_] `.` `await`
 
-*Await expressions* suspend the current computation until the given future is ready to produce a value.
-The syntax for an await expression is an expression with a type that implements the [Future] trait, called the *future operand*, then the token `.`, and then the `await` keyword.
+An `await` expression is a syntactic construct for suspending a computation
+provided by an implementation of `std::future::IntoFuture` until the given
+future is ready to produce a value.
+The syntax for an await expression is an expression with a type that implements the [`IntoFuture`] trait, called the *future operand*, then the token `.`, and then the `await` keyword.
 Await expressions are legal only within an [async context], like an [`async fn`] or an [`async` block].
 
 More specifically, an await expression has the following effect.
 
-1. Evaluate the future operand to a [future] `tmp`;
-2. Pin `tmp` using [`Pin::new_unchecked`];
-3. This pinned future is then polled by calling the [`Future::poll`] method and passing it the current [task context](#task-context);
-3. If the call to `poll` returns [`Poll::Pending`], then the future returns `Poll::Pending`, suspending its state so that, when the surrounding async context is re-polled,execution returns to step 2;
-4. Otherwise the call to `poll` must have returned [`Poll::Ready`], in which case the value contained in the [`Poll::Ready`] variant is used as the result of the `await` expression itself.
+1. Create a future by calling [`IntoFuture::into_future`] on the future operand.
+2. Evaluate the future to a [future] `tmp`;
+3. Pin `tmp` using [`Pin::new_unchecked`];
+4. This pinned future is then polled by calling the [`Future::poll`] method and passing it the current [task context](#task-context);
+5. If the call to `poll` returns [`Poll::Pending`], then the future returns `Poll::Pending`, suspending its state so that, when the surrounding async context is re-polled,execution returns to step 3;
+6. Otherwise the call to `poll` must have returned [`Poll::Ready`], in which case the value contained in the [`Poll::Ready`] variant is used as the result of the `await` expression itself.
 
 > **Edition differences**: Await expressions are only available beginning with Rust 2018.
 
@@ -29,7 +32,7 @@ Effectively, an await expression is roughly equivalent to the following non-norm
 
 <!-- ignore: example expansion -->
 ```rust,ignore
-match future_operand {
+match operand.into_future() {
     mut pinned => loop {
         let mut pin = unsafe { Pin::new_unchecked(&mut pinned) };
         match Pin::future::poll(Pin::borrow(&mut pin), &mut current_context) {
@@ -53,3 +56,5 @@ The variable `current_context` refers to the context taken from the async enviro
 [`poll::Ready`]: ../../std/task/enum.Poll.html#variant.Ready
 [async context]: ../expressions/block-expr.md#async-context
 [future]: ../../std/future/trait.Future.html
+[`IntoFuture`]: ../../std/future/trait.IntoFuture.html
+[`IntoFuture::into_future`]: ../../std/future/trait.IntoFuture.html#tymethod.into_future

src/interior-mutability.md

@@ -6,7 +6,7 @@ mutability if its internal state can be changed through a [shared reference] to
 it. This goes against the usual [requirement][ub] that the value pointed to by a
 shared reference is not mutated.
 
-[`std::cell::UnsafeCell<T>`] type is the only allowed way in Rust to disable
+[`std::cell::UnsafeCell<T>`] type is the only allowed way to disable
 this requirement. When `UnsafeCell<T>` is immutably aliased, it is still safe to
 mutate, or obtain a mutable reference to, the `T` it contains. As with all
 other types, it is undefined behavior to have multiple `&mut UnsafeCell<T>`

src/items/external-blocks.md

@@ -167,9 +167,9 @@ block.
 This modifier is only compatible with the `static` linking kind.
 Using any other kind will result in a compiler error.
 
-When building a rlib or staticlib `+bundle` means that all object files from the native static
-library will be added to the rlib or staticlib archive, and then used from it during linking of
-the final binary.
+When building a rlib or staticlib `+bundle` means that the native static library
+will be packed into the rlib or staticlib archive, and then retrieved from there
+during linking of the final binary.
 
 When building a rlib `-bundle` means that the native static library is registered as a dependency
 of that rlib "by name", and object files from it are included only during linking of the final

src/items/functions.md

@@ -175,7 +175,7 @@ is equivalent to:
 extern "Rust" fn foo() {}
 ```
 
-Functions in Rust can be called by foreign code, and using an ABI that
+Functions can be called by foreign code, and using an ABI that
 differs from Rust allows, for example, to provide functions that can be
 called from other programming languages like C:
 

src/macros-by-example.md

@@ -193,53 +193,6 @@ compiler knows how to expand them properly:
     not have the same number. This requirement applies to every layer of nested
     repetitions.
 
-## Dollar-dollar ($$)
-
-`$$` expands to a single `$`.
-
-Since metavariable expressions always apply during the expansion of a macro, they cannot be used in recursive macro definitions and this is where `$$` expressions comes into play, i.e., `$$` can be used to resolve ambiguities in nested macros.
-
-The following example illustrates a macro that fails to compile due to the ambiguity of the repetition in a nested macro:
-
-```rust,compile_fail
-macro_rules! foo_error {
-    () => {
-        macro_rules! bar_error {
-            ( $( $any:tt )* ) => { $( $any )* };
-            // ^^^^^^^^^^^ error: attempted to repeat an expression containing no syntax variables matched as repeating at this depth
-        }
-    };
-}
-
-foo_error!();
-```
-
-The following resolves the problem by escaping the `$` in the repetition with `$$`:
-
-```rust
-macro_rules! foo_ok {
-    () => {
-        macro_rules! bar_ok {
-            ( $$( $any:tt )* ) => { $$( $any )* };
-        }
-    };
-}
-
-foo_ok!();
-```
-
-One consequence of such expansion is that deeper nested levels make dollar-dollar declarations grown linearly, starting at `$$`, then `$$$$`, then `$$$$$` and so on. This is also necessary to be fully featured so that it is possible to specify names of metavariables using other metavariables at each nesting level.
-
-```ignore
-$foo          => bar      => bar    // Evaluate foo at level 1
-$$foo         => $foo     => bar    // Evaluate foo at level 2
-$$$foo        => $bar     => baz    // Evaluate foo at level 1, and use that as a name at level 2
-$$$$foo       => $$foo    => $foo   // Evaluate foo at level 3
-$$$$$foo      => $$bar    => $bar   // Evaluate foo at level 1, and use that as a name at level 3
-$$$$$$foo     => $$$foo   => $bar   // Evaluate foo at level 2, and use that as a name at level 3
-$$$$$$$foo    => $$$bar   => $baz   // Evaluate foo at level 1, use that at level 2, and then use *that* at level 3
-```
-
 ## Scoping, Exporting, and Importing
 
 For historical reasons, the scoping of macros by example does not work entirely

src/statements-and-expressions.md

@@ -7,5 +7,5 @@ each other kind of expression, and rules for evaluation of expressions involve
 specifying both the value produced by the expression and the order in which its
 sub-expressions are themselves evaluated.
 
-In contrast, statements in Rust serve _mostly_ to contain and explicitly
+In contrast, statements serve _mostly_ to contain and explicitly
 sequence expression evaluation.

src/subtyping.md

@@ -1,7 +1,7 @@
 # Subtyping and Variance
 
 Subtyping is implicit and can occur at any stage in type checking or
-inference. Subtyping in Rust is very restricted and occurs only due to
+inference. Subtyping is restricted to two cases:
 variance with respect to lifetimes and between types with higher ranked
 lifetimes. If we were to erase lifetimes from types, then the only subtyping
 would be due to type equality.