---

yaml
---
r: 33919
b: refs/heads/snap-stage3
c: 05e51e6
h: refs/heads/master
i:
  33917: 432e633
  33915: 66c1c7e
  33911: 6f0a97e
  33903: d25277e
  33887: d296eae
  33855: b11ab06
  33791: ee7a913
v: v3

Author: brson

[refs]

@@ -1,7 +1,7 @@
 ---
 refs/heads/master: cd6f24f9d14ac90d167386a56e7a6ac1f0318195
 refs/heads/snap-stage1: e33de59e47c5076a89eadeb38f4934f58a3618a6
-refs/heads/snap-stage3: 5b6c1a2950ba2a8b6377a387f666b0e50c45fc4f
+refs/heads/snap-stage3: 05e51e6f7f4f70ede2164e8da325f60c64f79616
 refs/heads/try: d324a424d8f84b1eb049b12cf34182bda91b0024
 refs/tags/release-0.1: 1f5c5126e96c79d22cb7862f75304136e204f105
 refs/heads/ndm: f3868061cd7988080c30d6d5bf352a5a5fe2460b

branches/snap-stage3/AUTHORS.txt

@@ -4,6 +4,7 @@ Graydon Hoare <[email protected]>
 
 Other authors:
 
+
 Adam Bozanich <[email protected]>
 Aleksander Balicki <[email protected]>
 Alex Rønne Petersen <[email protected]>
@@ -29,6 +30,7 @@ Chris Peterson <[email protected]>
 Chris Pressey <[email protected]>
 Damian Gryski <[email protected]>
 Damien Grassart <[email protected]>
+Damien Schoof <[email protected]>
 Daniel Brooks <[email protected]>
 Daniel Luz <[email protected]>
 Daniel Patterson <[email protected]>
@@ -72,7 +74,7 @@ Jyun-Yan You <[email protected]>
 Kelly Wilson <[email protected]>
 Kevin Atkinson <[email protected]>
 Kevin Cantu <[email protected]>
-Lennart Kudling
+Lennart Kudling <[email protected]>
 Lindsey Kuper <[email protected]>
 Luca Bruno <[email protected]>
 Luqman Aden <[email protected]>
@@ -91,6 +93,7 @@ Orphée Lafond-Lummis <[email protected]>
 Patrick Walton <[email protected]>
 Patrik Kårlin <[email protected]>
 Paul Stansifer <[email protected]>
+Paul Woolcock <[email protected]>
 Peter Hull <[email protected]>
 Philipp Brüschweiler <[email protected]>
 Rafael Ávila de Espíndola <[email protected]>
@@ -102,14 +105,15 @@ Roland Tanglao <[email protected]>
 Roy Frostig <[email protected]>
 Ryan Scheel <[email protected]>
 Sean Stangl <[email protected]>
-Simon BD
+Simon Barber-Dueck <[email protected]>
 startling <[email protected]>
 Stefan Plantikow <[email protected]>
 Taras Shpot <[email protected]>
 Ted Horst <[email protected]>
 Tim Chevalier <[email protected]>
 Tom Lee <[email protected]>
 Tomoki Aonuma <[email protected]>
+Tony Young <[email protected]>
 Tycho Sci <[email protected]>
 Viktor Dahl <[email protected]>
 Vincent Belliard <[email protected]>

branches/snap-stage3/doc/README

@@ -0,0 +1,13 @@
+The markdown docs are only generated by make when node is installed (use
+`make doc`). If you don't have node installed you can generate them yourself. 
+Unfortunately there's no real standard for markdown and all the tools work 
+differently. pandoc is one that seems to work well.
+
+To generate an html version of a doc do something like:
+pandoc --from=markdown --to=html --number-sections -o build/doc/rust.html doc/rust.md && git web--browse build/doc/rust.html
+
+The syntax for pandoc flavored markdown can be found at:
+http://johnmacfarlane.net/pandoc/README.html#pandocs-markdown
+
+A nice quick reference (for non-pandoc markdown) is at:
+http://kramdown.rubyforge.org/quickref.html

branches/snap-stage3/doc/rust.md

@@ -494,7 +494,7 @@ transcriber : '(' transcriber * ')' | '[' transcriber * ']'
 
 User-defined syntax extensions are called "macros", and they can be defined
 with the `macro_rules!` syntax extension. User-defined macros can currently
-only be invoked in expression position.
+be invoked as expressions, statements, or items.
 
 (A `sep_token` is any token other than `*` and `+`. A `non_special_token` is
 any token other than a delimiter or `$`.)
