fix #24968 more friend error message for Self in fn args

src/doc/reference.md

@@ -3529,7 +3529,9 @@ The actual implementation for each vtable entry can vary on an object-by-object
 basis.
 
 Note that for a trait object to be instantiated, the trait must be
-_object-safe_. Object safety rules are defined in [RFC 255][rfc255].
+_object-safe_. Object safety rules are defined in [RFC 255].
+
+[RFC 255]: https://github.com/rust-lang/rfcs/blob/master/text/0255-object-safety.md
 
 Given a pointer-typed expression `E` of type `&T` or `Box<T>`, where `T`
 implements trait `R`, casting `E` to the corresponding pointer type `&R` or

src/doc/trpl/concurrency.md

@@ -6,7 +6,7 @@ and more cores, yet many programmers aren't prepared to fully utilize them.
 
 Rust's memory safety features also apply to its concurrency story too. Even
 concurrent Rust programs must be memory safe, having no data races. Rust's type
-system is up to the thread, and gives you powerful ways to reason about
+system is up to the task, and gives you powerful ways to reason about
 concurrent code at compile time.
 
 Before we talk about the concurrency features that come with Rust, it's important

src/doc/trpl/dining-philosophers.md

@@ -73,6 +73,9 @@ a name is all we need. We choose the [`String`][string] type for the name,
 rather than `&str`. Generally speaking, working with a type which owns its
 data is easier than working with one that uses references.
 
+[struct]: structs.html
+[string]: strings.html
+
 Let’s continue:
 
 ```rust

src/doc/trpl/enums.md

@@ -55,9 +55,6 @@ fn process_color_change(msg: Message) {
 }
 ```
 
-Both variants are named `Digit`, but since they’re scoped to the `enum` name
-there's no ambiguity.
-
 Not supporting these operations may seem rather limiting, but it’s a limitation
 which we can overcome. There are two ways: by implementing equality ourselves,
 or by pattern matching variants with [`match`][match] expressions, which you’ll
@@ -66,3 +63,4 @@ equality yet, but we’ll find out in the [`traits`][traits] section.
 
 [match]: match.html
 [if-let]: if-let.html
+[traits]: traits.html

src/doc/trpl/guessing-game.md

@@ -213,12 +213,12 @@ The next part will use this handle to get input from the user:
 ```
 
 Here, we call the [`read_line()`][read_line] method on our handle.
-[Method][method]s are like associated functions, but are only available on a
+[Methods][method] are like associated functions, but are only available on a
 particular instance of a type, rather than the type itself. We’re also passing
 one argument to `read_line()`: `&mut guess`.
 
 [read_line]: ../std/io/struct.Stdin.html#method.read_line
-[method]: methods.html
+[method]: method-syntax.html
 
 Remember how we bound `guess` above? We said it was mutable. However,
 `read_line` doesn’t take a `String` as an argument: it takes a `&mut String`.

src/doc/trpl/iterators.md

@@ -42,7 +42,7 @@ loop is just a handy way to write this `loop`/`match`/`break` construct.
 `for` loops aren't the only thing that uses iterators, however. Writing your
 own iterator involves implementing the `Iterator` trait. While doing that is
 outside of the scope of this guide, Rust provides a number of useful iterators
-to accomplish various threads. Before we talk about those, we should talk about a
+to accomplish various tasks. Before we talk about those, we should talk about a
 Rust anti-pattern. And that's using ranges like this.
 
 Yes, we just talked about how ranges are cool. But ranges are also very

src/doc/trpl/match.md

@@ -97,4 +97,4 @@ Unlike the previous uses of `match`, you can’t use the normal `if`
 statement to do this. You can use the [`if let`][if-let] statement,
 which can be seen as an abbreviated form of `match`.
 
-[if-let][if-let.html]
+[if-let]: if-let.html

src/doc/trpl/mutability.md

@@ -35,7 +35,7 @@ let y = &mut x;
 
 `y` is an immutable binding to a mutable reference, which means that you can’t
 bind `y` to something else (`y = &mut z`), but you can mutate the thing that’s
-bound to `y`. (`*y = 5`) A subtle distinction.
+bound to `y` (`*y = 5`). A subtle distinction.
 
 Of course, if you need both:
 

src/doc/trpl/patterns.md

@@ -66,7 +66,7 @@ match x {
 }
 ```
 
