---

yaml
---
r: 232221
b: refs/heads/auto
c: e9d2587
h: refs/heads/master
i:
  232219: 2ed9103
v: v3

Author: bors

[refs]

@@ -8,7 +8,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: b44cb01bd73b32ffe046b4dcfa549a954d139ab2
+refs/heads/auto: e9d2587766a30d30491ec96dab5cc5d741ae043a
 refs/tags/release-0.6: b4ebcfa1812664df5e142f0134a5faea3918544c
 refs/tags/0.1: b19db808c2793fe2976759b85a355c3ad8c8b336
 refs/tags/0.2: 1754d02027f2924bed83b0160ee340c7f41d5ea1

branches/auto/COMPILER_TESTS.md

@@ -1,6 +1,6 @@
 # Compiler Test Documentation
 
-In the Rust project, we use a special set of comands imbedded in
+In the Rust project, we use a special set of comands embedded 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 emediatly after `HELP`.
+\* **Note**: `SUGGESTION` must follow immediately 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/auto/Makefile.in

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

branches/auto/RELEASES.md

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

branches/auto/configure

@@ -1095,6 +1095,12 @@ 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/auto/mk/dist.mk

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

branches/auto/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=libstdc++.a))"
+					-print-file-name=lib$(CFG_STDCPP_NAME).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))
+		$$(LLVM_CONFIG_$(1)) "$(CFG_STDCPP_NAME)"
 endef
 
 $(foreach host,$(CFG_HOST), \

branches/auto/mk/platform.mk

@@ -208,6 +208,14 @@ define CFG_MAKE_TOOLCHAIN
 
   ifeq ($$(findstring $(HOST_$(1)),arm aarch64 mips mipsel powerpc),)
 
+  # On OpenBSD, we need to pass the path of libstdc++.so to the linker
+  # (use path of libstdc++.a which is a known name for the same path)
+  ifeq ($(OSTYPE_$(1)),unknown-openbsd)
+    RUSTC_FLAGS_$(1)=-L "$$(dir $$(shell $$(CC_$(1)) $$(CFG_GCCISH_CFLAGS_$(1)) \
+        -print-file-name=lib$(CFG_STDCPP_NAME).a))" \
+        $(RUSTC_FLAGS_$(1))
+  endif
+
   # On Bitrig, we need the relocation model to be PIC for everything
   ifeq (,$(filter $(OSTYPE_$(1)),bitrig))
     LLVM_MC_RELOCATION_MODEL="pic"

branches/auto/mk/tests.mk

@@ -1046,6 +1046,10 @@ $$(call TEST_OK_FILE,$(1),$(2),$(3),rmake): \
 		$$(RMAKE_TESTS:%=$(3)/test/run-make/%-$(1)-T-$(2)-H-$(3).ok)
 	@touch $$@
 
+$(3)/test/run-make/%-$(1)-T-$(2)-H-$(3).ok: \
+	export INCLUDE := $$(CFG_MSVC_INCLUDE_PATH_$$(HOST_$(3)))
+$(3)/test/run-make/%-$(1)-T-$(2)-H-$(3).ok: \
+	export LIB := $$(CFG_MSVC_LIB_PATH_$$(HOST_$(3)))
 $(3)/test/run-make/%-$(1)-T-$(2)-H-$(3).ok: \
 		$(S)src/test/run-make/%/Makefile \
 		$$(CSREQ$(1)_T_$(2)_H_$(3))
@@ -1056,15 +1060,16 @@ $(3)/test/run-make/%-$(1)-T-$(2)-H-$(3).ok: \
         $$(MAKE) \
 	    $$(HBIN$(1)_H_$(3))/rustc$$(X_$(3)) \
 	    $(3)/test/run-make/$$* \
-	    $$(CC_$(3)) \
+	    '$$(CC_$(3))' \
 	    "$$(CFG_GCCISH_CFLAGS_$(3))" \
 	    $$(HBIN$(1)_H_$(3))/rustdoc$$(X_$(3)) \
 	    "$$(TESTNAME)" \
 	    $$(LD_LIBRARY_PATH_ENV_NAME$(1)_T_$(2)_H_$(3)) \
 	    "$$(LD_LIBRARY_PATH_ENV_HOSTDIR$(1)_T_$(2)_H_$(3))" \
 	    "$$(LD_LIBRARY_PATH_ENV_TARGETDIR$(1)_T_$(2)_H_$(3))" \
 	    $(1) \
-	    $$(S)
+	    $$(S) \
+	    $(3)
 	@touch -r [email protected]_time $$@ && rm [email protected]_time
 else
 # FIXME #11094 - The above rule doesn't work right for multiple targets

branches/auto/src/doc/complement-project-faq.md

@@ -22,7 +22,7 @@ Existing languages at this level of abstraction and efficiency are unsatisfactor
 
 # Is any part of this thing production-ready?
 
-No. Feel free to play around, but don't expect completeness or stability yet. Expect incompleteness and breakage.
+Yes!
 
 # Is this a completely Mozilla-planned and orchestrated thing?
 

branches/auto/src/doc/reference.md

@@ -1178,11 +1178,22 @@ let px: i32 = match p { Point(x, _) => x };
 ```
 
 A _unit-like struct_ is a structure without any fields, defined by leaving off
-the list of fields entirely. Such types will have a single value. For example:
+the list of fields entirely. Such a structure implicitly defines a constant of
+its type with the same name. For example:
 
 ```
+# #![feature(braced_empty_structs)]
 struct Cookie;
-let c = [Cookie, Cookie, Cookie, Cookie];
+let c = [Cookie, Cookie {}, Cookie, Cookie {}];
+```
+
+is equivalent to
+
+```
+# #![feature(braced_empty_structs)]
+struct Cookie {}
+const Cookie: Cookie = Cookie {};
+let c = [Cookie, Cookie {}, Cookie, Cookie {}];
 ```
 
 The precise memory layout of a structure is not specified. One can specify a
@@ -2411,6 +2422,7 @@ The currently implemented features of the reference compiler are:
                               terms of encapsulation).
 * - `default_type_parameter_fallback` - Allows type parameter defaults to
                                         influence type inference.
+* - `braced_empty_structs` - Allows use of empty structs with braces.
 
 If a feature is promoted to a language feature, then all existing programs will
 start to receive compilation warnings about `#![feature]` directives which enabled
@@ -2762,7 +2774,7 @@ The following expressions are equivalent.
 let x = std::ops::Range {start: 0, end: 10};
 let y = 0..10;
 
-assert_eq!(x,y);
+assert_eq!(x, y);
 ```
 
 ### Unary operator expressions
@@ -3035,18 +3047,18 @@ A `loop` expression may optionally have a _label_. The label is written as
 a lifetime preceding the loop expression, as in `'foo: loop{ }`. If a
 label is present, then labeled `break` and `continue` expressions nested
 within this loop may exit out of this loop or return control to its head.
-See [Break expressions](#break-expressions) and [Continue
+See [break expressions](#break-expressions) and [continue
 expressions](#continue-expressions).
 
-### Break expressions
+### `break` expressions
 
 A `break` expression has an optional _label_. If the label is absent, then
 executing a `break` expression immediately terminates the innermost loop
 enclosing it. It is only permitted in the body of a loop. If the label is
 present, then `break 'foo` terminates the loop with label `'foo`, which need not
 be the innermost label enclosing the `break` expression, but must enclose it.
 
-### Continue expressions
+### `continue` expressions
 
 A `continue` expression has an optional _label_. If the label is absent, then
 executing a `continue` expression immediately terminates the current iteration
@@ -3059,7 +3071,7 @@ innermost label enclosing the `break` expression, but must enclose it.
 
 A `continue` expression is only permitted in the body of a loop.
 
-### While loops
+### `while` loops
 
 A `while` loop begins by evaluating the boolean loop conditional expression.
 If the loop conditional expression evaluates to `true`, the loop body block
@@ -3082,12 +3094,12 @@ Like `loop` expressions, `while` loops can be controlled with `break` or
 loops](#infinite-loops), [break expressions](#break-expressions), and
 [continue expressions](#continue-expressions) for more information.
 
-### For expressions
+### `for` expressions
 
 A `for` expression is a syntactic construct for looping over elements provided
 by an implementation of `std::iter::IntoIterator`.
 
-An example of a for loop over the contents of an array:
+An example of a `for` loop over the contents of an array:
 
 ```
 # type Foo = i32;
@@ -3117,7 +3129,7 @@ Like `loop` expressions, `for` loops can be controlled with `break` or
 loops](#infinite-loops), [break expressions](#break-expressions), and
 [continue expressions](#continue-expressions) for more information.
 
-### If expressions
+### `if` expressions
 
 An `if` expression is a conditional branch in program control. The form of an
 `if` expression is a condition expression, followed by a consequent block, any
@@ -3129,7 +3141,7 @@ evaluates to `false`, the consequent block is skipped and any subsequent `else
 if` condition is evaluated. If all `if` and `else if` conditions evaluate to
 `false` then any `else` block is executed.
 
-### Match expressions
+### `match` expressions
 
 A `match` expression branches on a *pattern*. The exact form of matching that
 occurs depends on the pattern. Patterns consist of some combination of
@@ -3235,7 +3247,7 @@ let message = match maybe_digit {
 };
 ```
 
-### If let expressions
+### `if let` expressions
 
 An `if let` expression is semantically identical to an `if` expression but in place
 of a condition expression it expects a refutable let statement. If the value of the
@@ -3256,15 +3268,15 @@ if let ("Ham", b) = dish {
 }
 ```
 
-### While let loops
+### `while let` loops
 
 A `while let` loop is semantically identical to a `while` loop but in place of a
 condition expression it expects a refutable let statement. If the value of the
 expression on the right hand side of the let statement matches the pattern, the
 loop body block executes and control returns to the pattern matching statement.
 Otherwise, the while expression completes.
 
-### Return expressions
+### `return` expressions
 
 Return expressions are denoted with the keyword `return`. Evaluating a `return`
 expression moves its argument into the designated output location for the

branches/auto/src/doc/style/errors/ergonomics.md

@@ -57,7 +57,7 @@ fn write_info(info: &Info) -> Result<(), IoError> {
 ```
 
 See
-[the `result` module documentation](https://doc.rust-lang.org/stable/std/result/index.html#the-try!-macro)
+[the `result` module documentation](https://doc.rust-lang.org/stable/std/result/index.html#the-try-macro)
 for more details.
 
 ### The `Result`-`impl` pattern [FIXME]

branches/auto/src/doc/style/features/traits/generics.md

@@ -27,7 +27,7 @@ explicitly implement to be used by this generic function.
 * _Inference_. Since the type parameters to generic functions can usually be
   inferred, generic functions can help cut down on verbosity in code where
   explicit conversions or other method calls would usually be necessary. See the
-  [overloading/implicits use case](#use-case:-limited-overloading-and/or-implicit-conversions)
+  [overloading/implicits use case](#use-case-limited-overloading-andor-implicit-conversions)
   below.
 * _Precise types_. Because generics give a _name_ to the specific type
   implementing a trait, it is possible to be precise about places where that
@@ -51,7 +51,7 @@ explicitly implement to be used by this generic function.
   a `Vec<T>` contains elements of a single concrete type (and, indeed, the
   vector representation is specialized to lay these out in line). Sometimes
   heterogeneous collections are useful; see
-  [trait objects](#use-case:-trait-objects) below.
+  [trait objects](#use-case-trait-objects) below.
 * _Signature verbosity_. Heavy use of generics can bloat function signatures.
   **[Ed. note]** This problem may be mitigated by some language improvements; stay tuned.
 

branches/auto/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 more
+A common gripe when reading Rust code is with types like `Rc<RefCell<Vec<T>>>` (or even 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)