---

yaml
---
r: 160957
b: refs/heads/auto
c: cd5c823
h: refs/heads/master
i:
  160955: 5fc7420
v: v3

Author: steveklabnik

[refs]

@@ -10,7 +10,7 @@ refs/tags/release-0.3: b5f0d0f648d9a6153664837026ba1be43d3e2503
 refs/tags/release-0.3.1: 495bae036dfe5ec6ceafd3312b4dca48741e845b
 refs/tags/release-0.4: e828ea2080499553b97dfe33b3f4d472b4562ad7
 refs/tags/release-0.5: 7e3bcfbf21278251ee936ad53e92e9b719702d73
-refs/heads/auto: 60541cdc1ec334b278740fd6d59b9d08929e6d0d
+refs/heads/auto: cd5c8235c5448a7234548c772468c8d2e8f150d9
 refs/heads/servo: af82457af293e2a842ba6b7759b70288da276167
 refs/tags/release-0.6: b4ebcfa1812664df5e142f0134a5faea3918544c
 refs/tags/0.1: b19db808c2793fe2976759b85a355c3ad8c8b336

branches/auto/configure

@@ -624,6 +624,7 @@ probe CFG_LD               ld
 probe CFG_VALGRIND         valgrind
 probe CFG_PERF             perf
 probe CFG_ISCC             iscc
+probe CFG_LLNEXTGEN        LLnextgen
 probe CFG_JAVAC            javac
 probe CFG_ANTLR4           antlr4
 probe CFG_GRUN             grun

branches/auto/mk/docs.mk

@@ -246,6 +246,26 @@ endef
 $(foreach lang,$(L10N_LANGS),$(eval $(call DEF_L10N_DOC,$(lang),guide)))
 
 
+######################################################################
+# LLnextgen (grammar analysis from refman)
+######################################################################
+
+ifeq ($(CFG_LLNEXTGEN),)
+  $(info cfg: no llnextgen found, omitting grammar-verification)
+else
+.PHONY: verify-grammar
+
+doc/rust.g: $(D)/rust.md $(S)src/etc/extract_grammar.py
+	@$(call E, extract_grammar: $@)
+	$(Q)$(CFG_PYTHON) $(S)src/etc/extract_grammar.py $< >$@
+
+verify-grammar: doc/rust.g
+	@$(call E, LLnextgen: $<)
+	$(Q)$(CFG_LLNEXTGEN) --generate-lexer-wrapper=no $< >$@
+	$(Q)rm -f doc/rust.c doc/rust.h
+endif
+
+
 ######################################################################
 # Rustdoc (libstd/extra)
 ######################################################################
@@ -279,8 +299,7 @@ $(2) += doc/$(1)/index.html
 doc/$(1)/index.html: CFG_COMPILER_HOST_TRIPLE = $(CFG_TARGET)
 doc/$(1)/index.html: $$(LIB_DOC_DEP_$(1)) doc/$(1)/
 	@$$(call E, rustdoc: $$@)
-	$$(Q)CFG_LLVM_LINKAGE_FILE=$$(LLVM_LINKAGE_PATH_$(CFG_BUILD)) \
-		$$(RUSTDOC) --cfg dox --cfg stage2 $$<
+	$$(Q)$$(RUSTDOC) --cfg dox --cfg stage2 $$<
 endef
 
 $(foreach crate,$(DOC_CRATES),$(eval $(call DEF_LIB_DOC,$(crate),DOC_TARGETS)))

branches/auto/mk/llvm.mk

@@ -49,12 +49,6 @@ else
 LLVM_STDCPP_LOCATION_$(1) =
 endif
 