-This prints `something else`
+This prints `something else`.
 
 # Bindings
 
@@ -152,7 +152,7 @@ match x {
 }
 ```
 
-This prints `Got an int!`
+This prints `Got an int!`.
 
 # ref and ref mut
 

src/doc/trpl/structs.md

@@ -196,3 +196,5 @@ useful. For instance, a library may ask you to create a structure that
 implements a certain [trait][trait] to handle events. If you don’t have
 any data you need to store in the structure, you can just create a
 unit-like struct.
+
+[trait]: traits.html

src/doc/trpl/the-stack-and-the-heap.md

@@ -80,15 +80,15 @@ This memory is kind of like a giant array: addresses start at zero and go
 up to the final number. So here’s a diagram of our first stack frame:
 
 | Address | Name | Value |
-+---------+------+-------+
+|---------|------|-------|
 | 0       | x    | 42    |
 
 We’ve got `x` located at address `0`, with the value `42`.
 
 When `foo()` is called, a new stack frame is allocated:
 
 | Address | Name | Value |
-+---------+------+-------+
+|---------|------|-------|
 | 2       | z    | 100   |
 | 1       | y    | 5     |
 | 0       | x    | 42    |
@@ -107,7 +107,7 @@ value being stored.
 After `foo()` is over, its frame is deallocated:
 
 | Address | Name | Value |
-+---------+------+-------+
+|---------|------|-------|
 | 0       | x    | 42    |
 
 And then, after `main()`, even this last value goes away. Easy!
@@ -142,13 +142,13 @@ fn main() {
 Okay, first, we call `main()`:
 
 | Address | Name | Value |
-+---------+------+-------+
+|---------|------|-------|
 | 0       | x    | 42    |
 
 Next up, `main()` calls `foo()`:
 
 | Address | Name | Value |
-+---------+------+-------+
+|---------|------|-------|
 | 3       | c    | 1     |
 | 2       | b    | 100   |
 | 1       | a    | 5     |
@@ -157,7 +157,7 @@ Next up, `main()` calls `foo()`:
 And then `foo()` calls `bar()`:
 
 | Address | Name | Value |
-+---------+------+-------+
+|---------|------|-------|
 | 4       | i    | 6     |
 | 3       | c    | 1     |
 | 2       | b    | 100   |
@@ -170,7 +170,7 @@ After `bar()` is over, its frame is deallocated, leaving just `foo()` and
 `main()`:
 
 | Address | Name | Value |
-+---------+------+-------+
+|---------|------|-------|
 | 3       | c    | 1     |
 | 2       | b    | 100   |
 | 1       | a    | 5     |
@@ -179,7 +179,7 @@ After `bar()` is over, its frame is deallocated, leaving just `foo()` and
 And then `foo()` ends, leaving just `main()`
 
 | Address | Name | Value |
-+---------+------+-------+
+|---------|------|-------|
 | 0       | x    | 42    |
 
 And then we’re done. Getting the hang of it? It’s like piling up dishes: you
@@ -206,7 +206,7 @@ fn main() {
 Here’s what happens in memory when `main()` is called:
 
 | Address | Name | Value  |
-+---------+------+--------+
+|---------|------|--------|
 | 1       | y    | 42     |
 | 0       | x    | ?????? |
 
@@ -218,7 +218,7 @@ it allocates some memory for the heap, and puts `5` there. The memory now looks
 like this:
 
 | Address         | Name | Value          |
-+-----------------+------+----------------+
+|-----------------|------|----------------|
 | 2<sup>30</sup>  |      | 5              |
 | ...             | ...  | ...            |
 | 1               | y    | 42             |
@@ -243,7 +243,7 @@ layout of a program which has been running for a while now:
 
 
 | Address              | Name | Value                |
-+----------------------+------+----------------------+
+|----------------------|------|----------------------|
 | 2<sup>30</sup>       |      | 5                    |
 | (2<sup>30</sup>) - 1 |      |                      |
 | (2<sup>30</sup>) - 2 |      |                      |
@@ -272,7 +272,7 @@ when it was created. Great! So when `x` goes away, it first frees the memory
 allocated on the heap:
 
 | Address | Name | Value  |
-+---------+------+--------+
+|---------|------|--------|
 | 1       | y    | 42     |
 | 0       | x    | ?????? |
 
@@ -305,7 +305,7 @@ fn main() {
 When we enter `main()`, memory looks like this:
 
 | Address | Name | Value |
-+---------+------+-------+
+|---------|------|-------|
 | 1       | y    | 0     |
 | 0       | x    | 5     |
 
@@ -315,7 +315,7 @@ memory location that `x` lives at, which in this case is `0`.
 What about when we call `foo()`, passing `y` as an argument?
 
 | Address | Name | Value |
-+---------+------+-------+
+|---------|------|-------|
 | 3       | z    | 42    |
 | 2       | i    | 0     |
 | 1       | y    | 0     |
@@ -367,7 +367,7 @@ fn main() {
 First, we call `main()`:
 
 | Address         | Name | Value          |
-+-----------------+------+----------------+
+|-----------------|------|----------------|
 | 2<sup>30</sup>  |      | 20             |
 | ...             | ...  | ...            |
 | 2               | j    | 0              |
@@ -380,7 +380,7 @@ value pointing there.
 Next, at the end of `main()`, `foo()` gets called:
 
 | Address         | Name | Value          |
-+-----------------+------+----------------+
+|-----------------|------|----------------|
 | 2<sup>30</sup>  |      | 20             |
 | ...             | ...  | ...            |
 | 5               | z    | 4              |
@@ -397,7 +397,7 @@ since `j` points at `h`.
 Next, `foo()` calls `baz()`, passing `z`:
 
 | Address         | Name | Value          |
-+-----------------+------+----------------+
+|-----------------|------|----------------|
 | 2<sup>30</sup>  |      | 20             |
 | ...             | ...  | ...            |
 | 7               | g    | 100            |
@@ -413,7 +413,7 @@ We’ve allocated memory for `f` and `g`. `baz()` is very short, so when it’s
 over, we get rid of its stack frame:
 
 | Address         | Name | Value          |
-+-----------------+------+----------------+
+|-----------------|------|----------------|
 | 2<sup>30</sup>  |      | 20             |
 | ...             | ...  | ...            |
 | 5               | z    | 4              |
@@ -426,11 +426,11 @@ over, we get rid of its stack frame:
 Next, `foo()` calls `bar()` with `x` and `z`:
 
 | Address              | Name | Value                |
-+----------------------+------+----------------------+
+|----------------------|------|----------------------|
 |  2<sup>30</sup>      |      | 20                   |
 | (2<sup>30</sup>) - 1 |      | 5                    |
 | ...                  | ...  | ...                  |
-| 10                   | e    | 4                    |
+| 10                   | e    | 9                    |
 | 9                    | d    | (2<sup>30</sup>) - 1 |
 | 8                    | c    | 5                    |
 | 7                    | b    | 4                    |
@@ -449,13 +449,13 @@ case, we set up the variables as usual.
 At the end of `bar()`, it calls `baz()`:
 
 | Address              | Name | Value                |
-+----------------------+------+----------------------+
+|----------------------|------|----------------------|
 |  2<sup>30</sup>      |      | 20                   |
 | (2<sup>30</sup>) - 1 |      | 5                    |
 | ...                  | ...  | ...                  |
 | 12                   | g    | 100                  |
 | 11                   | f    | 4                    |
-| 10                   | e    | 4                    |
+| 10                   | e    | 9                    |
 | 9                    | d    | (2<sup>30</sup>) - 1 |
 | 8                    | c    | 5                    |
 | 7                    | b    | 4                    |
@@ -473,11 +473,11 @@ far.
 After `baz()` is over, we get rid of `f` and `g`:
 
 | Address              | Name | Value                |
-+----------------------+------+----------------------+
+|----------------------|------|----------------------|
 |  2<sup>30</sup>      |      | 20                   |
 | (2<sup>30</sup>) - 1 |      | 5                    |
 | ...                  | ...  | ...                  |
-| 10                   | e    | 4                    |
+| 10                   | e    | 9                    |
 | 9                    | d    | (2<sup>30</sup>) - 1 |
 | 8                    | c    | 5                    |
 | 7                    | b    | 4                    |
@@ -493,7 +493,7 @@ Next, we return from `bar()`. `d` in this case is a `Box<T>`, so it also frees
 what it points to: (2<sup>30</sup>) - 1.
 
 | Address         | Name | Value          |
-+-----------------+------+----------------+
+|-----------------|------|----------------|
 |  2<sup>30</sup> |      | 20             |
 | ...             | ...  | ...            |
 | 5               | z    | 4              |
@@ -506,7 +506,7 @@ what it points to: (2<sup>30</sup>) - 1.
 And after that, `foo()` returns:
 
 | Address         | Name | Value          |
-+-----------------+------+----------------+
+|-----------------|------|----------------|
 |  2<sup>30</sup> |      | 20             |
 | ...             | ...  | ...            |
 | 2               | j    | 0              |

src/doc/trpl/while-loops.md

@@ -3,7 +3,7 @@
 Rust also has a `while` loop. It looks like this:
 
 ```{rust}
