---

yaml
---
r: 234369
b: refs/heads/tmp
c: 2548e2e
h: refs/heads/master
i:
  234367: da2baf8
v: v3

Author: id4ho

[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: 6b36e921f4198f5afc1656db2d153f4f74a1fabe
+refs/heads/tmp: 2548e2ee58949667ccf27e1d842242ed21313b77
 refs/tags/1.0.0-alpha.2: 4c705f6bc559886632d3871b04f58aab093bfa2f
 refs/tags/homu-tmp: ab792abf1fcc28afbd315426213f6428da25c085
 refs/tags/1.0.0-beta: 8cbb92b53468ee2b0c2d3eeb8567005953d40828

branches/tmp/configure

@@ -1180,27 +1180,16 @@ do
             # MSVC requires cmake because that's how we're going to build LLVM
             probe_need CFG_CMAKE cmake
 
-            # There are three builds of cmake on windows: MSVC, MinGW and Cygwin
-            # The Cygwin build does not have generators for Visual Studio, so
-            # detect that here and error.
-            if ! "$CFG_CMAKE" --help | sed -n '/^Generators/,$p' | grep 'Visual Studio' > /dev/null
-            then
-                err "cmake does not support Visual Studio generators.\n\n \
-                     This is likely due to it being an msys/cygwin build of cmake, \
-                     rather than the required windows version, built using MinGW \
-                     or Visual Studio."
-            fi
-
             # Use the REG program to figure out where VS is installed
             # We need to figure out where cl.exe and link.exe are, so we do some
             # munging and some probing here. We also look for the default
             # INCLUDE and LIB variables for MSVC so we can set those in the
             # build system as well.
-            install=$(cmd //c reg QUERY \
+            install=$(reg QUERY \
                        'HKLM\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\14.0' \
                        -v InstallDir)
             if [ -z "$install" ]; then
-              install=$(cmd //c reg QUERY \
+              install=$(reg QUERY \
                          'HKLM\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\12.0' \
                          -v InstallDir)
             fi
@@ -1233,9 +1222,9 @@ do
             eval CFG_MSVC_LINK_$bits="\"$bindir/link.exe\""
 
             vcvarsall="${CFG_MSVC_ROOT}/VC/vcvarsall.bat"
-            include_path=$(cmd //V:ON //c "$vcvarsall" $msvc_part \& echo !INCLUDE!)
+            include_path=$(cmd /c "\"$vcvarsall\" $msvc_part && cmd /c echo %INCLUDE%")
             need_ok "failed to learn about MSVC's INCLUDE"
-            lib_path=$(cmd //V:ON //c "$vcvarsall" $msvc_part \& echo !LIB!)
+            lib_path=$(cmd /c "\"$vcvarsall\" $msvc_part && cmd /c echo %LIB%")
             need_ok "failed to learn about MSVC's LIB"
 
             eval CFG_MSVC_INCLUDE_PATH_${bits}="\"$include_path\""

branches/tmp/mk/rt.mk

@@ -259,10 +259,8 @@ BACKTRACE_NAME_$(1) := $$(call CFG_STATIC_LIB_NAME_$(1),backtrace)
 BACKTRACE_LIB_$(1) := $$(RT_OUTPUT_DIR_$(1))/$$(BACKTRACE_NAME_$(1))
 BACKTRACE_BUILD_DIR_$(1) := $$(RT_OUTPUT_DIR_$(1))/libbacktrace
 
-# We don't use this on platforms that aren't linux-based (with the exception of
-# msys2/mingw builds on windows, which use it to read the dwarf debug
-# information) so just make the file available, the compilation of libstd won't
-# actually build it.
+# We don't use this on platforms that aren't linux-based, so just make the file
+# available, the compilation of libstd won't actually build it.
 ifeq ($$(findstring darwin,$$(OSTYPE_$(1))),darwin)
 # See comment above
 $$(BACKTRACE_LIB_$(1)):
@@ -275,7 +273,7 @@ $$(BACKTRACE_LIB_$(1)):
 	touch $$@
 else
 
-ifeq ($$(findstring msvc,$(1)),msvc)
+ifeq ($$(CFG_WINDOWSY_$(1)),1)
 # See comment above
 $$(BACKTRACE_LIB_$(1)):
 	touch $$@
@@ -298,25 +296,16 @@ endif
 # ./configure script. This is done to force libbacktrace to *not* use the
 # atomic/sync functionality because it pulls in unnecessary dependencies and we
 # never use it anyway.
-#
-# We also use `env PWD=` to clear the PWD environment variable, and then
-# execute the command in a new shell. This is necessary to workaround a
-# buildbot/msys2 bug: the shell is launched with PWD set to a windows-style path,
-# which results in all further uses of `pwd` also printing a windows-style path,
-# which breaks libbacktrace's configure script. Clearing PWD within the same
-# shell is not sufficient.
-
 $$(BACKTRACE_BUILD_DIR_$(1))/Makefile: $$(BACKTRACE_DEPS) $$(MKFILE_DEPS)
 	@$$(call E, configure: libbacktrace for $(1))
 	$$(Q)rm -rf $$(BACKTRACE_BUILD_DIR_$(1))
 	$$(Q)mkdir -p $$(BACKTRACE_BUILD_DIR_$(1))
-	$$(Q)(cd $$(BACKTRACE_BUILD_DIR_$(1)) && env \
-	      PWD= \
+	$$(Q)(cd $$(BACKTRACE_BUILD_DIR_$(1)) && \
 	      CC="$$(CC_$(1))" \
 	      AR="$$(AR_$(1))" \
 	      RANLIB="$$(AR_$(1)) s" \
 	      CFLAGS="$$(CFG_GCCISH_CFLAGS_$(1):-Werror=) -fno-stack-protector" \
-	      $(S)src/libbacktrace/configure --build=$(CFG_GNU_TRIPLE_$(CFG_BUILD)) --host=$(CFG_GNU_TRIPLE_$(1)))
+	      $(S)src/libbacktrace/configure --target=$(1) --host=$(CFG_BUILD))
 	$$(Q)echo '#undef HAVE_ATOMIC_FUNCTIONS' >> \
 	      $$(BACKTRACE_BUILD_DIR_$(1))/config.h
 	$$(Q)echo '#undef HAVE_SYNC_FUNCTIONS' >> \
@@ -328,7 +317,7 @@ $$(BACKTRACE_LIB_$(1)): $$(BACKTRACE_BUILD_DIR_$(1))/Makefile $$(MKFILE_DEPS)
 		INCDIR=$(S)src/libbacktrace
 	$$(Q)cp $$(BACKTRACE_BUILD_DIR_$(1))/.libs/libbacktrace.a $$@
 
-endif # endif for msvc
+endif # endif for windowsy
 endif # endif for ios
 endif # endif for darwin
 

branches/tmp/src/doc/grammar.md

@@ -281,7 +281,7 @@ type_path_tail : '<' type_expr [ ',' type_expr ] + '>'
 ## Macros
 
 ```antlr
-expr_macro_rules : "macro_rules" '!' ident '(' macro_rule * ')' ';'
+expr_macro_rules : "macro_rules" '!' ident '(' macro_rule * ')' ';' 
                  | "macro_rules" '!' ident '{' macro_rule * '}' ;
 macro_rule : '(' matcher * ')' "=>" '(' transcriber * ')' ';' ;
 matcher : '(' matcher * ')' | '[' matcher * ']'
@@ -306,7 +306,7 @@ transcriber : '(' transcriber * ')' | '[' transcriber * ']'
 
 ```antlr
 item : vis ? mod_item | fn_item | type_item | struct_item | enum_item
-     | const_item | static_item | trait_item | impl_item | extern_block_item ;
+     | const_item | static_item | trait_item | impl_item | extern_block ;
 ```
 
 ### Type Parameters
@@ -636,31 +636,31 @@ lambda_expr : '|' ident_list '|' expr ;
 ### While loops
 
 ```antlr
-while_expr : [ lifetime ':' ] ? "while" no_struct_literal_expr '{' block '}' ;
+while_expr : [ lifetime ':' ] "while" no_struct_literal_expr '{' block '}' ;
 ```
 
 ### Infinite loops
 
 ```antlr
-loop_expr : [ lifetime ':' ] ? "loop" '{' block '}';
+loop_expr : [ lifetime ':' ] "loop" '{' block '}';
 ```
 
 ### Break expressions
 
 ```antlr
-break_expr : "break" [ lifetime ] ?;
+break_expr : "break" [ lifetime ];
 ```
 
 ### Continue expressions
 
 ```antlr
-continue_expr : "continue" [ lifetime ] ?;
+continue_expr : "continue" [ lifetime ];
 ```
 
 ### For expressions
 
 ```antlr
-for_expr : [ lifetime ':' ] ? "for" pat "in" no_struct_literal_expr '{' block '}' ;
+for_expr : [ lifetime ':' ] "for" pat "in" no_struct_literal_expr '{' block '}' ;
 ```
 
 ### If expressions
@@ -688,12 +688,13 @@ match_pat : pat [ '|' pat ] * [ "if" expr ] ? ;
 ```antlr
 if_let_expr : "if" "let" pat '=' expr '{' block '}'
                else_tail ? ;
+else_tail : "else" [ if_expr | if_let_expr | '{' block '}' ] ;
 ```
 
 ### While let loops
 
 ```antlr
-while_let_expr : [ lifetime ':' ] ? "while" "let" pat '=' expr '{' block '}' ;
+while_let_expr : "while" "let" pat '=' expr '{' block '}' ;
 ```
 
 ### Return expressions
@@ -753,6 +754,8 @@ return_expr : "return" expr ? ;
 ```antlr
 closure_type := [ 'unsafe' ] [ '<' lifetime-list '>' ] '|' arg-list '|'
                 [ ':' bound-list ] [ '->' type ]
+procedure_type := 'proc' [ '<' lifetime-list '>' ] '(' arg-list ')'
+                  [ ':' bound-list ] [ '->' type ]
 lifetime-list := lifetime | lifetime ',' lifetime-list
 arg-list := ident ':' type | ident ':' type ',' arg-list
 bound-list := bound | bound '+' bound-list

branches/tmp/src/doc/reference.md

@@ -3200,6 +3200,16 @@ let z = match x { &0 => "zero", _ => "some" };
 assert_eq!(y, z);
 ```
 
+A pattern that's just an identifier, like `Nil` in the previous example, could
+either refer to an enum variant that's in scope, or bind a new variable. The
+compiler resolves this ambiguity by forbidding variable bindings that occur in
+`match` patterns from shadowing names of variants that are in scope. For
+example, wherever `List` is in scope, a `match` pattern would not be able to
+bind `Nil` as a new name. The compiler interprets a variable pattern `x` as a
+binding _only_ if there is no variant named `x` in scope. A convention you can
+use to avoid conflicts is simply to name variants with upper-case letters, and
+local variables with lower-case letters.
+
 Multiple match patterns may be joined with the `|` operator. A range of values
 may be specified with `...`. For example:
 

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

@@ -1,6 +1,6 @@
 % Choosing your Guarantees
 
-One important feature of Rust is that it lets us control the costs and guarantees
+One important feature of Rust as language is that it lets us control the costs and guarantees
 of a program.
 
 There are various “wrapper type” abstractions in the Rust standard library which embody
@@ -18,9 +18,9 @@ Before proceeding, it is highly recommended that one reads about [ownership][own
 
 ## `Box<T>`
 
-[`Box<T>`][box] is an &ldquo;owned&rdquo; pointer, or a &ldquo;box&rdquo;. While it can hand
-out references to the contained data, it is the only owner of the data. In particular, consider
-the following:
+[`Box<T>`][box] is pointer which is &ldquo;owned&rdquo;, or a &ldquo;box&rdquo;. While it can hand
+out references to the contained data, it is the only owner of the data. In particular, when
+something like the following occurs:
 
 ```rust
 let x = Box::new(1);
@@ -40,7 +40,7 @@ allowed to share references to this by the regular borrowing rules, checked at c
 
 [box]: ../std/boxed/struct.Box.html
 
-## `&T` and `&mut T`
+## `&T` and `&mut T` 
 
 These are immutable and mutable references respectively. They follow the &ldquo;read-write lock&rdquo;
 pattern, such that one may either have only one mutable reference to some data, or any number of
@@ -243,7 +243,7 @@ Many of the types above cannot be used in a threadsafe manner. Particularly, `Rc
 `RefCell<T>`, which both use non-atomic reference counts (_atomic_ reference counts are those which
 can be incremented from multiple threads without causing a data race), cannot be used this way. This
 makes them cheaper to use, but we need thread safe versions of these too. They exist, in the form of
-`Arc<T>` and `Mutex<T>`/`RwLock<T>`
+`Arc<T>` and `Mutex<T>`/`RWLock<T>`
 
 Note that the non-threadsafe types _cannot_ be sent between threads, and this is checked at compile
 time.

branches/tmp/src/doc/trpl/deref-coercions.md

@@ -89,8 +89,8 @@ Vectors can `Deref` to a slice.
 
 ## Deref and method calls
 
-`Deref` will also kick in when calling a method. Consider the following
-example.
+`Deref` will also kick in when calling a method. In other words, these are
+the same two things in Rust:
 
 ```rust
 struct Foo;
@@ -99,13 +99,13 @@ impl Foo {
     fn foo(&self) { println!("Foo"); }
 }
 
-let f = &&Foo;
+let f = Foo;
 
 f.foo();
 ```
 
-Even though `f` is a `&&Foo` and `foo` takes `&self`, this works. That’s
-because these things are the same:
+Even though `f` isn’t a reference, and `foo` takes `&self`, this works.
+That’s because these things are the same:
 
 ```rust,ignore
 f.foo();

branches/tmp/src/doc/trpl/method-syntax.md

@@ -7,7 +7,7 @@ can be awkward. Consider this code:
 baz(bar(foo));
 ```
 
-We would read this left-to right, and so we see ‘baz bar foo’. But this isn’t the
+We would read this left-to-right, and so we see ‘baz bar foo’. But this isn’t the
 order that the functions would get called in, that’s inside-out: ‘foo bar baz’.
 Wouldn’t it be nice if we could do this instead?
 
@@ -45,17 +45,17 @@ This will print `12.566371`.
 
 
 
-We’ve made a struct that represents a circle. We then write an `impl` block,
+We’ve made a `struct` that represents a circle. We then write an `impl` block,
 and inside it, define a method, `area`.
 
-Methods take a  special first parameter, of which there are three variants:
+Methods take a special first parameter, of which there are three variants:
 `self`, `&self`, and `&mut self`. You can think of this first parameter as
 being the `foo` in `foo.bar()`. The three variants correspond to the three
 kinds of things `foo` could be: `self` if it’s just a value on the stack,
 `&self` if it’s a reference, and `&mut self` if it’s a mutable reference.
 Because we took the `&self` parameter to `area`, we can use it just like any
 other parameter. Because we know it’s a `Circle`, we can access the `radius`
-just like we would with any other struct. 
+just like we would with any other `struct`. 
 
 We should default to using `&self`, as you should prefer borrowing over taking
 ownership, as well as taking immutable references over mutable ones. Here’s an
@@ -120,12 +120,12 @@ Check the return type:
 ```rust
 # struct Circle;
 # impl Circle {
-fn grow(&self) -> Circle {
+fn grow(&self, increment: f64) -> Circle {
 # Circle } }
 ```
 
 We just say we’re returning a `Circle`. With this method, we can grow a new
-circle to any arbitrary size.
+`circle` to any arbitrary size.
 
 # Associated functions
 
@@ -161,7 +161,7 @@ methods’.
 
 # Builder Pattern
 
-Let’s say that we want our users to be able to create Circles, but we will
+Let’s say that we want our users to be able to create `Circle`s, but we will
 allow them to only set the properties they care about. Otherwise, the `x`
 and `y` attributes will be `0.0`, and the `radius` will be `1.0`. Rust doesn’t
 have method overloading, named arguments, or variable arguments. We employ
@@ -224,7 +224,7 @@ fn main() {
 }
 ```
 
-What we’ve done here is make another struct, `CircleBuilder`. We’ve defined our
+What we’ve done here is make another `struct`, `CircleBuilder`. We’ve defined our
 builder methods on it. We’ve also defined our `area()` method on `Circle`. We
 also made one more method on `CircleBuilder`: `finalize()`. This method creates
 our final `Circle` from the builder. Now, we’ve used the type system to enforce

branches/tmp/src/doc/trpl/the-stack-and-the-heap.md

@@ -38,7 +38,7 @@ local variables and some other information. This is called a ‘stack frame’,
 for the purpose of this tutorial, we’re going to ignore the extra information
 and just consider the local variables we’re allocating. So in this case, when
 `main()` is run, we’ll allocate a single 32-bit integer for our stack frame.
-This is automatically handled for you, as you can see; we didn’t have to write
+This is automatically handled for you, as you can see, we didn’t have to write
 any special Rust code or anything.
 
 When the function is over, its stack frame gets deallocated. This happens
@@ -51,7 +51,7 @@ we’ll throw them all away at the same time as well, we can get rid of it very
 fast too.
 
 The downside is that we can’t keep values around if we need them for longer
-than a single function. We also haven’t talked about what the word, ‘stack’,
+than a single function. We also haven’t talked about what that name, ‘stack’
 means. To do that, we need a slightly more complicated example:
 
 ```rust