-
-# LLVM linkage:
-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))
 endef
 
 $(foreach host,$(CFG_HOST), \
@@ -63,14 +57,10 @@ $(foreach host,$(CFG_HOST), \
 $(foreach host,$(CFG_HOST), \
  $(eval LLVM_CONFIGS := $(LLVM_CONFIGS) $(LLVM_CONFIG_$(host))))
 
-# This can't be done in target.mk because it's included before this file.
-define LLVM_LINKAGE_DEPS
-$$(TLIB$(1)_T_$(2)_H_$(3))/stamp.rustc_llvm: $$(LLVM_LINKAGE_PATH_$(3))
-endef
-
-$(foreach source,$(CFG_HOST), \
- $(foreach target,$(CFG_TARGET), \
-  $(eval $(call LLVM_LINKAGE_DEPS,0,$(target),$(source))) \
-  $(eval $(call LLVM_LINKAGE_DEPS,1,$(target),$(source))) \
-  $(eval $(call LLVM_LINKAGE_DEPS,2,$(target),$(source))) \
-  $(eval $(call LLVM_LINKAGE_DEPS,3,$(target),$(source)))))
+$(S)src/librustc_llvm/llvmdeps.rs: \
+		    $(LLVM_CONFIGS) \
+		    $(S)src/etc/mklldeps.py \
+		    $(MKFILE_DEPS)
+	$(Q)$(CFG_PYTHON) $(S)src/etc/mklldeps.py \
+		"$@" "$(LLVM_COMPONENTS)" "$(CFG_ENABLE_LLVM_STATIC_STDCPP)" \
+		$(LLVM_CONFIGS)

branches/auto/mk/target.mk

@@ -79,8 +79,7 @@ $$(TLIB$(1)_T_$(2)_H_$(3))/stamp.$(4): \
 	    $$(dir $$@)$$(call CFG_LIB_GLOB_$(2),$(4)))
 	$$(call REMOVE_ALL_OLD_GLOB_MATCHES, \
 	    $$(dir $$@)$$(call CFG_RLIB_GLOB,$(4)))
-	$(Q)CFG_LLVM_LINKAGE_FILE=$$(LLVM_LINKAGE_PATH_$(2)) \
-	    $$(subst @,,$$(STAGE$(1)_T_$(2)_H_$(3))) \
+	$$(STAGE$(1)_T_$(2)_H_$(3)) \
 		$$(RUST_LIB_FLAGS_ST$(1)) \
 		-L "$$(RT_OUTPUT_DIR_$(2))" \
 		-L "$$(LLVM_LIBDIR_$(2))" \
@@ -135,6 +134,8 @@ SNAPSHOT_RUSTC_POST_CLEANUP=$(HBIN0_H_$(CFG_BUILD))/rustc$(X_$(CFG_BUILD))
 
 define TARGET_HOST_RULES
 
+$$(TLIB$(1)_T_$(2)_H_$(3))/stamp.rustc_llvm: $(S)src/librustc_llvm/llvmdeps.rs
+
 $$(TBIN$(1)_T_$(2)_H_$(3))/:
 	mkdir -p $$@
 

branches/auto/mk/tests.mk

@@ -412,8 +412,7 @@ $(3)/stage$(1)/test/$(4)test-$(2)$$(X_$(2)): \
 		$$(CRATEFILE_$(4)) \
 		$$(TESTDEP_$(1)_$(2)_$(3)_$(4))
 	@$$(call E, rustc: $$@)
-	$(Q)CFG_LLVM_LINKAGE_FILE=$$(LLVM_LINKAGE_PATH_$(2)) \
-	    $$(subst @,,$$(STAGE$(1)_T_$(2)_H_$(3))) -o $$@ $$< --test \
+	$$(STAGE$(1)_T_$(2)_H_$(3)) -o $$@ $$< --test \
 		-L "$$(RT_OUTPUT_DIR_$(2))" \
 		-L "$$(LLVM_LIBDIR_$(2))" \
 		$$(RUSTFLAGS_$(4))
@@ -891,8 +890,7 @@ endif
 ifeq ($(2),$$(CFG_BUILD))
 $$(call TEST_OK_FILE,$(1),$(2),$(3),doc-crate-$(4)): $$(CRATEDOCTESTDEP_$(1)_$(2)_$(3)_$(4))
 	@$$(call E, run doc-crate-$(4) [$(2)])
-	$$(Q)CFG_LLVM_LINKAGE_FILE=$$(LLVM_LINKAGE_PATH_$(2)) \
-	    $$(RUSTDOC_$(1)_T_$(2)_H_$(3)) --test --cfg dox \
+	$$(Q)$$(RUSTDOC_$(1)_T_$(2)_H_$(3)) --test --cfg dox \
 	    	$$(CRATEFILE_$(4)) --test-args "$$(TESTARGS)" && touch $$@
 else
 $$(call TEST_OK_FILE,$(1),$(2),$(3),doc-crate-$(4)):

branches/auto/src/doc/complement-bugreport.md

@@ -2,7 +2,7 @@
 
 # I think I found a bug in the compiler!
 
-If you see this message: `error: internal compiler error: unexpected panic`,
+If you see this message: `error: internal compiler error: unexpected failure`,
 then you have definitely found a bug in the compiler. It's also possible that
 your code is not well-typed, but if you saw this message, it's still a bug in
 error reporting.

branches/auto/src/doc/guide-pointers.md

@@ -445,32 +445,11 @@ fn succ(x: &int) -> int { *x + 1 }
 to
 
 ```{rust}
-use std::rc::Rc;
-
 fn box_succ(x: Box<int>) -> int { *x + 1 }
 
-fn rc_succ(x: Rc<int>) -> int { *x + 1 }
-```
-
-Note that the caller of your function will have to modify their calls slightly:
-
-```{rust}
-use std::rc::Rc;
-
-fn succ(x: &int) -> int { *x + 1 }
-
-let ref_x = &5i;
-let box_x = box 5i;
-let rc_x  = Rc::new(5i);
-
-succ(ref_x);
-succ(&*box_x);
-succ(&*rc_x);
+fn rc_succ(x: std::rc::Rc<int>) -> int { *x + 1 }
 ```
 
-The initial `*` dereferences the pointer, and then `&` takes a reference to
-those contents.
-
 # Boxes
 
 `Box<T>` is Rust's 'boxed pointer' type. Boxes provide the simplest form of
@@ -593,7 +572,7 @@ fn add_one(x: &mut int) -> int {
 fn main() {
     let x = box 5i;
 
-    println!("{}", add_one(&*x)); // error: cannot borrow immutable dereference
+    println!("{}", add_one(&*x)); // error: cannot borrow immutable dereference 
                                   // of `&`-pointer as mutable
 }
 ```
@@ -721,9 +700,9 @@ This gives you flexibility without sacrificing performance.
 
 You may think that this gives us terrible performance: return a value and then
 immediately box it up ?! Isn't that the worst of both worlds? Rust is smarter
-than that. There is no copy in this code. `main` allocates enough room for the
-`box`, passes a pointer to that memory into `foo` as `x`, and then `foo` writes
-the value straight into that pointer. This writes the return value directly into
+than that. There is no copy in this code. main allocates enough room for the
+`box , passes a pointer to that memory into foo as x, and then foo writes the
+value straight into that pointer. This writes the return value directly into
 the allocated box.
 
 This is important enough that it bears repeating: pointers are not for

branches/auto/src/doc/guide.md

@@ -62,7 +62,7 @@ the easiest way to keep people updated while Rust is in its alpha state.
 
 Oh, we should also mention the officially supported platforms:
 
-* Windows (7, 8, Server 2008 R2)
+* Windows (7, 8, Server 2008 R2), x86 only
 * Linux (2.6.18 or later, various distributions), x86 and x86-64
 * OSX 10.7 (Lion) or greater, x86 and x86-64
 
@@ -378,15 +378,9 @@ of your time with Rust.
 The first thing we'll learn about are 'variable bindings.' They look like this:
 
 ```{rust}
-fn main() {
-    let x = 5i;
-}
+let x = 5i;
 ```
 
-Putting `fn main() {` in each example is a bit tedious, so we'll leave that out
-in the future. If you're following along, make sure to edit your `main()`
-function, rather than leaving it off. Otherwise, you'll get an error.
-
 In many languages, this is called a 'variable.' But Rust's variable bindings
 have a few tricks up their sleeves. Rust has a very powerful feature called
 'pattern matching' that we'll get into detail with later, but the left
@@ -689,7 +683,7 @@ fn main() {
 ```
 
 This is the simplest possible function declaration. As we mentioned before,
-`fn` says 'this is a function,' followed by the name, some parentheses because
+`fn` says 'this is a function,' followed by the name, some parenthesis because
 this function takes no arguments, and then some curly braces to indicate the
 body. Here's a function named `foo`:
 
@@ -890,7 +884,7 @@ Tuples are an ordered list of a fixed size. Like this:
 let x = (1i, "hello");
 ```
 
-The parentheses and commas form this two-length tuple. Here's the same code, but
+The parenthesis and commas form this two-length tuple. Here's the same code, but
 with the type annotated:
 
 ```rust
@@ -914,9 +908,9 @@ let (x, y, z) = (1i, 2i, 3i);
 println!("x is {}", x);
 ```
 
-Remember before when I said the left-hand side of a `let` statement was more
+Remember before when I said the left hand side of a `let` statement was more
 powerful than just assigning a binding? Here we are. We can put a pattern on
-the left-hand side of the `let`, and if it matches up to the right-hand side,
+the left hand side of the `let`, and if it matches up to the right hand side,
 we can assign multiple bindings at once. In this case, `let` 'destructures,'
 or 'breaks up,' the tuple, and assigns the bits to three bindings.
 
@@ -1459,9 +1453,9 @@ focus. Any time you have a data structure of variable size, things can get
 tricky, and strings are a re-sizable data structure. That said, Rust's strings
 also work differently than in some other systems languages, such as C.
 
-Let's dig into the details. A **string** is a sequence of Unicode scalar values
+Let's dig into the details. A **string** is a sequence of unicode scalar values
 encoded as a stream of UTF-8 bytes. All strings are guaranteed to be
-validly encoded UTF-8 sequences. Additionally, strings are not null-terminated
+validly-encoded UTF-8 sequences. Additionally, strings are not null-terminated
 and can contain null bytes.
 
 Rust has two main types of strings: `&str` and `String`.
@@ -3939,7 +3933,7 @@ match x {
 }
 ```
 
-Here, the `val` inside the `match` has type `int`. In other words, the left-hand
+Here, the `val` inside the `match` has type `int`. In other words, the left hand
 side of the pattern destructures the value. If we have `&5i`, then in `&val`, `val`
 would be `5i`.
 
@@ -3997,35 +3991,6 @@ match origin {
 }
 ```
 
-You can do this kind of match on any member, not just the first:
-
-```{rust}
-# #![allow(non_shorthand_field_patterns)]
-struct Point {
-    x: int,
-    y: int,
-}
-
-let origin = Point { x: 0i, y: 0i };
-
-match origin {
-    Point { y: y, .. } => println!("y is {}", y),
-}
-```
-
-If you want to match against a slice or array, you can use `[]`:
-
-```{rust}
-fn main() {
-    let v = vec!["match_this", "1"];
-
-    match v.as_slice() {
-        ["match_this", second] => println!("The second element is {}", second),
-        _ => {},
-    }
-}
-```
-
 Whew! That's a lot of different ways to match things, and they can all be
 mixed and matched, depending on what you're doing:
 
@@ -4716,7 +4681,7 @@ let x: Option<int> = Some(5i);
 
 In the type declaration, we say `Option<int>`. Note how similar this looks to
 `Option<T>`. So, in this particular `Option`, `T` has the value of `int`. On
-the right-hand side of the binding, we do make a `Some(T)`, where `T` is `5i`.
+the right hand side of the binding, we do make a `Some(T)`, where `T` is `5i`.
 Since that's an `int`, the two sides match, and Rust is happy. If they didn't
 match, we'd get an error:
 
@@ -5284,7 +5249,7 @@ immediately.
 
 ## Success and failure
 
-Tasks don't always succeed, they can also panic. A task that wishes to panic
+Tasks don't always succeed, they can also panic. A task that wishes to panic 
 can call the `panic!` macro, passing a message:
 
 ```{rust}