---

yaml
---
r: 139263
b: refs/heads/try2
c: 47ddb59
h: refs/heads/master
i:
  139261: 32a31d3
  139259: 538813c
  139255: 5930303
  139247: c8088b7
  139231: f7185e7
  139199: d669d06
  139135: 29033cc
  139007: ec0376a
  138751: 378c66c
  138239: 16547ae
  137215: 4b4d2f9
  135167: cec7097
  131071: 126dbf5
v: v3

Author: bors

[refs]

@@ -5,7 +5,7 @@ refs/heads/snap-stage3: 78a7676898d9f80ab540c6df5d4c9ce35bb50463
 refs/heads/try: 519addf6277dbafccbb4159db4b710c37eaa2ec5
 refs/tags/release-0.1: 1f5c5126e96c79d22cb7862f75304136e204f105
 refs/heads/ndm: f3868061cd7988080c30d6d5bf352a5a5fe2460b
-refs/heads/try2: 29e8b6ea9b63c5cc1cd91cc5eb756820f7fe50b7
+refs/heads/try2: 47ddb59b802faa25b733416caf3d1b5588ab60a3
 refs/heads/dist-snap: ba4081a5a8573875fed17545846f6f6902c8ba8d
 refs/tags/release-0.2: c870d2dffb391e14efb05aa27898f1f6333a9596
 refs/tags/release-0.3: b5f0d0f648d9a6153664837026ba1be43d3e2503

branches/try2/Makefile.in

