Nomicon: Fix Links

The style `[name][]` does not work with Pandoc, whereas `[name]` does.
I hope hoedown accepts this as well.

destructors.md

@@ -52,7 +52,7 @@ impl<T> Drop for Box<T> {
 ```
 
 and this works fine because when Rust goes to drop the `ptr` field it just sees
-a [Unique][] that has no actual `Drop` implementation. Similarly nothing can
+a [Unique] that has no actual `Drop` implementation. Similarly nothing can
 use-after-free the `ptr` because when drop exits, it becomes inacessible.
 
 However this wouldn't work:

meet-safe-and-unsafe.md

@@ -60,8 +60,8 @@ Unlike C, Undefined Behaviour is pretty limited in scope in Rust. All the core
 language cares about is preventing the following things:
 
 * Dereferencing null or dangling pointers
-* Reading [uninitialized memory][]
-* Breaking the [pointer aliasing rules][]
+* Reading [uninitialized memory]
+* Breaking the [pointer aliasing rules]
 * Producing invalid primitive values:
     * dangling/null references
     * a `bool` that isn't 0 or 1

other-reprs.md

@@ -26,7 +26,7 @@ still consumes a byte of space.
 * DSTs, tuples, and tagged unions are not a concept in C and as such are never
 FFI safe.
 
-* **If the type would have any [drop flags][], they will still be added**
+* **If the type would have any [drop flags], they will still be added**
 
 * This is equivalent to one of `repr(u*)` (see the next section) for enums. The
 chosen size is the default enum size for the target platform's C ABI. Note that

safe-unsafe-meaning.md

@@ -35,7 +35,7 @@ unchecked contracts:
 
 There is also `#[unsafe_no_drop_flag]`, which is a special case that exists for
 historical reasons and is in the process of being phased out. See the section on
-[drop flags][] for details.
+[drop flags] for details.
 
 Some examples of unsafe functions:
 
@@ -44,7 +44,7 @@ Some examples of unsafe functions:
 * `ptr::offset` is an intrinsic that invokes Undefined Behaviour 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)
+  bypassing type safety in arbitrary ways. (see [conversions] for details)
 * All FFI functions are `unsafe` because they can do arbitrary things.
   C being an obvious culprit, but generally any language can do something
   that Rust isn't happy about.

send-and-sync.md

@@ -10,7 +10,7 @@ captures this through the `Send` and `Sync` traits.
 
 Send and Sync are fundamental to Rust's concurrency story. As such, a
 substantial amount of special tooling exists to make them work right. First and
-foremost, they're [unsafe traits][]. This means that they are unsafe to
+foremost, they're [unsafe traits]. This means that they are unsafe to
 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

transmutes.md

@@ -21,7 +21,7 @@ same size. The ways to cause Undefined Behaviour with this are mind boggling.
     * No you can't do it
     * No you're not special
 * Transmuting to a reference without an explicitly provided lifetime
-  produces an [unbounded lifetime][]
+  produces an [unbounded lifetime]
 
 `mem::transmute_copy<T, U>` somehow manages to be *even more* wildly unsafe than
 this. It copies `size_of<U>` bytes out of an `&T` and interprets them as a `U`.