@@ -510,9 +510,8 @@ For parsing reasons, delimiters must be balanced, but they are otherwise not spe
 
 In the matcher, `$` _name_ `:` _designator_ matches the nonterminal in the
 Rust syntax named by _designator_. Valid designators are `item`, `block`,
-`stmt`, `pat`, `expr`, `ty`, `ident`, `path`, `tt`, `matchers`. The last two
-are the right-hand side and the left-hand side respectively of the `=>` in
-macro rules. In the transcriber, the designator is already known, and so only
+`stmt`, `pat`, `expr`, `ty` (type), `ident`, `path`, `matchers` (lhs of the `=>` in macro rules),
+`tt` (rhs of the `=>` in macro rules). In the transcriber, the designator is already known, and so only
 the name of a matched nonterminal comes after the dollar sign.
 
 In both the matcher and transcriber, the Kleene star-like operator indicates repetition.
@@ -799,7 +798,7 @@ extern mod ruststd (name = "std"); // linking to 'std' under another name
 ##### Use declarations
 
 ~~~~~~~~ {.ebnf .gram}
-use_decl : "use" ident [ '=' path
+use_decl : "pub"? "use" ident [ '=' path
                           | "::" path_glob ] ;
 
 path_glob : ident [ "::" path_glob ] ?
@@ -1104,6 +1103,27 @@ Constants are declared with the `const` 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.
 
+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.
+
+~~~~
+const bit1: uint = 1 << 0;
+const bit2: uint = 1 << 1;
+
+const bits: [uint * 2] = [bit1, bit2];
+const string: &str = "bitstring";
+
+struct BitsNStrings {
+    mybits: [uint *2],
+    mystring: &str
+}
+
+const bits_n_strings: BitsNStrings = BitsNStrings {
+    mybits: bits,
+    mystring: string
+};
+~~~~
+
 ### Traits
 
 A _trait_ describes a set of method types.
@@ -1175,6 +1195,9 @@ Values with a trait type can have [methods called](#method-call-expressions) on
 for any method in the trait,
 and can be used to instantiate type parameters that are bounded by the trait.
 
+Trait methods may be static. Currently implementations of static methods behave like
+functions declared in the implentation's module.
+
 ### Implementations
 
 An _implementation_ is an item that implements a [trait](#traits) for a specific type.
@@ -1304,9 +1327,8 @@ Attributes may appear as any of
 * An identifier followed by the equals sign '=' and a literal, providing a key/value pair
 * An identifier followed by a parenthesized list of sub-attribute arguments
 
-Attributes are applied to an entity by placing them within a hash-list
-(`#[...]`) as either a prefix to the entity or as a semicolon-delimited
-declaration within the entity body.
+Attributes terminated by a semi-colon apply to the entity that the attribute is declared
+within. Attributes that are not terminated by a semi-colon apply to the next entity.
 
 An example of attributes:
 
@@ -1326,9 +1348,9 @@ mod bar {
   ...
 }
 
-// A documentation attribute
-#[doc = "Add two numbers together."]
-fn add(x: int, y: int) { x + y }
+// A lint attribute used to suppress a warning/error
+#[allow(non_camel_case_types)]
+pub type int8_t = i8;
 ~~~~~~~~
 
 > **Note:** In future versions of Rust, user-provided extensions to the compiler will be able to interpret attributes.
@@ -1341,6 +1363,8 @@ names are effectively reserved. Some significant attributes include:
 * The `cfg` attribute, for conditional-compilation by build-configuration.
 * The `link` attribute, for describing linkage metadata for a crate.
 * The `test` attribute, for marking functions as unit tests.
+* The `allow`, `warn`, `forbid`, and `deny` attributes, for controling lint checks. Lint checks supported
+by the compiler can be found via `rustc -W help`.
 
 Other attributes may be added or removed during development of the language.
 
@@ -1546,7 +1570,9 @@ it is automatically derferenced to make the field access possible.
 ### Vector expressions
 
 ~~~~~~~~{.ebnf .gram}
-vec_expr : '[' "mut" ? [ expr [ ',' expr ] * ] ? ']'
+vec_expr : '[' "mut"? vec_elems? ']'
+
+vec_elems : [expr [',' expr]*] | [expr ',' ".." expr]
 ~~~~~~~~
 
 A [_vector_](#vector-types) _expression_ is written by enclosing zero or
@@ -1558,6 +1584,7 @@ When no mutability is specified, the vector is immutable.
 ~~~~
 [1, 2, 3, 4];
 ["a", "b", "c", "d"];
+[0, ..128];             // vector with 128 zeros
 [mut 0u8, 0u8, 0u8, 0u8];
 ~~~~
 
@@ -1889,7 +1916,7 @@ let x: int = add(1, 2);
 
 ~~~~~~~~ {.abnf .gram}
 ident_list : [ ident [ ',' ident ]* ] ? ;
-lambda_expr : '|' ident_list '| expr ;
+lambda_expr : '|' ident_list '|' expr ;
 ~~~~~~~~
 
 A _lambda expression_ (a.k.a. "anonymous function expression") defines a function and denotes it as a value,
@@ -2170,17 +2197,6 @@ When matching fields of a record,
 the fields being matched are specified first,
 then a placeholder (`_`) represents the remaining fields.
 
-A pattern that's just a variable binding,
-like `Nil` in the previous answer,
-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.
- 
 ~~~~
 # type options = {choose: bool, size: ~str};
 # type player = {player: ~str, stats: (), options: options};
@@ -2212,6 +2228,22 @@ fn main() {
 }
 ~~~~
 
+Patterns that bind variables default to binding to a copy of the matched value. This can be made
+explicit using the ```copy``` keyword, changed to bind to a borrowed pointer by using the ```ref```
+keyword, or to a mutable borrowed pointer using ```ref mut```, or the value can be moved into
+the new binding using ```move```.
+
+A pattern that's just an identifier,
+like `Nil` in the previous answer,
+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:
 
@@ -2694,11 +2726,12 @@ The kinds are:
     structural types containing only other sendable types.
 `Owned`
   : Types of this kind do not contain any borrowed pointers;
-    this can be a useful guarantee for code that breaks borrowing assumptions using [`unsafe` operations](#unsafe-functions).    
+    this can be a useful guarantee for code that breaks borrowing assumptions using [`unsafe` operations](#unsafe-functions).
 `Copy`
   : This kind includes all types that can be copied. All types with
     sendable kind are copyable, as are managed boxes, managed closures,
     trait types, and structural types built out of these.
+    Types with destructors (types that implement `Drop`) can not implement `Copy`.
 _Default_
   : Types with destructors, closure environments,
     and various other _non-first-class_ types,

branches/snap-stage3/doc/tutorial.md

@@ -1540,8 +1540,7 @@ them. In the rare case where the compiler needs assistance, though, the
 arguments and return types may be annotated.
 
 ~~~~
-# type mygoodness = fn(~str) -> ~str; type what_the = int;
-let bloop = |well, oh: mygoodness| -> what_the { fail oh(well) };
+let square = |x: int| -> uint { x * x as uint };
 ~~~~
 
 There are several forms of closure, each with its own role. The most
@@ -1914,7 +1913,7 @@ struct TimeBomb {
 }
 
 impl TimeBomb : Drop {
-    fn finalize() {
+    fn finalize(&self) {
         for iter::repeat(self.explosivity) {
             io::println("blam!");
         }
@@ -2043,8 +2042,9 @@ as in this version of `print_all` that copies elements.
 fn print_all<T: Printable Copy>(printable_things: ~[T]) {
     let mut i = 0;
     while i < printable_things.len() {
-        let copy_of_thing = printable_things[0];
+        let copy_of_thing = printable_things[i];
         copy_of_thing.print();
+        i += 1;
     }
 }
 ~~~

branches/snap-stage3/mk/tools.mk

@@ -10,11 +10,11 @@ COMPILETEST_INPUTS := $(wildcard $(S)src/compiletest/*rs)
 
 # Cargo, the package manager
 CARGO_LIB := $(S)src/libcargo/cargo.rc
-CARGO_INPUTS := $(wildcard $(S)src/cargo/*rs)
+CARGO_INPUTS := $(wildcard $(S)src/libcargo/*rs)
 
 # Rustdoc, the documentation tool
 RUSTDOC_LIB := $(S)src/librustdoc/rustdoc.rc
-RUSTDOC_INPUTS := $(wildcard $(S)src/rustdoc/*.rs)
+RUSTDOC_INPUTS := $(wildcard $(S)src/librustdoc/*.rs)
 
 # Rusti, the JIT REPL
 RUSTI_LIB := $(S)src/librusti/rusti.rc

branches/snap-stage3/src/compiletest/common.rs

@@ -1,10 +1,10 @@
 enum mode { mode_compile_fail, mode_run_fail, mode_run_pass, mode_pretty, }
 
 impl mode : cmp::Eq {
-    pure fn eq(other: &mode) -> bool {
-        (*other) as int == self as int
+    pure fn eq(&self, other: &mode) -> bool {
+        (*other) as int == (*self) as int
     }
-    pure fn ne(other: &mode) -> bool { !self.eq(other) }
+    pure fn ne(&self, other: &mode) -> bool { !(*self).eq(other) }
 }
 
 type config = {