Auto merge of #30619 - steveklabnik:rollup, r=steveklabnik

- Successful merges: #30253, #30390, #30405, #30549, #30603, #30610
- Failed merges:

src/doc/book/macros.md

@@ -611,8 +611,7 @@ to define a single macro that works both inside and outside our library. The
 function name will expand to either `::increment` or `::mylib::increment`.
 
 To keep this system simple and correct, `#[macro_use] extern crate ...` may
-only appear at the root of your crate, not inside `mod`. This ensures that
-`$crate` is a single identifier.
+only appear at the root of your crate, not inside `mod`.
 
 # The deep end
 

src/libcore/fmt/mod.rs

@@ -356,7 +356,7 @@ impl<'a> Display for Arguments<'a> {
 /// `Debug` implementations using either `derive` or the debug builder API
 /// on `Formatter` support pretty printing using the alternate flag: `{:#?}`.
 ///
-/// [debug_struct]: ../std/fmt/struct.Formatter.html#method.debug_struct
+/// [debug_struct]: ../../std/fmt/struct.Formatter.html#method.debug_struct
 ///
 /// Pretty printing with `#?`:
 ///

src/libcore/iter.rs

@@ -604,7 +604,7 @@ pub trait Iterator {
     /// iterators, returning a tuple where the first element comes from the
     /// first iterator, and the second element comes from the second iterator.
     ///
-    /// In other words, it zips two iterators together, into a single one. 🤐
+    /// In other words, it zips two iterators together, into a single one.
     ///
     /// When either iterator returns `None`, all further calls to `next()`
     /// will return `None`.

src/libcore/macros.rs

@@ -135,10 +135,10 @@ macro_rules! debug_assert {
     ($($arg:tt)*) => (if cfg!(debug_assertions) { assert!($($arg)*); })
 }
 
-/// Asserts that two expressions are equal to each other, testing equality in
-/// both directions.
+/// Asserts that two expressions are equal to each other.
 ///
-/// On panic, this macro will print the values of the expressions.
+/// On panic, this macro will print the values of the expressions with their
+/// debug representations.
 ///
 /// Unlike `assert_eq!`, `debug_assert_eq!` statements are only enabled in non
 /// optimized builds by default. An optimized build will omit all

src/librustc_metadata/loader.rs

@@ -664,6 +664,8 @@ impl<'a> Context<'a> {
                 }
                 sess.err(&format!("extern location for {} is of an unknown type: {}",
                                  self.crate_name, loc.display()));
+                sess.help(&format!("file name should be lib*.rlib or {}*.{}",
+                                   dylibname.0, dylibname.1));
                 false
             });
 

src/librustc_resolve/diagnostics.rs

@@ -274,7 +274,7 @@ https://doc.rust-lang.org/reference.html#use-declarations
 "##,
 
 E0401: r##"
-Inner functions do not inherit type parameters from the functions they are
+Inner items do not inherit type parameters from the functions they are
 embedded in. For example, this will not compile:
 
 ```
@@ -286,12 +286,32 @@ fn foo<T>(x: T) {
 }
 ```
 
-Functions inside functions are basically just like top-level functions, except
-that they can only be called from the function they are in.
+nor will this:
+
+```
+fn foo<T>(x: T) {
+    type MaybeT = Option<T>;
+    // ...
+}
+```
+
+or this:
+
+```
+fn foo<T>(x: T) {
+    struct Foo {
+        x: T,
+    }
+    // ...
+}
+```
+
+Items inside functions are basically just like top-level items, except
+that they can only be used from the function they are in.
 
 There are a couple of solutions for this.
 
-You can use a closure:
+If the item is a function, you may use a closure:
 
 ```
 fn foo<T>(x: T) {
@@ -302,7 +322,7 @@ fn foo<T>(x: T) {
 }
 ```
 
-or copy over the parameters:
+For a generic item, you can copy over the parameters:
 
 ```
 fn foo<T>(x: T) {
@@ -313,6 +333,12 @@ fn foo<T>(x: T) {
 }
 ```
 
+```
+fn foo<T>(x: T) {
+    type MaybeT<T> = Option<T>;
+}
+```
+
 Be sure to copy over any bounds as well:
 
 ```
@@ -324,10 +350,18 @@ fn foo<T: Copy>(x: T) {
 }
 ```
 
+```
+fn foo<T: Copy>(x: T) {
+    struct Foo<T: Copy> {
+        x: T,
+    }
+}
+```
+
 This may require additional type hints in the function body.
 
-In case the function is in an `impl`, defining a private helper function might
-be easier:
+In case the item is a function inside an `impl`, defining a private helper
+function might be easier:
 
 ```
 impl<T> Foo<T> {