Update text/3519-arbitrary-self-types-v2.md

Fix a link

Co-authored-by: Tyler Mandry <tmandry@gmail.com>

Author: adetaylor

text/3519-arbitrary-self-types-v2.md

@@ -349,7 +349,7 @@ The existing branches in the compiler for "arbitrary self types" already emit ex
   }
   ```
   We don't know a use-case for this. There are several cases where this can result in misleading diagnostics. (For instance, if such a method is called with an incorrect type (for example `smart_ptr.a::<&Foo>()` instead of `smart_ptr.a::<Foo>()`). We could attempt to find and fix all those cases. However, we feel that generic receiver types might risk subtle interactions with method resolutions and other parts of the language. We think it is a safer choice to generate an error on any declaration of a generic `self` type.
-- As noted in [#compiler-changes-deshadowing](the section about compiler changes for deshadowing) we will produce a "multiple method candidates" error if a method in an inner type is chosen in preference to a method in an outer type ("inner" = further along the `Receiver` chain) and the inner type is either `self: &T` or `self: &mut T` and we're choosing it in preference to `self: T` or `self: &T` in the outer type.
+- As noted in [the section about compiler changes for deshadowing](#compiler-changes-deshadowing) we will produce a "multiple method candidates" error if a method in an inner type is chosen in preference to a method in an outer type ("inner" = further along the `Receiver` chain) and the inner type is either `self: &T` or `self: &mut T` and we're choosing it in preference to `self: T` or `self: &T` in the outer type.
 
 # Drawbacks
 [drawbacks]: #drawbacks