---

yaml
---
r: 234527
b: refs/heads/tmp
c: 9ef62a4
h: refs/heads/master
i:
  234525: b1b3a1c
  234523: 0403237
  234519: 28a85a8
  234511: 572770d
  234495: 8354446
v: v3

Author: ranma42

[refs]

@@ -25,7 +25,7 @@ refs/tags/0.11.0: e1247cb1d0d681be034adb4b558b5a0c0d5720f9
 refs/tags/0.12.0: f0c419429ef30723ceaf6b42f9b5a2aeb5d2e2d1
 refs/heads/beta: d2e13e822a73e0ea46ae9e21afdd3155fc997f6d
 refs/tags/1.0.0-alpha: e42bd6d93a1d3433c486200587f8f9e12590a4d7
-refs/heads/tmp: f710aae2eff6a738caa5991e62267c3a5f70b1c9
+refs/heads/tmp: 9ef62a44903df9574b25ca0d04e3a648b6bb54cd
 refs/tags/1.0.0-alpha.2: 4c705f6bc559886632d3871b04f58aab093bfa2f
 refs/tags/homu-tmp: ab792abf1fcc28afbd315426213f6428da25c085
 refs/tags/1.0.0-beta: 8cbb92b53468ee2b0c2d3eeb8567005953d40828

branches/tmp/COMPILER_TESTS.md

@@ -10,7 +10,6 @@ links to the major sections:
 * [Writing Documentation](#writing-documentation)
 * [Issue Triage](#issue-triage)
 * [Out-of-tree Contributions](#out-of-tree-contributions)
-* [Helpful Links and Information](#helpful-links-and-information)
 
 If you have questions, please make a post on [internals.rust-lang.org][internals] or
 hop on [#rust-internals][pound-rust-internals].
@@ -211,26 +210,3 @@ valuable!
 [users]: https://users.rust-lang.org/
 [so]: http://stackoverflow.com/questions/tagged/rust
 [community-library]: https://github.com/rust-lang/rfcs/labels/A-community-library
-
-## Helpful Links and Information
-
-For people new to Rust, and just starting to contribute, or even for
-more seasoned developers, some useful places to look for information
-are:
-
-* The [Rust Internals forum][rif], a place to ask questions and
-  discuss Rust's internals
-* The [generated documentation for rust's compiler][gdfrustc]
-* The [rust referance][rr], even though it doesn't specifically talk about Rust's internals, its a great reasource nontheless
-* Although out of date, [Tom Lee's great blog article][tlgba] is very helpful
-* [rustaceans.org][ro] is helpful, but mostly dedicated to IRC
-* The [Rust Compiler Testing Docs][rctd]
-* **Google**!
-* Don't be afraid to ask! The Rust community is friendly and helpful.
-
-[gdfrustc]: http://manishearth.github.io/rust-internals-docs/rustc/
-[rif]: http://internals.rust-lang.org
-[rr]: https://doc.rust-lang.org/book/README.html
-[tlgba]: http://tomlee.co/2014/04/03/a-more-detailed-tour-of-the-rust-compiler/
-[ro]: http://www.rustaceans.org/
-[rctd]: ./COMPILER_TESTS.md

branches/tmp/CONTRIBUTING.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:

branches/tmp/src/doc/nomicon/destructors.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

branches/tmp/src/doc/nomicon/meet-safe-and-unsafe.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

branches/tmp/src/doc/nomicon/other-reprs.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.

branches/tmp/src/doc/nomicon/safe-unsafe-meaning.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

branches/tmp/src/doc/nomicon/send-and-sync.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`.