---

yaml
---
r: 71921
b: refs/heads/dist-snap
c: 22786d6
h: refs/heads/master
i:
  71919: d80959c
v: v3

Author: tdaede

[refs]

@@ -7,7 +7,7 @@ refs/tags/release-0.1: 1f5c5126e96c79d22cb7862f75304136e204f105
 refs/heads/ndm: f3868061cd7988080c30d6d5bf352a5a5fe2460b
 refs/heads/try2: 147ecfdd8221e4a4d4e090486829a06da1e0ca3c
 refs/heads/incoming: b50030718cf28f2a5a81857a26b57442734fe854
-refs/heads/dist-snap: 03116f251d2d53842971b356fb320f6101d1a3e5
+refs/heads/dist-snap: 22786d6c5b3fb94ef64295f5b832ed776954db09
 refs/tags/release-0.2: c870d2dffb391e14efb05aa27898f1f6333a9596
 refs/tags/release-0.3: b5f0d0f648d9a6153664837026ba1be43d3e2503
 refs/heads/try3: 9387340aab40a73e8424c48fd42f0c521a4875c0

branches/dist-snap/.gitmodules

@@ -1,6 +1,6 @@
 [submodule "src/llvm"]
 	path = src/llvm
-	url = https://github.com/brson/llvm.git
+	url = git://github.com/brson/llvm.git
 [submodule "src/libuv"]
 	path = src/libuv
-	url = https://github.com/brson/libuv.git
+	url = git://github.com/brson/libuv.git

branches/dist-snap/configure

@@ -237,7 +237,7 @@ need_cmd uname
 need_cmd date
 need_cmd tr
 need_cmd sed
-
+need_cmd file
 
 msg "inspecting environment"
 
@@ -533,7 +533,7 @@ then
     LLVM_VERSION=$($LLVM_CONFIG --version)
 
     case $LLVM_VERSION in
-	(3.3|3.3svn|3.2|3.2svn)
+	(3.2svn|3.2|3.1svn|3.1|3.0svn|3.0)
 	    msg "found ok version of LLVM: $LLVM_VERSION"
 	    ;;
 	(*)

branches/dist-snap/doc/rust.md

@@ -441,10 +441,10 @@ expression context, the final namespace qualifier is omitted.
 Two examples of paths with type arguments:
 
 ~~~~
-# use core::hashmap::HashMap;
+# use core::hashmap::linear::LinearMap;
 # fn f() {
 # fn id<T:Copy>(t: T) -> T { t }
-type t = HashMap<int,~str>;  // Type arguments used in a type expression
+type t = LinearMap<int,~str>;  // Type arguments used in a type expression
 let x = id::<int>(10);         // Type arguments used in a call expression
 # }
 ~~~~