@@ -238,7 +238,7 @@ $(foreach target,$(CFG_TARGET_TRIPLES),\
 
 CORELIB_CRATE := $(S)src/libcore/core.rc
 CORELIB_INPUTS := $(wildcard $(addprefix $(S)src/libcore/,        \
-                                           core.rc *.rs */*.rs))
+                                           core.rc *.rs */*.rs */*/*rs))
 
 ######################################################################
 # Standard library variables

branches/try2/RELEASES.txt

@@ -1,7 +1,7 @@
 Version 0.6 (March 2013)
 ---------------------------
 
-   * ~??? changes, numerous bugfixes
+   * ~2000 changes, numerous bugfixes
 
    * TODO:
       * Ord/Cmp
@@ -39,6 +39,8 @@ Version 0.6 (March 2013)
       * Newtype enums removed. Used tuple-structs.
       * Trait implementations no longer support visibility modifiers
       * Pattern matching over vectors improved and expanded
+      * `const` renamed to `static` to correspond to lifetime name,
+        and make room for future `static mut` unsafe mutable globals.
 
    * Semantic changes
       * Types with owned pointers or custom destructors move by default,
@@ -52,8 +54,9 @@ Version 0.6 (March 2013)
       * Name resolution continues to be tweaked
       * Method visibility is inherited from the implementation declaration
       * Structural records have been removed
-      * Many more types can be used in constants, including enums,
-        `static lifetime pointers and vectors
+      * Many more types can be used in static items, including enums
+        'static-lifetime pointers and vectors
+      * Pattern matching over vectors improved and expanded
       * Typechecking of closure types has been overhauled to
         improve inference and eliminate unsoundness
 
@@ -85,6 +88,7 @@ Version 0.6 (March 2013)
       * Improved foreign function ABI implementation for x86, x86_64
       * Various memory usage improvements
       * Rust code may be embedded in foreign code under limited circumstances
+      * Inline assembler supported by new asm!() syntax extension.
 
 Version 0.5 (December 2012)
 ---------------------------

branches/try2/configure

@@ -136,9 +136,17 @@ validate_opt () {
                 isArgValid=1
             fi
         done
-        if test $isArgValid -eq 0
+        if [ "$arg" = "--help" ]
         then
-            err "Option '$arg' is not recognized"
+            echo ""
+            echo "No more help available for Configure options,"
+            echo "check the Wiki or join our IRC channel"
+            break
+        else
+            if test $isArgValid -eq 0
+            then
+                err "Option '$arg' is not recognized"
+            fi
         fi
     done
 }
@@ -266,13 +274,42 @@ case $CFG_OSTYPE in
     MINGW32*)
         CFG_OSTYPE=pc-mingw32
         ;;
+# Thad's Cygwin identifers below
+
+#   Vista 32 bit
+    CYGWIN_NT-6.0)
+        CFG_OSTYPE=pc-mingw32
+        CFG_CPUTYPE=i686
+        ;;
+
+#   Vista 64 bit
+    CYGWIN_NT-6.0-WOW64)
+        CFG_OSTYPE=w64-mingw32
+        CFG_CPUTYPE=x86_64
+        ;;
+
+#   Win 7 32 bit
+    CYGWIN_NT-6.1)
+        CFG_OSTYPE=pc-mingw32
+        CFG_CPUTYPE=i686
+        ;;
 
+#   Win 7 64 bit
+    CYGWIN_NT-6.1-WOW64)
+        CFG_OSTYPE=w64-mingw32
+        CFG_CPUTYPE=x86_64
+        ;;
+
+# We do not detect other OS such as XP/2003 using 64 bit using uname.
+# If we want to in the future, we will need to use Cygwin - Chuck's csih helper in /usr/lib/csih/winProductName.exe or alternative.
     *)
         err "unknown OS type: $CFG_OSTYPE"
         ;;
 esac
 
 
+if [ -z "$CFG_CPUTYPE" ]
+then
 case $CFG_CPUTYPE in
 
     i386 | i486 | i686 | i786 | x86)
@@ -290,6 +327,7 @@ case $CFG_CPUTYPE in
     *)
         err "unknown CPU type: $CFG_CPUTYPE"
 esac
+fi
 
 # Detect 64 bit linux systems with 32 bit userland and force 32 bit compilation
 if [ $CFG_OSTYPE = unknown-linux-gnu -a $CFG_CPUTYPE = x86_64 ]

branches/try2/doc/rust.md

@@ -617,8 +617,8 @@ each of which may have some number of [attributes](#attributes) attached to it.
 ## Items
 
 ~~~~~~~~ {.ebnf .gram}
-item : mod_item | fn_item | type_item | enum_item
-     | const_item | trait_item | impl_item | foreign_mod_item ;
+item : mod_item | fn_item | type_item | struct_item | enum_item
+     | static_item | trait_item | impl_item | foreign_mod_item ;
 ~~~~~~~~
 
 An _item_ is a component of a crate; some module items can be defined in crate
@@ -627,7 +627,7 @@ crate by a nested set of [modules](#modules). Every crate has a single
 "outermost" anonymous module; all further items within the crate have
 [paths](#paths) within the module tree of the crate.
 
-Items are entirely determined at compile-time, remain constant during
+Items are entirely determined at compile-time, generally remain fixed during
 execution, and may reside in read-only memory.
 
 There are several kinds of item:
@@ -637,7 +637,7 @@ There are several kinds of item:
   * [type definitions](#type-definitions)
   * [structures](#structures)
   * [enumerations](#enumerations)
-  * [constants](#constants)
+  * [static items](#static-items)
   * [traits](#traits)
   * [implementations](#implementations)
 
@@ -1091,21 +1091,23 @@ a = Cat{ name: ~"Spotty", weight: 2.7 };
 In this example, `Cat` is a _struct-like enum variant_,
 whereas `Dog` is simply called an enum variant.
 
-### Constants
+### Static items
 
 ~~~~~~~~ {.ebnf .gram}
-const_item : "const" ident ':' type '=' expr ';' ;
+static_item : "static" ident ':' type '=' expr ';' ;
 ~~~~~~~~
 
-A *constant* is a named value stored in read-only memory in a crate.
-The value bound to a constant is evaluated at compile time.
-Constants are declared with the `static` keyword.
-A constant item must have an expression giving its definition.
-The definition expression of a constant is limited to expression forms that can be evaluated at compile time.
+A *static item* is a named _constant value_ stored in the global data section of a crate.
+Immutable static items are stored in the read-only data section.
+The constant value bound to a static item is, like all constant values, evaluated at compile time.
+Static items have the `static` lifetime, which outlives all other lifetimes in a Rust program.
+Static items are declared with the `static` keyword.
+A static item must have a _constant expression_ giving its definition.
 
-Constants must be explicitly typed. The type may be ```bool```, ```char```, a number, or a type derived from those primitive types.
-The derived types are borrowed pointers, static arrays, tuples, and structs.
-Borrowed pointers must be have the `'static` lifetime.
+Static items must be explicitly typed.
+The type may be ```bool```, ```char```, a number, or a type derived from those primitive types.
+The derived types are borrowed pointers with the `'static` lifetime,
+fixed-size arrays, tuples, and structs.
 
 ~~~~
 static bit1: uint = 1 << 0;
@@ -1456,7 +1458,7 @@ The declared names may denote new slots or new items.
 
 An _item declaration statement_ has a syntactic form identical to an
 [item](#items) declaration within a module. Declaring an item -- a function,
-enumeration, type, constant, trait, implementation or module -- locally
+enumeration, structure, type, static, trait, implementation or module -- locally
 within a statement block is simply a way of restricting its scope to a narrow
 region containing all of its uses; it is otherwise identical in meaning to
 declaring the item outside the statement block.

branches/try2/doc/tutorial-borrowed-ptr.md

@@ -468,11 +468,10 @@ overwritten for the duration of the borrow.  In fact, the compiler
 would accept the example we gave earlier. The example is safe because
 the shape pointer has type `&Shape`, which means "borrowed pointer to
 immutable memory containing a `shape`". If, however, the type of that
-pointer were `&const Shape` or `&mut Shape`, then the ref binding
-would be ill-typed. Just as with unique boxes, the compiler will
-permit `ref` bindings into data owned by the stack frame even if the
-data are mutable, but otherwise it requires that the data reside in
-immutable memory.
+pointer were `&mut Shape`, then the ref binding would be ill-typed.
+Just as with unique boxes, the compiler will permit `ref` bindings
+into data owned by the stack frame even if the data are mutable,
+but otherwise it requires that the data reside in immutable memory.
 
 # Returning borrowed pointers
 

branches/try2/doc/tutorial-macros.md

@@ -3,10 +3,12 @@
 # Introduction
 
 Functions are the primary tool that programmers can use to build abstractions.
-Sometimes, however, programmers want to perform abstractions over things that are not
-runtime values. Macros provide a syntactic abstraction. For an example of how this
-can be useful, consider the following two code fragments, which both pattern-match
-on their input and return early in one case, and do nothing otherwise:
+Sometimes, however, programmers want to abstract over compile-time syntax
+rather than run-time values.
+Macros provide syntactic abstraction.
+For an example of how this can be useful, consider the following two code fragments,
+which both pattern-match on their input and both return early in one case,
+doing nothing otherwise:
 
 ~~~~
 # enum t { special_a(uint), special_b(uint) };
@@ -25,9 +27,10 @@ match input_2 {
 # }
 ~~~~
 
-This code could become tiresome if repeated many times. However, no function
-can capture its functionality to make it possible to rewrite the repetition
-away. Rust's macro system, however, can eliminate the repetition. Macros are
+This code could become tiresome if repeated many times.
+However, no function can capture its functionality to make it possible
+to abstract the repetition away.
+Rust's macro system, however, can eliminate the repetition. Macros are
 lightweight custom syntax extensions, themselves defined using the
 `macro_rules!` syntax extension. The following `early_return` macro captures
 the pattern in the above code:
@@ -37,7 +40,7 @@ the pattern in the above code:
 # fn f() -> uint {
 # let input_1 = special_a(0), input_2 = special_a(0);
 macro_rules! early_return(
-    ($inp:expr $sp:ident) => ( //invoke it like `(input_5 special_e)`
+    ($inp:expr $sp:ident) => ( // invoke it like `(input_5 special_e)`
         match $inp {
             $sp(x) => { return x; }
             _ => {}
@@ -93,10 +96,10 @@ that could be invoked like: `my_macro!(i->(( 2+2 )))`.
 
 ## Invocation location
 
-A macro invocation may take the place of (and therefore expand to) either an
-expression, an item, or a statement. The Rust parser will parse the macro
-invocation as a "placeholder" for whichever of those three nonterminals is
-appropriate for the location.
+A macro invocation may take the place of (and therefore expand to)
+an expression, an item, or a statement.
+The Rust parser will parse the macro invocation as a "placeholder"
+for whichever of those three nonterminals is appropriate for the location.
 
 At expansion time, the output of the macro will be parsed as whichever of the
 three nonterminals it stands in for. This means that a single macro might,
@@ -112,17 +115,19 @@ The right-hand side of the `=>` follows the same rules as the left-hand side,
 except that a `$` need only be followed by the name of the syntactic fragment
 to transcribe into the macro expansion; its type need not be repeated.
 
-The right-hand side must be enclosed by delimiters, which are ignored by the
-transcriber (therefore `() => ((1,2,3))` is a macro that expands to a tuple
-expression, `() => (let $x=$val)` is a macro that expands to a statement, and
-`() => (1,2,3)` is a macro that expands to a syntax error).
+The right-hand side must be enclosed by delimiters, which the transcriber ignores.
+Therefore `() => ((1,2,3))` is a macro that expands to a tuple expression,
+`() => (let $x=$val)` is a macro that expands to a statement,
+and `() => (1,2,3)` is a macro that expands to a syntax error
+(since the transcriber interprets the parentheses on the right-hand-size as delimiters,
+and `1,2,3` is not a valid Rust expression on its own).
 
 Except for permissibility of `$name` (and `$(...)*`, discussed below), the
 right-hand side of a macro definition is ordinary Rust syntax. In particular,
 macro invocations (including invocations of the macro currently being defined)
 are permitted in expression, statement, and item locations. However, nothing
 else about the code is examined or executed by the macro system; execution
-still has to wait until runtime.
+still has to wait until run-time.
 
 ## Interpolation location
 
@@ -287,7 +292,6 @@ A macro may accept multiple different input grammars. The first one to
 successfully match the actual argument to a macro invocation is the one that
 "wins".
 
-
 In the case of the example above, we want to write a recursive macro to
 process the semicolon-terminated lines, one-by-one. So, we want the following
 input patterns:
@@ -369,19 +373,19 @@ return result + val;
 # }
 ~~~~
 
-This technique is applicable in many cases where transcribing a result "all
-at once" is not possible. It resembles ordinary functional programming in some
-respects, but it is important to recognize the differences.
+This technique applies to many cases where transcribing a result all at once is not possible.
+The resulting code resembles ordinary functional programming in some respects,
+but has some important differences from functional programming.
 
 The first difference is important, but also easy to forget: the transcription
 (right-hand) side of a `macro_rules!` rule is literal syntax, which can only
 be executed at run-time. If a piece of transcription syntax does not itself
 appear inside another macro invocation, it will become part of the final
 program. If it is inside a macro invocation (for example, the recursive
-invocation of `biased_match_rec!`), it does have the opprotunity to affect
+invocation of `biased_match_rec!`), it does have the opportunity to affect
 transcription, but only through the process of attempted pattern matching.
 
-The second difference is related: the evaluation order of macros feels
+The second, related, difference is that the evaluation order of macros feels
 "backwards" compared to ordinary programming. Given an invocation
 `m1!(m2!())`, the expander first expands `m1!`, giving it as input the literal
 syntax `m2!()`. If it transcribes its argument unchanged into an appropriate

branches/try2/doc/tutorial.md

@@ -234,7 +234,7 @@ while count < 10 {
 
 Although Rust can almost always infer the types of local variables, you
 can specify a variable's type by following it with a colon, then the type
-name. Constants, on the other hand, always require a type annotation.
+name. Static items, on the other hand, always require a type annotation.
 
 ~~~~
 static monster_factor: float = 57.8;

branches/try2/mk/tests.mk

@@ -244,21 +244,29 @@ $(foreach host,$(CFG_HOST_TRIPLES), \
 
 define TEST_RUNNER
 
+# If NO_REBUILD is set then break the dependencies on std so we can
+# test crates without rebuilding core and std first
+ifeq ($(NO_REBUILD),)
+STDTESTDEP_$(1)_$(2)_$(3) = $$(TLIB$(1)_T_$(2)_H_$(3))/$$(CFG_STDLIB_$(2))
+else
+STDTESTDEP_$(1)_$(2)_$(3) =
+endif
+
 $(3)/test/coretest.stage$(1)-$(2)$$(X_$(2)):			\
 		$$(CORELIB_CRATE) $$(CORELIB_INPUTS)	\
-		$$(TLIB$(1)_T_$(2)_H_$(3))/$$(CFG_STDLIB_$(2))
+		$$(STDTESTDEP_$(1)_$(2)_$(3))
 	@$$(call E, compile_and_link: $$@)
 	$$(STAGE$(1)_T_$(2)_H_$(3)) -o $$@ $$< --test
 
 $(3)/test/stdtest.stage$(1)-$(2)$$(X_$(2)):			\
 		$$(STDLIB_CRATE) $$(STDLIB_INPUTS)	\
-		$$(TLIB$(1)_T_$(2)_H_$(3))/$$(CFG_STDLIB_$(2))
+		$$(STDTESTDEP_$(1)_$(2)_$(3))
 	@$$(call E, compile_and_link: $$@)
 	$$(STAGE$(1)_T_$(2)_H_$(3)) -o $$@ $$< --test
 
 $(3)/test/syntaxtest.stage$(1)-$(2)$$(X_$(2)):			\
 		$$(LIBSYNTAX_CRATE) $$(LIBSYNTAX_INPUTS)	\
-		$$(TLIB$(1)_T_$(2)_H_$(3))/$$(CFG_STDLIB_$(2))
+		$$(STDTESTDEP_$(1)_$(2)_$(3))
 	@$$(call E, compile_and_link: $$@)
 	$$(STAGE$(1)_T_$(2)_H_$(3)) -o $$@ $$< --test
 

branches/try2/src/compiletest/common.rs

@@ -63,6 +63,9 @@ pub struct config {
     // Run tests using the JIT
     jit: bool,
 
+    // Run tests using the new runtime
+    newrt: bool,
+
     // Explain what's going on
     verbose: bool