-let mut x = 5; // mut x: u32
+let mut x = 5; // mut x: i32
 let mut done = false; // mut done: bool
 
 while !done {

src/libcollections/str.rs

@@ -396,6 +396,7 @@ macro_rules! utf8_acc_cont_byte {
 
 #[stable(feature = "rust1", since = "1.0.0")]
 impl Borrow<str> for String {
+    #[inline]
     fn borrow(&self) -> &str { &self[..] }
 }
 

src/libcore/slice.rs

@@ -665,14 +665,14 @@ macro_rules! iterator {
             #[inline]
             fn next(&mut self) -> Option<$elem> {
                 // could be implemented with slices, but this avoids bounds checks
-                if self.ptr == self.end {
-                    None
-                } else {
-                    unsafe {
-                        if mem::size_of::<T>() != 0 {
-                            ::intrinsics::assume(!self.ptr.is_null());
-                            ::intrinsics::assume(!self.end.is_null());
-                        }
+                unsafe {
+                    if mem::size_of::<T>() != 0 {
+                        assume(!self.ptr.is_null());
+                        assume(!self.end.is_null());
+                    }
+                    if self.ptr == self.end {
+                        None
+                    } else {
                         let old = self.ptr;
                         self.ptr = slice_offset!(self.ptr, 1);
                         Some(slice_ref!(old))
@@ -710,15 +710,15 @@ macro_rules! iterator {
             #[inline]
             fn next_back(&mut self) -> Option<$elem> {
                 // could be implemented with slices, but this avoids bounds checks
-                if self.end == self.ptr {
-                    None
-                } else {
-                    unsafe {
+                unsafe {
+                    if mem::size_of::<T>() != 0 {
+                        assume(!self.ptr.is_null());
+                        assume(!self.end.is_null());
+                    }
+                    if self.end == self.ptr {
+                        None
+                    } else {
                         self.end = slice_offset!(self.end, -1);
-                        if mem::size_of::<T>() != 0 {
-                            ::intrinsics::assume(!self.ptr.is_null());
-                            ::intrinsics::assume(!self.end.is_null());
-                        }
                         Some(slice_ref!(self.end))
                     }
                 }