Updating syntax/ast.rs types to structs

AUTHORS.txt

@@ -16,6 +16,7 @@ Arkaitz Jimenez <[email protected]>
 Armin Ronacher <[email protected]>
 Austin Seipp <[email protected]>
 auREAX <[email protected]>
+Ben Alpert <[email protected]>
 Ben Blum <[email protected]>
 Ben Striegel <[email protected]>
 Benjamin Herr <[email protected]>
@@ -49,6 +50,7 @@ Erick Tryzelaar <[email protected]>
 Erik Rose <[email protected]>
 Evan McClanahan <[email protected]>
 Francisco Souza <[email protected]>
+Franklin Chen <[email protected]>
 Gabriel <[email protected]>
 Gareth Daniel Smith <[email protected]>
 Glenn Willen <[email protected]>
@@ -58,6 +60,7 @@ Grahame Bowland <[email protected]>
 Haitao Li <[email protected]>
 Huon Wilson <[email protected]>
 Ian D. Bollinger <[email protected]>
+Ilyong Cho <[email protected]>
 Isaac Aggrey <[email protected]>
 Ivano Coppola <[email protected]>
 Jacob Harris Cryer Kragh <[email protected]>
@@ -74,6 +77,7 @@ Jesse Ruderman <[email protected]>
 Jim Blandy <[email protected]>
 Jimmy Lu <[email protected]>
 Joe Pletcher <[email protected]>
+John Clements <[email protected]>
 Jon Morton <[email protected]>
 Jonathan Sternberg <[email protected]>
 Josh Matthews <[email protected]>
@@ -84,13 +88,14 @@ Kelly Wilson <[email protected]>
 Kevin Atkinson <[email protected]>
 Kevin Cantu <[email protected]>
 Lennart Kudling <[email protected]>
-Lindsey Kuper <lindsey@rockstargirl.org>
+Lindsey Kuper <lindsey@composition.al>
 Luca Bruno <[email protected]>
 Luqman Aden <[email protected]>
 Magnus Auvinen <[email protected]>
 Mahmut Bulut <[email protected]>
 Margaret Meyerhofer <[email protected]>
 Marijn Haverbeke <[email protected]>
+Mark Lacey <[email protected]>
 Martin DeMello <[email protected]>
 Matt Brubeck <[email protected]>
 Matthew O'Connor <[email protected]>
@@ -106,6 +111,7 @@ Patrik Kårlin <[email protected]>
 Paul Stansifer <[email protected]>
 Paul Woolcock <[email protected]>
 Peter Hull <[email protected]>
+Peter Williams <[email protected]>
 Philipp Brüschweiler <[email protected]>
 Rafael Ávila de Espíndola <[email protected]>
 Ralph Giles <[email protected]>
@@ -116,9 +122,11 @@ Roland Tanglao <[email protected]>
 Roy Frostig <[email protected]>
 Ryan Scheel <[email protected]>
 Sean Stangl <[email protected]>
+Sebastian N. Fernandez <[email protected]>
 Simon Barber-Dueck <[email protected]>
 startling <[email protected]>
 Stefan Plantikow <[email protected]>
+Steve Klabnik <[email protected]>
 Taras Shpot <[email protected]>
 Ted Horst <[email protected]>
 Tim Chevalier <[email protected]>
@@ -130,5 +138,6 @@ Tycho Sci <[email protected]>
 Viktor Dahl <[email protected]>
 Vincent Belliard <[email protected]>
 Wade Mealing <[email protected]>
+William Ting <[email protected]>
 Yasuhiro Fujii <[email protected]>
 Zack Corr <[email protected]>

CONTRIBUTING.md