@@ -1653,12 +1653,11 @@ Path expressions are [lvalues](#lvalues-rvalues-and-temporaries).
 
 ### Tuple expressions
 
-Tuples are written by enclosing one or more comma-separated
+Tuples are written by enclosing two or more comma-separated
 expressions in parentheses. They are used to create [tuple-typed](#tuple-types)
 values.
 
 ~~~~~~~~ {.tuple}
-(0,);
 (0f, 4.5f);
 ("a", 4u, true);
 ~~~~~~~~
@@ -2579,7 +2578,7 @@ to the record type-constructor. The differences are as follows:
 
 Tuple types and values are denoted by listing the types or values of their
 elements, respectively, in a parenthesized, comma-separated
-list.
+list. Single-element tuples are not legal; all tuples have two or more values.
 
 The members of a tuple are laid out in memory contiguously, like a record, in
 order specified by the tuple type.
@@ -3252,28 +3251,6 @@ of runtime logging modules follows.
 * `::rt::backtrace` Log a backtrace on task failure
 * `::rt::callback` Unused
 
-#### Logging Expressions
-
-Rust provides several macros to log information. Here's a simple Rust program
-that demonstrates all four of them:
-
-```rust
-fn main() {
-    error!("This is an error log")
-    warn!("This is a warn log")
-    info!("this is an info log")
-    debug!("This is a debug log")
-}
-```
-
-These four log levels correspond to levels 1-4, as controlled by `RUST_LOG`:
-
-```bash
-$ RUST_LOG=rust=3 ./rust
-rust: ~"\"This is an error log\""
-rust: ~"\"This is a warn log\""
-rust: ~"\"this is an info log\""
-```
 
 # Appendix: Rationales and design tradeoffs
 

branches/dist-snap/doc/tutorial-tasks.md

@@ -2,63 +2,74 @@
 
 # Introduction
 
-Rust provides safe concurrency through a combination
-of lightweight, memory-isolated tasks and message passing.
-This tutorial will describe the concurrency model in Rust, how it
-relates to the Rust type system, and introduce
-the fundamental library abstractions for constructing concurrent programs.
-
-Rust tasks are not the same as traditional threads: rather,
-they are considered _green threads_, lightweight units of execution that the Rust
-runtime schedules cooperatively onto a small number of operating system threads.
-On a multi-core system Rust tasks will be scheduled in parallel by default.
-Because tasks are significantly
+The designers of Rust designed the language from the ground up to support pervasive
+and safe concurrency through lightweight, memory-isolated tasks and
+message passing.
+
+Rust tasks are not the same as traditional threads: rather, they are more like
+_green threads_. The Rust runtime system schedules tasks cooperatively onto a
+small number of operating system threads. Because tasks are significantly
 cheaper to create than traditional threads, Rust can create hundreds of
 thousands of concurrent tasks on a typical 32-bit system.
-In general, all Rust code executes inside a task, including the `main` function.
-
-In order to make efficient use of memory Rust tasks have dynamically sized stacks.
-A task begins its life with a small
-amount of stack space (currently in the low thousands of bytes, depending on
-platform), and acquires more stack as needed.
-Unlike in languages such as C, a Rust task cannot accidentally write to
-memory beyond the end of the stack, causing crashes or worse.
 
-Tasks provide failure isolation and recovery. When a fatal error occurs in Rust
-code as a result of an explicit call to `fail!()`, an assertion failure, or
-another invalid operation, the runtime system destroys the entire
+Tasks provide failure isolation and recovery. When an exception occurs in Rust
+code (as a result of an explicit call to `fail!()`, an assertion failure, or
+another invalid operation), the runtime system destroys the entire
 task. Unlike in languages such as Java and C++, there is no way to `catch` an
 exception. Instead, tasks may monitor each other for failure.
 
+Rust tasks have dynamically sized stacks. A task begins its life with a small
+amount of stack space (currently in the low thousands of bytes, depending on
+platform), and acquires more stack as needed. Unlike in languages such as C, a
+Rust task cannot run off the end of the stack. However, tasks do have a stack
+budget. If a Rust task exceeds its stack budget, then it will fail safely:
+with a checked exception.
+
 Tasks use Rust's type system to provide strong memory safety guarantees. In
 particular, the type system guarantees that tasks cannot share mutable state
 with each other. Tasks communicate with each other by transferring _owned_
 data through the global _exchange heap_.
 
+This tutorial explains the basics of tasks and communication in Rust,
+explores some typical patterns in concurrent Rust code, and finally
+discusses some of the more unusual synchronization types in the standard
+library.
+
+> ***Warning:*** This tutorial is incomplete
+
 ## A note about the libraries
 
 While Rust's type system provides the building blocks needed for safe
 and efficient tasks, all of the task functionality itself is implemented
 in the core and standard libraries, which are still under development
-and do not always present a consistent or complete interface.
+and do not always present a consistent interface.
+
+In particular, there are currently two independent modules that provide a
+message passing interface to Rust code: `core::comm` and `core::pipes`.
+`core::comm` is an older, less efficient system that is being phased out in
+favor of `pipes`. At some point, we will remove the existing `core::comm` API
+and move the user-facing portions of `core::pipes` to `core::comm`. In this
+tutorial, we discuss `pipes` and ignore the `comm` API.
 
 For your reference, these are the standard modules involved in Rust
 concurrency at this writing.
 
 * [`core::task`] - All code relating to tasks and task scheduling
-* [`core::comm`] - The message passing interface
-* [`core::pipes`] - The underlying messaging infrastructure
-* [`std::comm`] - Additional messaging types based on `core::pipes`
+* [`core::comm`] - The deprecated message passing API
+* [`core::pipes`] - The new message passing infrastructure and API
+* [`std::comm`] - Higher level messaging types based on `core::pipes`
 * [`std::sync`] - More exotic synchronization tools, including locks
-* [`std::arc`] - The ARC (atomically reference counted) type,
-  for safely sharing immutable data
+* [`std::arc`] - The ARC (atomic reference counted) type, for safely sharing
+  immutable data
+* [`std::par`] - Some basic tools for implementing parallel algorithms
 
 [`core::task`]: core/task.html
 [`core::comm`]: core/comm.html
 [`core::pipes`]: core/pipes.html
 [`std::comm`]: std/comm.html
 [`std::sync`]: std/sync.html
 [`std::arc`]: std/arc.html
+[`std::par`]: std/par.html
 
 # Basics
 

branches/dist-snap/doc/tutorial.md

@@ -495,11 +495,7 @@ omitted.
 
 A powerful application of pattern matching is *destructuring*:
 matching in order to bind names to the contents of data
-types.
-
-> ***Note:*** The following code makes use of tuples (`(float, float)`) which
-> are explained in section 5.3. For now you can think of tuples as a list of
-> items.
+types. Remember that `(float, float)` is a tuple of two floats:
 
 ~~~~
 fn angle(vector: (float, float)) -> float {
@@ -751,7 +747,7 @@ fn area(sh: Shape) -> float {
 
 Tuples in Rust behave exactly like structs, except that their fields
 do not have names. Thus, you cannot access their fields with dot notation.
-Tuples can have any arity except for 0 (though you may consider
+Tuples can have any arity except for 0 or 1 (though you may consider
 unit, `()`, as the empty tuple if you like).
 
 ~~~~
@@ -992,7 +988,7 @@ custom destructors.
 
 # Boxes
 
-Many modern languages represent values as pointers to heap memory by
+Many modern languages represent values as as pointers to heap memory by
 default. In contrast, Rust, like C and C++, represents such types directly.
 Another way to say this is that aggregate data in Rust are *unboxed*. This
 means that if you `let x = Point { x: 1f, y: 1f };`, you are creating a struct
@@ -1071,28 +1067,6 @@ let mut d = @mut 5; // mutable variable, mutable box
 d = @mut 15;
 ~~~~
 
-A mutable variable and an immutable variable can refer to the same box, given 
-that their types are compatible. Mutability of a box is a property of its type, 
-however, so for example a mutable handle to an immutable box cannot be 
-assigned a reference to a mutable box.
-
-~~~~
-let a = @1;     // immutable box
-let b = @mut 2; // mutable box
-
-let mut c : @int;       // declare a variable with type managed immutable int
-let mut d : @mut int;   // and one of type managed mutable int
-
-c = a;          // box type is the same, okay
-d = b;          // box type is the same, okay
-~~~~
-
-~~~~ {.xfail-test}
-// but b cannot be assigned to c, or a to d
-c = b;          // error
-~~~~
-
-
 # Move semantics
 
 Rust uses a shallow copy for parameter passing, assignment and returning values
@@ -1107,16 +1081,6 @@ let y = x.clone(); // y is a newly allocated box
 let z = x; // no new memory allocated, x can no longer be used
 ~~~~
 
-Since in owned boxes mutability is a property of the owner, not the 
-box, mutable boxes may become immutable when they are moved, and vice-versa.
-
-~~~~
-let r = ~13;
-let mut s = r; // box becomes mutable
-*s += 1;
-let t = s; // box becomes immutable
-~~~~
-
 # Borrowed pointers
 
 Rust's borrowed pointers are a general purpose reference type. In contrast with
@@ -1227,7 +1191,7 @@ they are frozen:
 let x = @mut 5;
 let y = x;
 {
-    let z = &*y; // the managed box is now frozen
+    let y = &*y; // the managed box is now frozen
     // modifying it through x or y will cause a task failure
 }
 // the box is now unfrozen again
@@ -1924,8 +1888,8 @@ illegal to copy and pass by value.
 Generic `type`, `struct`, and `enum` declarations follow the same pattern:
 
 ~~~~
-# use core::hashmap::HashMap;
-type Set<T> = HashMap<T, ()>;
+# use core::hashmap::linear::LinearMap;
+type Set<T> = LinearMap<T, ()>;
 
 struct Stack<T> {
     elements: ~[T]
@@ -2324,7 +2288,7 @@ impl Shape for CircleStruct {
 Notice that methods of `Circle` can call methods on `Shape`, as our
 `radius` implementation calls the `area` method.
 This is a silly way to compute the radius of a circle
-(since we could just return the `radius` field), but you get the idea.
+(since we could just return the `circle` field), but you get the idea.
 
 In type-parameterized functions,
 methods of the supertrait may be called on values of subtrait-bound type parameters.

branches/dist-snap/man/rustc.1

@@ -170,5 +170,5 @@ See \fBAUTHORS.txt\fR in the rust source distribution. Graydon Hoare
 <\fI[email protected]\fR> is the project leader.
 
 .SH "COPYRIGHT"
-This work is dual-licensed under Apache 2.0 and MIT terms.  See \fBCOPYRIGHT\fR
-file in the rust source distribution.
+This work is licensed under MIT-like terms.  See \fBLICENSE.txt\fR
+in the rust source distribution.

branches/dist-snap/mk/dist.mk

@@ -18,7 +18,6 @@ PKG_FILES := \
     $(S)COPYRIGHT                              \
     $(S)LICENSE-APACHE                         \
     $(S)LICENSE-MIT                            \
-    $(S)AUTHORS.txt                            \
     $(S)README.md                              \
     $(S)configure $(S)Makefile.in              \
     $(S)man                                    \

branches/dist-snap/mk/install.mk

@@ -119,8 +119,6 @@ install-host: $(CSREQ$(ISTAGE)_T_$(CFG_BUILD_TRIPLE)_H_$(CFG_BUILD_TRIPLE))
 	$(Q)$(call INSTALL_LIB,$(HL),$(PHL),$(LIBSYNTAX_GLOB_$(CFG_BUILD_TRIPLE)))
 	$(Q)$(call INSTALL_LIB,$(HL),$(PHL),$(LIBRUSTI_GLOB_$(CFG_BUILD_TRIPLE)))
 	$(Q)$(call INSTALL_LIB,$(HL),$(PHL),$(LIBRUST_GLOB_$(CFG_BUILD_TRIPLE)))
-	$(Q)$(call INSTALL_LIB,$(HL),$(PHL),$(LIBRUSTPKG_GLOB_$(CFG_BUILD_TRIPLE)))
-	$(Q)$(call INSTALL_LIB,$(HL),$(PHL),$(LIBRUSTDOC_GLOB_$(CFG_BUILD_TRIPLE)))
 	$(Q)$(call INSTALL,$(HL),$(PHL),$(CFG_RUNTIME_$(CFG_BUILD_TRIPLE)))
 	$(Q)$(call INSTALL,$(HL),$(PHL),$(CFG_RUSTLLVM_$(CFG_BUILD_TRIPLE)))
 	$(Q)$(call INSTALL,$(S)/man, \

branches/dist-snap/mk/platform.mk

@@ -239,31 +239,6 @@ CFG_RUN_arm-linux-androideabi=
 CFG_RUN_TARG_arm-linux-androideabi=
 RUSTC_FLAGS_arm-linux-androideabi :=--android-cross-path=$(CFG_ANDROID_CROSS_PATH)
 
-# mips-unknown-linux-gnu configuration
-CC_mips-unknown-linux-gnu=mips-linux-gnu-gcc
-CXX_mips-unknown-linux-gnu=mips-linux-gnu-g++
-CPP_mips-unknown-linux-gnu=mips-linux-gnu-gcc -E
-AR_mips-unknown-linux-gnu=mips-linux-gnu-ar
-CFG_LIB_NAME_mips-unknown-linux-gnu=lib$(1).so
-CFG_LIB_GLOB_mips-unknown-linux-gnu=lib$(1)-*.so
-CFG_LIB_DSYM_GLOB_mips-unknown-linux-gnu=lib$(1)-*.dylib.dSYM
-CFG_GCCISH_CFLAGS_mips-unknown-linux-gnu := -Wall -g -fPIC -mips32r2 -msoft-float -mabi=32
-CFG_GCCISH_CXXFLAGS_mips-unknown-linux-gnu := -fno-rtti
-CFG_GCCISH_LINK_FLAGS_mips-unknown-linux-gnu := -shared -fPIC -g -mips32r2 -msoft-float -mabi=32
-CFG_GCCISH_DEF_FLAG_mips-unknown-linux-gnu := -Wl,--export-dynamic,--dynamic-list=
-CFG_GCCISH_PRE_LIB_FLAGS_mips-unknown-linux-gnu := -Wl,-whole-archive
-CFG_GCCISH_POST_LIB_FLAGS_mips-unknown-linux-gnu := -Wl,-no-whole-archive -Wl,-znoexecstack
-CFG_DEF_SUFFIX_mips-unknown-linux-gnu := .linux.def
-CFG_INSTALL_NAME_mips-unknown-linux-gnu =
-CFG_LIBUV_LINK_FLAGS_mips-unknown-linux-gnu =
-CFG_EXE_SUFFIX_mips-unknown-linux-gnu :=
-CFG_WINDOWSY_mips-unknown-linux-gnu :=
-CFG_UNIXY_mips-unknown-linux-gnu := 1
-CFG_PATH_MUNGE_mips-unknown-linux-gnu := true
-CFG_LDPATH_mips-unknown-linux-gnu :=
-CFG_RUN_mips-unknown-linux-gnu=
-CFG_RUN_TARG_mips-unknown-linux-gnu=
-
 # i686-pc-mingw32 configuration
 CC_i686-pc-mingw32=$(CC)
 CXX_i686-pc-mingw32=$(CXX)

branches/dist-snap/mk/rt.mk

@@ -27,7 +27,6 @@
 LIBUV_FLAGS_i386 = -m32 -fPIC
 LIBUV_FLAGS_x86_64 = -m64 -fPIC
 LIBUV_FLAGS_arm = -fPIC -DANDROID -std=gnu99
-LIBUV_FLAGS_mips = -fPIC -mips32r2 -msoft-float -mabi=32
 
 # when we're doing a snapshot build, we intentionally degrade as many
 # features in libuv and the runtime as possible, to ease portability.
@@ -181,10 +180,6 @@ else
 $$(LIBUV_LIB_$(1)): $$(LIBUV_DEPS)
 	$$(Q)$$(MAKE) -C $$(S)src/libuv/ \
 		CFLAGS="$$(LIBUV_FLAGS_$$(HOST_$(1))) $$(SNAP_DEFINES)" \
-		LDFLAGS="$$(LIBUV_FLAGS_$$(HOST_$(1)))" \
-		CC="$$(CC_$(1))" \
-		CXX="$$(CXX_$(1))" \
-		AR="$$(AR_$(1))" \
 		builddir_name="$$(CFG_BUILD_DIR)/rt/$(1)/libuv" \
 		V=$$(VERBOSE)
 endif

branches/dist-snap/src/compiletest/compiletest.rc

@@ -17,8 +17,8 @@
 #[allow(deprecated_mode)];
 #[allow(deprecated_pattern)];
 
-extern mod core(vers = "0.7-rc");
-extern mod std(vers = "0.7-rc");
+extern mod core(vers = "0.6");
+extern mod std(vers = "0.6");
 
 use core::*;