]> git.lizzy.rs Git - rust.git/commitdiff
Nomicon: Fix Links
authorPascal Hertleif <killercup@gmail.com>
Sat, 12 Sep 2015 10:13:24 +0000 (12:13 +0200)
committerPascal Hertleif <killercup@gmail.com>
Sat, 12 Sep 2015 10:13:24 +0000 (12:13 +0200)
The style `[name][]` does not work with Pandoc, whereas `[name]` does.
I hope hoedown accepts this as well.

src/doc/nomicon/destructors.md
src/doc/nomicon/meet-safe-and-unsafe.md
src/doc/nomicon/other-reprs.md
src/doc/nomicon/safe-unsafe-meaning.md
src/doc/nomicon/send-and-sync.md
src/doc/nomicon/transmutes.md

index 4492e2a92fae9e95aac56b0277e9b2a3626baa48..91abdab9778f2fc55a9ed9a72474f95334464599 100644 (file)
@@ -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:
index 15e49c747b81075f46b83c59b142db0b0928f274..52582e8750b4690daa82520ba8a3f3066bda496d 100644 (file)
@@ -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
index 93ef2c13cdf8c5de5b2ad459b9aa0cfc9313b786..71da743f35d3cbc92784c5001eb0a601931cef9c 100644 (file)
@@ -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
index e9037b56ff9d7a0bae0ab769a1e825c4bcc5ef5b..3cb02d31b175f5b526cefaea78c0413783fc9a5e 100644 (file)
@@ -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.
index 8724b97546ea118d5b14993e18144e088a4f429d..9ab60d03fca7e41a6b1555f67683f207a8ed899b 100644 (file)
@@ -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
index f19dda0d8b81fd948b54b36b1c5cb255192ad0e5..2b34ad0a9fad164baf630f7bde97df6bbd1e84b1 100644 (file)
@@ -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`.