@@ -0,0 +1,12 @@
+## Pull request procedure
+
+Pull requests should be targeted at Rust's `incoming` branch (note that by default Github will aim them at the `master` branch) -- see "Changing The Commit Range and Destination Repository" in Github's documentation on [pull requests](https://help.github.com/articles/using-pull-requests). Before pushing to your Github repo and issuing the pull request, please do two things:
+
+1. [Rebase](http://git-scm.com/book/en/Git-Branching-Rebasing) your local changes against the `incoming` branch. Resolve any conflicts that arise.
+2. Run the full Rust test suite with the `make check` command. You're not off the hook even if you just stick to documentation; code examples in the docs are tested as well!
+
+Pull requests will be treated as "review requests", and we will give feedback we expect to see corrected on [style](https://github.com/mozilla/rust/wiki/Note-style-guide) and substance before pulling. Changes contributed via pull request should focus on a single issue at a time, like any other. We will not look kindly on pull-requests that try to "sneak" unrelated changes in.
+
+Normally, all pull requests must include regression tests (see [[Note-testsuite]]) that test your change. Occasionally, a change will be very difficult to test for. In those cases, please include a note in your commit message explaining why.
+
+For more details, please refer to [[Note-development-policy]].

README.md

@@ -65,10 +65,11 @@ API-documentation tool, and `cargo`, the Rust package manager.
 
 ## License
 
-Rust is primarily distributed under the terms of the MIT license, with
-portions covered by various BSD-like licenses.
+Rust is primarily distributed under the terms of both the MIT license
+and the Apache License (Version 2.0), with portions covered by various
+BSD-like licenses.
 
-See LICENSE.txt for details.
+See LICENSE-APACHE, LICENSE-MIT, and COPYRIGHT for details.
 
 ## More help
 

configure

@@ -516,7 +516,7 @@ then
                       | cut -d ' ' -f 2)
 
     case $CFG_CLANG_VERSION in
-        (3.0svn | 3.0 | 3.1 | 4.0 | 4.1)
+        (3.0svn | 3.0 | 3.1 | 3.2 | 4.0 | 4.1)
         step_msg "found ok version of CLANG: $CFG_CLANG_VERSION"
         CFG_C_COMPILER="clang"
         ;;
@@ -578,7 +578,7 @@ for t in $CFG_TARGET_TRIPLES
 do
   make_dir rt/$t
   for i in                                          \
-    isaac linenoise bigint sync test arch/i386 arch/x86_64    \
+    isaac linenoise sync test arch/i386 arch/x86_64    \
     libuv libuv/src/ares libuv/src/eio libuv/src/ev
   do
     make_dir rt/$t/$i

doc/rust.md

@@ -1107,6 +1107,19 @@ let mut a: Animal = Dog;
 a = Cat;
 ~~~~
 
+Enumeration constructors can have either named or unnamed fields:
+~~~~
+enum Animal {
+    Dog (~str, float),
+    Cat { name: ~str, weight: float }
+}
+
+let mut a: Animal = Dog(~"Cocoa", 37.2);
+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
 
 ~~~~~~~~ {.ebnf .gram}
@@ -3245,12 +3258,12 @@ crate name the crate is given a default name that matches the source file,
 with the extension removed. In that case, to turn on logging for a program
 compiled from, e.g. `helloworld.rs`, `RUST_LOG` should be set to `helloworld`.
 
-As a convenience, the logging spec can also be set to a special psuedo-crate,
+As a convenience, the logging spec can also be set to a special pseudo-crate,
 `::help`. In this case, when the application starts, the runtime will
 simply output a list of loaded modules containing log expressions, then exit.
 
 The Rust runtime itself generates logging information. The runtime's logs are
-generated for a number of artificial modules in the `::rt` psuedo-crate,
+generated for a number of artificial modules in the `::rt` pseudo-crate,
 and can be enabled just like the logs for any standard module. The full list
 of runtime logging modules follows.
 
@@ -3328,7 +3341,7 @@ have come and gone during the course of Rust's development:
 
 * The Newsqueak (1988), Alef (1995), and Limbo (1996) family. These
   languages were developed by Rob Pike, Phil Winterbottom, Sean Dorward and
-  others in their group at Bell labs Computing Sciences Research Center
+  others in their group at Bell Labs Computing Sciences Research Center
   (Murray Hill, NJ, USA).
 
 * The Napier (1985) and Napier88 (1988) family. These languages were

doc/tutorial-macros.md

@@ -43,7 +43,7 @@ macro_rules! early_return(
             _ => {}
         }
     );
-);
+)
 // ...
 early_return!(input_1 special_a);
 // ...
@@ -115,7 +115,7 @@ 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 errror).
+`() => (1,2,3)` is a macro that expands to a syntax error).
 
 Except for permissibility of `$name` (and `$(...)*`, discussed below), the
 right-hand side of a macro definition is ordinary Rust syntax. In particular,
@@ -160,7 +160,7 @@ macro_rules! early_return(
             _ => {}
         }
     );
-);
+)
 // ...
 early_return!(input_1, [special_a|special_c|special_d]);
 // ...