---

yaml
---
r: 234753
b: refs/heads/tmp
c: 8aef16c
h: refs/heads/master
i:
  234751: ab616c5
v: v3

Author: Manishearth

[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: 8f8fe8194d108ad7094a286bb4db5169656835c2
+refs/heads/tmp: 8aef16c2a5c175f7b4359122d7409765b09d6bf5
 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

@@ -1,6 +1,6 @@
 # Compiler Test Documentation
 
-In the Rust project, we use a special set of comands embedded in
+In the Rust project, we use a special set of comands imbedded in
 comments to test the Rust compiler. There are two groups of commands:
 
 1. Header commands
@@ -29,11 +29,11 @@ The error levels that you can have are:
 3. `NOTE`
 4. `HELP` and `SUGGESTION`*
 
-\* **Note**: `SUGGESTION` must follow immediately after `HELP`.
+\* **Note**: `SUGGESTION` must follow emediatly after `HELP`.
 
 ## Summary of Header Commands
 
-Header commands specify something about the entire test file as a
+Header commands specify something about the entire test file, as a
 whole, instead of just a few lines inside the test.
 
 * `ignore-X` where `X` is an architecture, OS or stage will ignore the test accordingly

branches/tmp/Makefile.in

@@ -26,7 +26,7 @@
 #
 #   * check - Run the complete test suite
 #
-#   * clean - Clean the build repository. It is advised to run this
+#   * clean - Clean the build repertory. It is advised to run this
 #             command if you want to build Rust again, after an update
 #             of the git repository.
 #

branches/tmp/RELEASES.md

@@ -1,4 +1,4 @@
-Version 1.3.0 (2015-09-17)
+Version 1.3.0 (September 2015)
 ==============================
 
 * ~900 changes, numerous bugfixes

branches/tmp/configure

@@ -1095,12 +1095,6 @@ envopt CPP
 envopt CFLAGS
 envopt CXXFLAGS
 
-# stdc++ name in use
-# used to manage non-standard name (on OpenBSD for example)
-program_transform_name=$($CFG_CC -v 2>&1 | sed -n "s/.*--program-transform-name='\([^']*\)'.*/\1/p")
-CFG_STDCPP_NAME=$(echo "stdc++" | sed "${program_transform_name}")
-putvar CFG_STDCPP_NAME
-
 # a little post-processing of various config values
 CFG_PREFIX=${CFG_PREFIX%/}
 CFG_MANDIR=${CFG_MANDIR%/}

branches/tmp/mk/dist.mk

@@ -77,7 +77,6 @@ $(PKG_TAR): $(PKG_FILES)
          -C $(S) \
          --exclude-vcs \
          --exclude=*~ \
-         --exclude=*.pyc \
          --exclude=*/llvm/test/*/*.ll \
          --exclude=*/llvm/test/*/*.td \
          --exclude=*/llvm/test/*/*.s \

branches/tmp/mk/llvm.mk

@@ -73,7 +73,7 @@ $$(LLVM_STAMP_$(1)): $(S)src/rustllvm/llvm-auto-clean-trigger
 
 ifeq ($$(CFG_ENABLE_LLVM_STATIC_STDCPP),1)
 LLVM_STDCPP_RUSTFLAGS_$(1) = -L "$$(dir $$(shell $$(CC_$(1)) $$(CFG_GCCISH_CFLAGS_$(1)) \
-					-print-file-name=lib$(CFG_STDCPP_NAME).a))"
+					-print-file-name=libstdc++.a))"
 else
 LLVM_STDCPP_RUSTFLAGS_$(1) =
 endif
@@ -83,7 +83,7 @@ endif
 LLVM_LINKAGE_PATH_$(1):=$$(abspath $$(RT_OUTPUT_DIR_$(1))/llvmdeps.rs)
 $$(LLVM_LINKAGE_PATH_$(1)): $(S)src/etc/mklldeps.py $$(LLVM_CONFIG_$(1))
 	$(Q)$(CFG_PYTHON) "$$<" "$$@" "$$(LLVM_COMPONENTS)" "$$(CFG_ENABLE_LLVM_STATIC_STDCPP)" \
-		$$(LLVM_CONFIG_$(1)) "$(CFG_STDCPP_NAME)"
+		$$(LLVM_CONFIG_$(1))
 endef
 
 $(foreach host,$(CFG_HOST), \

branches/tmp/src/doc/trpl/choosing-your-guarantees.md

@@ -321,7 +321,7 @@ there's a lot of concurrent access happening.
 
 # Composition
 
-A common gripe when reading Rust code is with types like `Rc<RefCell<Vec<T>>>` (or even more
+A common gripe when reading Rust code is with types like `Rc<RefCell<Vec<T>>>` (or even more more
 complicated compositions of such types). It's not always clear what the composition does, or why the
 author chose one like this (and when one should be using such a composition in one's own code)
 

branches/tmp/src/doc/trpl/concurrency.md

@@ -26,8 +26,8 @@ to help us make sense of code that can possibly be concurrent.
 ### `Send`
 
 The first trait we're going to talk about is
-[`Send`](../std/marker/trait.Send.html). When a type `T` implements `Send`, it
-indicates that something of this type is able to have ownership transferred
+[`Send`](../std/marker/trait.Send.html). When a type `T` implements `Send`, it indicates
+to the compiler that something of this type is able to have ownership transferred
 safely between threads.
 
 This is important to enforce certain restrictions. For example, if we have a
@@ -42,19 +42,13 @@ us enforce that it can't leave the current thread.
 ### `Sync`
 
 The second of these traits is called [`Sync`](../std/marker/trait.Sync.html).
-When a type `T` implements `Sync`, it indicates that something
+When a type `T` implements `Sync`, it indicates to the compiler that something
 of this type has no possibility of introducing memory unsafety when used from
-multiple threads concurrently through shared references. This implies that
-types which don't have [interior mutability](mutability.html) are inherently
-`Sync`, which includes simple primitive types (like `u8`) and aggregate types
-containing them.
-
-For sharing references across threads, Rust provides a wrapper type called
-`Arc<T>`. `Arc<T>` implements `Send` and `Sync` if and only if `T` implements
-both `Send` and `Sync`. For example, an object of type `Arc<RefCell<U>>` cannot
-be transferred across threads because
-[`RefCell`](choosing-your-guarantees.html#refcell%3Ct%3E) does not implement
-`Sync`, consequently `Arc<RefCell<U>>` would not implement `Send`.
+multiple threads concurrently.
+
+For example, sharing immutable data with an atomic reference count is
+threadsafe. Rust provides a type like this, `Arc<T>`, and it implements `Sync`,
+so it is safe to share between threads.
 
 These two traits allow you to use the type system to make strong guarantees
 about the properties of your code under concurrency. Before we demonstrate
@@ -76,7 +70,7 @@ fn main() {
 }
 ```
 
-The `thread::spawn()` method accepts a [closure](closures.html), which is executed in a
+The `thread::spawn()` method accepts a closure, which is executed in a
 new thread. It returns a handle to the thread, that can be used to
 wait for the child thread to finish and extract its result:
 
@@ -221,18 +215,29 @@ fn main() {
 }
 ```
 
-Note that the value of `i` is bound (copied) to the closure and not shared
-among the threads.
 
-Also note that [`lock`](../std/sync/struct.Mutex.html#method.lock) method of
-[`Mutex`](../std/sync/struct.Mutex.html) has this signature:
+If we'd tried to use `Mutex<T>` without wrapping it in an `Arc<T>` we would have
+seen another error like:
+
+```text
+error: the trait `core::marker::Send` is not implemented for the type `std::sync::mutex::MutexGuard<'_, collections::vec::Vec<u32>>` [E0277]
+ thread::spawn(move || {
+                  ^~~~~~~~~~~~~
+note: `std::sync::mutex::MutexGuard<'_, collections::vec::Vec<u32>>` cannot be sent between threads safely
+ thread::spawn(move || {
+                  ^~~~~~~~~~~~~
+```
+
+You see, [`Mutex`](../std/sync/struct.Mutex.html) has a
+[`lock`](../std/sync/struct.Mutex.html#method.lock)
+method which has this signature:
 
 ```ignore
 fn lock(&self) -> LockResult<MutexGuard<T>>
 ```
 
-and because `Send` is not implemented for `MutexGuard<T>`, the guard cannot
-cross thread boundaries, ensuring thread-locality of lock acquire and release.
+and because `Send` is not implemented for `MutexGuard<T>`, we couldn't have
+transferred the guard across thread boundaries on it's own.
 
 Let's examine the body of the thread more closely:
 
@@ -312,24 +317,22 @@ use std::sync::mpsc;
 fn main() {
     let (tx, rx) = mpsc::channel();
 
-    for i in 0..10 {
+    for _ in 0..10 {
         let tx = tx.clone();
 
         thread::spawn(move || {
-            let answer = i * i;
+            let answer = 42;
 
             tx.send(answer);
         });
     }
 
-    for _ in 0..10 {
-        println!("{}", rx.recv().unwrap());
-    }
+   rx.recv().ok().expect("Could not receive answer");
 }
 ```
 
-Here we create 10 threads, asking each to calculate the square of a number (`i`
-at the time of `spawn()`), and then `send()` back the answer over the channel.
+A `u32` is `Send` because we can make a copy. So we create a thread, ask it to calculate
+the answer, and then it `send()`s us the answer over the channel.
 
 
 ## Panics

branches/tmp/src/doc/trpl/error-handling.md

@@ -28,7 +28,7 @@ systems may want to jump around.
     * [The `Result` type](#the-result-type)
         * [Parsing integers](#parsing-integers)
         * [The `Result` type alias idiom](#the-result-type-alias-idiom)
-    * [A brief interlude: unwrapping isn't evil](#a-brief-interlude:-unwrapping-isn't-evil)
+    * [A brief interlude: unwrapping isn't evil](#a-brief-interlude-unwrapping-isnt-evil)
 * [Working with multiple error types](#working-with-multiple-error-types)
     * [Composing `Option` and `Result`](#composing-option-and-result)
     * [The limits of combinators](#the-limits-of-combinators)
@@ -41,11 +41,11 @@ systems may want to jump around.
     * [The real `try!` macro](#the-real-try!-macro)
     * [Composing custom error types](#composing-custom-error-types)
     * [Advice for library writers](#advice-for-library-writers)
-* [Case study: A program to read population data](#case-study:-a-program-to-read-population-data)
+* [Case study: A program to read population data](#case-study-a-program-to-read-population-data)
     * [Initial setup](#initial-setup)
     * [Argument parsing](#argument-parsing)
     * [Writing the logic](#writing-the-logic)
-    * [Error handling with `Box<Error>`](#error-handling-with-box%3Cerror%3E)
+    * [Error handling with `Box<Error>`](#error-handling-with-box<error>)
     * [Reading from stdin](#reading-from-stdin)
     * [Error handling with a custom type](#error-handling-with-a-custom-type)
     * [Adding functionality](#adding-functionality)
@@ -87,9 +87,9 @@ thread '<main>' panicked at 'Invalid number: 11', src/bin/panic-simple.rs:5
 Here's another example that is slightly less contrived. A program that accepts
 an integer as an argument, doubles it and prints it.
 
-<a name="code-unwrap-double"></a>
-
+<div id="code-unwrap-double">
 ```rust,should_panic
+
 use std::env;
 
 fn main() {
@@ -99,6 +99,7 @@ fn main() {
     println!("{}", 2 * n);
 }
 ```
+</div>
 
 If you give this program zero arguments (error 1) or if the first argument
 isn't an integer (error 2), the program will panic just like in the first
@@ -139,8 +140,7 @@ system is an important concept because it will cause the compiler to force the
 programmer to handle that absence. Let's take a look at an example that tries
 to find a character in a string:
 
-<a name="code-option-ex-string-find"></a>
-
+<div id="code-option-ex-string-find">
 ```rust
 // Searches `haystack` for the Unicode character `needle`. If one is found, the
 // byte offset of the character is returned. Otherwise, `None` is returned.
@@ -153,6 +153,7 @@ fn find(haystack: &str, needle: char) -> Option<usize> {
     None
 }
 ```
+</div>
 
 Notice that when this function finds a matching character, it doen't just
 return the `offset`. Instead, it returns `Some(offset)`. `Some` is a variant or
@@ -186,8 +187,6 @@ But wait, what about `unwrap` used in [`unwrap-double`](#code-unwrap-double)?
 There was no case analysis there! Instead, the case analysis was put inside the
 `unwrap` method for you. You could define it yourself if you want:
 
-<a name="code-option-def-unwrap"></a>
-
 ```rust
 enum Option<T> {
     None,
@@ -211,7 +210,7 @@ that makes `unwrap` ergonomic to use. Unfortunately, that `panic!` means that
 
 ### Composing `Option<T>` values
 
-In [`option-ex-string-find`](#code-option-ex-string-find)
+In [`option-ex-string-find`](#code-option-ex-string-find-2)
 we saw how to use `find` to discover the extension in a file name. Of course,
 not all file names have a `.` in them, so it's possible that the file name has
 no extension. This *possibility of absence* is encoded into the types using
@@ -253,8 +252,6 @@ option is `None`, in which case, just return `None`.
 Rust has parametric polymorphism, so it is very easy to define a combinator
 that abstracts this pattern:
 
-<a name="code-option-map"></a>
-
 ```rust
 fn map<F, T, A>(option: Option<T>, f: F) -> Option<A> where F: FnOnce(T) -> A {
     match option {
@@ -394,8 +391,6 @@ remove choices because they will panic if `Option<T>` is `None`.
 The `Result` type is also
 [defined in the standard library][6]:
 
-<a name="code-result-def-1"></a>
-
 ```rust
 enum Result<T, E> {
     Ok(T),
@@ -672,8 +667,6 @@ with both an `Option` and a `Result`, the solution is *usually* to convert the
 (from `env::args()`) means the user didn't invoke the program correctly. We
 could just use a `String` to describe the error. Let's try:
 
-<a name="code-error-double-string"></a>
-
 ```rust
 use std::env;
 
@@ -906,8 +899,6 @@ seen above.
 
 Here is a simplified definition of a `try!` macro:
 
-<a nama name="code-try-def-simple"></a>
-
 ```rust
 macro_rules! try {
     ($e:expr) => (match $e {
@@ -1168,8 +1159,6 @@ The `std::convert::From` trait is
 [defined in the standard
 library](../std/convert/trait.From.html):
 
-<a name="code-from-def"></a>
-
 ```rust
 trait From<T> {
     fn from(T) -> Self;
@@ -1247,11 +1236,9 @@ macro_rules! try {
 }
 ```
 
-This is not its real definition. Its real definition is
+This is not it's real definition. It's real definition is
 [in the standard library](../std/macro.try!.html):
 
-<a name="code-try-def"></a>
-
 ```rust
 macro_rules! try {
     ($e:expr) => (match $e {
@@ -1470,7 +1457,7 @@ representation. But certainly, this will vary depending on use cases.
 At a minimum, you should probably implement the
 [`Error`](../std/error/trait.Error.html)
 trait. This will give users of your library some minimum flexibility for
-[composing errors](#the-real-try!-macro). Implementing the `Error` trait also
+[composing errors](#the-real-try-macro). Implementing the `Error` trait also
 means that users are guaranteed the ability to obtain a string representation
 of an error (because it requires impls for both `fmt::Debug` and
 `fmt::Display`).

branches/tmp/src/doc/trpl/guessing-game.md

@@ -147,7 +147,7 @@ a few tricks up their sleeves.
 
 For example, they’re [immutable][immutable] by default. That’s why our example
 uses `mut`: it makes a binding mutable, rather than immutable. `let` doesn’t
-take a name on the left hand side of the assignment, it actually accepts a
+take a name on the left hand side, it actually accepts a
 ‘[pattern][patterns]’. We’ll use patterns later. It’s easy enough
 to use for now:
 

branches/tmp/src/etc/mklldeps.py

@@ -17,7 +17,6 @@
 components = sys.argv[2].split() # splits on whitespace
 enable_static = sys.argv[3]
 llvm_config = sys.argv[4]
-stdcpp_name = sys.argv[5]
 
 f.write("""// Copyright 2013 The Rust Project Developers. See the COPYRIGHT
 // file at the top-level directory of this distribution and at
@@ -78,15 +77,15 @@ def run(args):
 out = run([llvm_config, '--cxxflags'])
 if enable_static == '1':
     assert('stdlib=libc++' not in out)
-    f.write("#[link(name = \"" + stdcpp_name + "\", kind = \"static\")]\n")
+    f.write("#[link(name = \"stdc++\", kind = \"static\")]\n")
 else:
     # Note that we use `cfg_attr` here because on MSVC the C++ standard library
     # is not c++ or stdc++, but rather the linker takes care of linking the
     # right standard library.
     if 'stdlib=libc++' in out:
         f.write("#[cfg_attr(not(target_env = \"msvc\"), link(name = \"c++\"))]\n")
     else:
-        f.write("#[cfg_attr(not(target_env = \"msvc\"), link(name = \"" + stdcpp_name + "\"))]\n")
+        f.write("#[cfg_attr(not(target_env = \"msvc\"), link(name = \"stdc++\"))]\n")
 
 # Attach everything to an extern block
 f.write("extern {}\n")