---

yaml
---
r: 236550
b: refs/heads/tmp
c: 6c2e3fb
h: refs/heads/master
v: v3

Author: bors

[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: a6c8c7d0db7f4d13960b0270419285d3e1fbf5ac
+refs/heads/tmp: 6c2e3fbe909be15cbc3a0a981950acd99360bedb
 refs/tags/1.0.0-alpha.2: 4c705f6bc559886632d3871b04f58aab093bfa2f
 refs/tags/homu-tmp: f859507de8c410b648d934d8f5ec1c52daac971d
 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 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/tmp/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/tmp/RELEASES.md

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

branches/tmp/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/tmp/mk/cfg/x86_64-unknown-netbsd.mk

@@ -1,4 +1,5 @@
 # x86_64-unknown-netbsd configuration
+CROSS_PREFIX_x86_64-unknown-netbsd=x86_64-unknown-netbsd-
 CC_x86_64-unknown-netbsd=$(CC)
 CXX_x86_64-unknown-netbsd=$(CXX)
 CPP_x86_64-unknown-netbsd=$(CPP)

branches/tmp/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/tmp/mk/grammar.mk

@@ -58,17 +58,17 @@ check-lexer: $(BG) $(BG)RustLexer.class check-build-lexer-verifier
 	$(Q)$(SG)check.sh $(S) "$(BG)" \
 		"$(CFG_GRUN)" "$(BG)verify" "$(BG)RustLexer.tokens"
 else
-$(info cfg: grun not available, skipping lexer test...)
+$(info cfg: lexer tooling not available, skipping lexer test...)
 check-lexer:
 
 endif
 else
-$(info cfg: antlr4 not available, skipping lexer test...)
+$(info cfg: lexer tooling not available, skipping lexer test...)
 check-lexer:
 
 endif
 else
-$(info cfg: javac not available, skipping lexer test...)
+$(info cfg: lexer tooling not available, skipping lexer test...)
 check-lexer:
 
 endif

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=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/tmp/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/tmp/src/compiletest/runtest.rs

@@ -1669,8 +1669,7 @@ fn compile_test_and_save_ir(config: &Config, props: &TestProps,
     // FIXME (#9639): This needs to handle non-utf8 paths
     let mut link_args = vec!("-L".to_owned(),
                              aux_dir.to_str().unwrap().to_owned());
-    let llvm_args = vec!("--emit=llvm-ir".to_owned(),
-                         "--crate-type=lib".to_owned());
+    let llvm_args = vec!("--emit=llvm-ir".to_owned(),);
     link_args.extend(llvm_args);
     let args = make_compile_args(config,
                                  props,

branches/tmp/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/tmp/src/doc/grammar.md

@@ -9,7 +9,7 @@ provides only one kind of material:
 
 This document does not serve as an introduction to the language. Background
 familiarity with the language is assumed. A separate [guide] is available to
-help acquire such background familiarity.
+help acquire such background.
 
 This document also does not serve as a reference to the [standard] library
 included in the language distribution. Those libraries are documented

branches/tmp/src/doc/reference.md

@@ -674,7 +674,7 @@ There are several kinds of item:
 * [modules](#modules)
 * [functions](#functions)
 * [type definitions](grammar.html#type-definitions)
-* [structures](#structures)
+* [structs](#structs)
 * [enumerations](#enumerations)
 * [constant items](#constant-items)
 * [static items](#static-items)
@@ -900,9 +900,10 @@ fn main() {}
 
 ### Functions
 
-A _function item_ defines a sequence of [statements](#statements) and an
-optional final [expression](#expressions), along with a name and a set of
-parameters. Functions are declared with the keyword `fn`. Functions declare a
+A _function item_ defines a sequence of [statements](#statements) and a
+final [expression](#expressions), along with a name and a set of
+parameters. Other than a name, all these are optional.
+Functions are declared with the keyword `fn`. Functions may declare a
 set of *input* [*variables*](#variables) as parameters, through which the caller
 passes arguments into the function, and the *output* [*type*](#types)
 of the value the function will return to its caller on completion.
@@ -921,7 +922,7 @@ An example of a function:
 
 ```
 fn add(x: i32, y: i32) -> i32 {
-    return x + y;
+    x + y
 }
 ```
 
@@ -1155,7 +1156,7 @@ type Point = (u8, u8);
 let p: Point = (41, 68);
 ```
 
-### Structures
+### Structs
 
 A _structure_ is a nominal [structure type](#structure-types) defined with the
 keyword `struct`.
@@ -2614,21 +2615,21 @@ comma:
 ### Structure expressions
 
 There are several forms of structure expressions. A _structure expression_
-consists of the [path](#paths) of a [structure item](#structures), followed by
+consists of the [path](#paths) of a [structure item](#structs), followed by
 a brace-enclosed list of one or more comma-separated name-value pairs,
 providing the field values of a new instance of the structure. A field name
 can be any identifier, and is separated from its value expression by a colon.
 The location denoted by a structure field is mutable if and only if the
 enclosing structure is mutable.
 
 A _tuple structure expression_ consists of the [path](#paths) of a [structure
-item](#structures), followed by a parenthesized list of one or more
+item](#structs), followed by a parenthesized list of one or more
 comma-separated expressions (in other words, the path of a structure item
 followed by a tuple expression). The structure item must be a tuple structure
 item.
 
 A _unit-like structure expression_ consists only of the [path](#paths) of a
-[structure item](#structures).
+[structure item](#structs).
 
 The following are examples of structure expressions:
 
@@ -3145,7 +3146,7 @@ if` condition is evaluated. If all `if` and `else if` conditions evaluate to
 
 A `match` expression branches on a *pattern*. The exact form of matching that
 occurs depends on the pattern. Patterns consist of some combination of
-literals, destructured arrays or enum constructors, structures and tuples,
+literals, destructured arrays or enum constructors, structs and tuples,
 variable binding specifications, wildcards (`..`), and placeholders (`_`). A
 `match` expression has a *head expression*, which is the value to compare to
 the patterns. The type of the patterns must equal the type of the head
@@ -3469,7 +3470,7 @@ named reference to an [`enum` item](#enumerations).
 ### Recursive types
 
 Nominal types — [enumerations](#enumerated-types) and
-[structures](#structure-types) — may be recursive. That is, each `enum`
+[structs](#structure-types) — may be recursive. That is, each `enum`
 constructor or `struct` field may refer, directly or indirectly, to the
 enclosing `enum` or `struct` type itself. Such recursion has restrictions:
 
@@ -3497,7 +3498,7 @@ let a: List<i32> = List::Cons(7, Box::new(List::Cons(13, Box::new(List::Nil))));
 ### Pointer types
 
 All pointers in Rust are explicit first-class values. They can be copied,
-stored into data structures, and returned from functions. There are two
+stored into data structs, and returned from functions. There are two
 varieties of pointer in Rust:
 
 * References (`&`)
@@ -3897,7 +3898,7 @@ references to boxes are dropped.
 ### Variables
 
 A _variable_ is a component of a stack frame, either a named function parameter,
-an anonymous [temporary](#lvalues,-rvalues-and-temporaries), or a named local
+an anonymous [temporary](#lvalues-rvalues-and-temporaries), or a named local
 variable.
 
 A _local variable_ (or *stack-local* allocation) holds a value directly,
@@ -4036,10 +4037,6 @@ In general, `--crate-type=bin` or `--crate-type=lib` should be sufficient for
 all compilation needs, and the other options are just available if more
 fine-grained control is desired over the output format of a Rust crate.
 
-# Appendix: Rationales and design trade-offs
-
-*TODO*.
-
 # Appendix: Influences
 
 Rust is not a particularly original language, with design elements coming from

branches/tmp/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/tmp/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/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 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)