---

yaml
---
r: 110227
b: refs/heads/try
c: 080d210
h: refs/heads/master
i:
  110225: 27202e1
  110223: 453e8bc
v: v3

Author: brson

[refs]

@@ -2,7 +2,7 @@
 refs/heads/master: e415c25bcd81dc1f9a5a3d25d9b48ed2d545336b
 refs/heads/snap-stage1: e33de59e47c5076a89eadeb38f4934f58a3618a6
 refs/heads/snap-stage3: c7fac4471201977fdb1c0c0a26c87287e12dc644
-refs/heads/try: f64fdf524a434f0e5cd0bc91d09c144723f3c90d
+refs/heads/try: 080d2104ff3b1637f919129bc40a99203a198a08
 refs/tags/release-0.1: 1f5c5126e96c79d22cb7862f75304136e204f105
 refs/heads/ndm: f3868061cd7988080c30d6d5bf352a5a5fe2460b
 refs/heads/try2: 147ecfdd8221e4a4d4e090486829a06da1e0ca3c

branches/try/Makefile.in

@@ -177,10 +177,10 @@ include config.mk
 
 # Just a few macros used everywhere
 include $(CFG_SRC_DIR)mk/util.mk
-# Reconfiguring when the makefiles or submodules change
-include $(CFG_SRC_DIR)mk/reconfig.mk
 # All crates and their dependencies
 include $(CFG_SRC_DIR)mk/crates.mk
+# Reconfiguring when the makefiles or submodules change
+include $(CFG_SRC_DIR)mk/reconfig.mk
 # Various bits of setup, common macros, and top-level rules
 include $(CFG_SRC_DIR)mk/main.mk
 # C and assembly components that are not LLVM

branches/try/mk/crates.mk

@@ -49,14 +49,14 @@
 # automatically generated for all stage/host/target combinations.
 ################################################################################
 
-TARGET_CRATES := libc std green rustuv native flate arena glob term semver \
+TARGET_CRATES := std green rustuv native flate arena glob term semver \
                  uuid serialize sync getopts collections num test time rand \
 		 workcache url log
 HOST_CRATES := syntax rustc rustdoc fourcc hexfloat
 CRATES := $(TARGET_CRATES) $(HOST_CRATES)
 TOOLS := compiletest rustdoc rustc
 
-DEPS_std := libc native:rustrt native:compiler-rt native:backtrace
+DEPS_std := native:rustrt native:compiler-rt native:backtrace
 DEPS_green := std rand native:context_switch
 DEPS_rustuv := std native:uv native:uv_support
 DEPS_native := std
@@ -105,7 +105,8 @@ COMPILER_DOC_CRATES := rustc syntax
 # $(1) is the crate to generate variables for
 define RUST_CRATE
 CRATEFILE_$(1) := $$(S)src/lib$(1)/lib.rs
-RSINPUTS_$(1) := $$(call rwildcard,$(S)src/lib$(1)/,*.rs)
+RSINPUTS_$(1) := $$(wildcard $$(addprefix $(S)src/lib$(1), \
+				*.rs */*.rs */*/*.rs */*/*/*.rs))
 RUST_DEPS_$(1) := $$(filter-out native:%,$$(DEPS_$(1)))
 NATIVE_DEPS_$(1) := $$(patsubst native:%,%,$$(filter native:%,$$(DEPS_$(1))))
 endef
@@ -116,7 +117,8 @@ $(foreach crate,$(CRATES),$(eval $(call RUST_CRATE,$(crate))))
 #
 # $(1) is the crate to generate variables for
 define RUST_TOOL
-TOOL_INPUTS_$(1) := $$(call rwildcard,$$(dir $$(TOOL_SOURCE_$(1))),*.rs)
+TOOL_INPUTS_$(1) := $$(wildcard $$(addprefix $$(dir $$(TOOL_SOURCE_$(1))), \
+				*.rs */*.rs */*/*.rs */*/*/*.rs))
 endef
 
 $(foreach crate,$(TOOLS),$(eval $(call RUST_TOOL,$(crate))))

branches/try/mk/rt.mk

@@ -215,6 +215,7 @@ $$(LIBUV_DIR_$(1))/Release/libuv.a: $$(LIBUV_DEPS) $$(LIBUV_MAKEFILE_$(1)) \
 		BUILDTYPE=Release \
 		NO_LOAD="$$(LIBUV_NO_LOAD)" \
 		V=$$(VERBOSE)
+	$$(Q)touch $$@
 
 endif
 

branches/try/src/compiletest/compiletest.rs

@@ -43,9 +43,7 @@ pub mod common;
 pub mod errors;
 
 #[start]
-fn start(argc: int, argv: **u8) -> int {
-    green::start(argc, argv, rustuv::event_loop, main)
-}
+fn start(argc: int, argv: **u8) -> int { green::start(argc, argv, main) }
 
 pub fn main() {
     let args = os::args();

branches/try/src/doc/guide-ffi.md

@@ -12,8 +12,7 @@ The following is a minimal example of calling a foreign function which will
 compile if snappy is installed:
 
 ~~~~ {.ignore}
-extern crate libc;
-use libc::size_t;
+use std::libc::size_t;
 
 #[link(name = "snappy")]
 extern {
@@ -45,8 +44,7 @@ keeping the binding correct at runtime.
 The `extern` block can be extended to cover the entire snappy API:
 
 ~~~~ {.ignore}
-extern crate libc;
-use libc::{c_int, size_t};
+use std::libc::{c_int, size_t};
 
 #[link(name = "snappy")]
 extern {
@@ -404,7 +402,7 @@ global state. In order to access these variables, you declare them in `extern`
 blocks with the `static` keyword:
 
 ~~~{.ignore}
-extern crate libc;
+use std::libc;
 
 #[link(name = "readline")]
 extern {
@@ -422,7 +420,7 @@ interface. To do this, statics can be declared with `mut` so rust can mutate
 them.
 
 ~~~{.ignore}
-extern crate libc;
+use std::libc;
 use std::ptr;
 
 #[link(name = "readline")]
@@ -446,15 +444,11 @@ calling foreign functions. Some foreign functions, most notably the Windows API,
 conventions. Rust provides a way to tell the compiler which convention to use:
 
 ~~~~
-extern crate libc;
-
 #[cfg(target_os = "win32", target_arch = "x86")]
 #[link(name = "kernel32")]
 extern "stdcall" {
-    fn SetEnvironmentVariableA(n: *u8, v: *u8) -> libc::c_int;
+    fn SetEnvironmentVariableA(n: *u8, v: *u8) -> std::libc::c_int;
 }
-
-# fn main() { }
 ~~~~
 
 This applies to the entire `extern` block. The list of supported ABI constraints

branches/try/src/doc/guide-lifetimes.md

@@ -559,14 +559,9 @@ points at a static constant).
 
 # Named lifetimes
 
-Lifetimes can be named and referenced. For example, the special lifetime
-`'static`, which does not go out of scope, can be used to create global
-variables and communicate between tasks (see the manual for usecases).
-
-## Parameter Lifetimes
-
-Named lifetimes allow for grouping of parameters by lifetime.
-For example, consider this function:
+Let's look at named lifetimes in more detail. Named lifetimes allow
+for grouping of parameters by lifetime. For example, consider this
+function:
 
 ~~~
 # struct Point {x: f64, y: f64}; // as before
@@ -660,25 +655,6 @@ fn select<'r, T>(shape: &Shape, threshold: f64,
 
 This is equivalent to the previous definition.
 
-## Labeled Control Structures
-
-Named lifetime notation can also be used to control the flow of execution:
-
-~~~
-'h: for i in range(0,10) {
-    'g: loop {
-        if i % 2 == 0 { continue 'h; }
-        if i == 9 { break 'h; }
-        break 'g;
-    }
-}
-~~~
-
-> ***Note:*** Labelled breaks are not currently supported within `while` loops.
-
-Named labels are hygienic and can be used safely within macros.
-See the macros guide section on hygiene for more details.
-
 # Conclusion
 
 So there you have it: a (relatively) brief tour of the lifetime

branches/try/src/doc/guide-macros.md

@@ -398,38 +398,6 @@ position (in particular, not as an argument to yet another macro invocation),
 the expander will then proceed to evaluate `m2!()` (along with any other macro
 invocations `m1!(m2!())` produced).
 
-# Hygiene
-
-To prevent clashes, rust implements
-[hygienic macros](http://en.wikipedia.org/wiki/Hygienic_macro).
-
-As an example, `loop` and `for-loop` labels (discussed in the lifetimes guide)
-will not clash. The following code will print "Hello!" only once:
-
-~~~
-#[feature(macro_rules)];
-
-macro_rules! loop_x (
-    ($e: expr) => (
-        // $e will not interact with this 'x
-        'x: loop {
-            println!("Hello!");
-            $e
-        }
-    );
-)
-
-fn main() {
-    'x: loop {
-        loop_x!(break 'x);
-        println!("I am never printed.");
-    }
-}
-~~~
-
-The two `'x` names did not clash, which would have caused the loop
-to print "I am never printed" and to run forever.
-
 # A final note
 
 Macros, as currently implemented, are not for the faint of heart. Even

branches/try/src/doc/guide-runtime.md

@@ -223,49 +223,27 @@ Having a default decision made in the compiler is done out of necessity and
 convenience. The compiler's decision of runtime to link to is *not* an
 endorsement of one over the other. As always, this decision can be overridden.
 
-For example, this program will be linked to "the default runtime". The current
-default runtime is to use libnative.
+For example, this program will be linked to "the default runtime"
 
 ~~~{.rust}
 fn main() {}
 ~~~
 
-### Force booting with libgreen
-
-In this example, the `main` function will be booted with I/O support powered by
-libuv. This is done by linking to the `rustuv` crate and specifying the
-`rustuv::event_loop` function as the event loop factory.
-
-To create a pool of green tasks which have no I/O support, you may shed the
-`rustuv` dependency and use the `green::basic::event_loop` function instead of
-`rustuv::event_loop`. All tasks will have no I/O support, but they will still be
-able to deschedule/reschedule (use channels, locks, etc).
+Whereas this program explicitly opts into using a particular runtime
 
 ~~~{.rust}
 extern crate green;
-extern crate rustuv;
 
 #[start]
 fn start(argc: int, argv: **u8) -> int {
-    green::start(argc, argv, rustuv::event_loop, main)
+    green::start(argc, argv, main)
 }
 
 fn main() {}
 ~~~
 
-### Force booting with libnative
-
-This program's `main` function will always be booted with libnative, running
-inside of an OS thread.
-
-~~~{.rust}
-extern crate native;
-
-#[start]
-fn start(argc: int, argv: **u8) -> int { native::start(argc, argv, main) }
-
-fn main() {}
-~~~
+Both libgreen/libnative provide a top-level `start` function which is used to
+boot an initial Rust task in that specified runtime.
 
 # Finding the runtime
 

branches/try/src/doc/guide-unsafe.md

@@ -192,8 +192,7 @@ As an example, we give a reimplementation of owned boxes by wrapping
 reimplementation is as safe as the built-in `~` type.
 
 ```
-extern crate libc;
-use libc::{c_void, size_t, malloc, free};
+use std::libc::{c_void, size_t, malloc, free};
 use std::mem;
 use std::ptr;
 

branches/try/src/doc/index.md

@@ -36,7 +36,6 @@ li {list-style-type: none; }
 * [The `glob` file path matching library](glob/index.html)
 * [The `green` M:N runtime library](green/index.html)
 * [The `hexfloat` library for hexadecimal floating-point literals](hexfloat/index.html)
-* [The `libc` bindings](libc/index.html)
 * [The `native` 1:1 threading runtime](native/index.html)
 * [The `num` arbitrary precision numerics library](num/index.html)
 * [The `rand` library for random numbers and distributions](rand/index.html)

branches/try/src/doc/rust.md

@@ -1471,13 +1471,11 @@ with the exception that they may not have a body
 and are instead terminated by a semicolon.
 
 ~~~~
-extern crate libc;
-use libc::{c_char, FILE};
+# use std::libc::{c_char, FILE};
 
 extern {
     fn fopen(filename: *c_char, mode: *c_char) -> *FILE;
 }
-# fn main() {}
 ~~~~
 
 Functions within external blocks may be called by Rust code,

branches/try/src/doc/tutorial.md

@@ -2103,8 +2103,7 @@ a `&T` pointer. `MutexArc` is an example of a *sharable* type with internal muta
 These are types that do not contain any data whose lifetime is bound to
 a particular stack frame. These are types that do not contain any
 references, or types where the only contained references
-have the `'static` lifetime. (For more on named lifetimes and their uses,
-see the [references and lifetimes guide][lifetimes].)
+have the `'static` lifetime.
 
 > ***Note:*** These two traits were referred to as 'kinds' in earlier
 > iterations of the language, and often still are.
@@ -2430,25 +2429,23 @@ select the method to call at runtime.
 
 This usage of traits is similar to Java interfaces.
 
-There are some built-in bounds, such as `Send` and `Share`, which are properties
-of the components of types. By design, trait objects don't know the exact type
-of their contents and so the compiler cannot reason about those properties.
+By default, each of the three storage classes for traits enforce a
+particular set of built-in kinds that their contents must fulfill in
+order to be packaged up in a trait object of that storage class.
 
-You can instruct the compiler, however, that the contents of a trait object must
-acribe to a particular bound with a trailing colon (`:`). These are examples of
-valid types:
+* The contents of owned traits (`~Trait`) must fulfill the `Send` bound.
+* The contents of reference traits (`&Trait`) are not constrained by any bound.
 
-~~~rust
-trait Foo {}
-trait Bar<T> {}
+Consequently, the trait objects themselves automatically fulfill their
+respective kind bounds. However, this default behavior can be overridden by
+specifying a list of bounds on the trait type, for example, by writing `~Trait:`
+(which indicates that the contents of the owned trait need not fulfill any
+bounds), or by writing `~Trait:Send+Share`, which indicates that in addition
+to fulfilling `Send`, contents must also fulfill `Share`, and as a consequence,
+the trait itself fulfills `Share`.
 
-fn sendable_foo(f: ~Foo:Send) { /* ... */ }
-fn shareable_bar<T: Share>(b: &Bar<T>: Share) { /* ... */ }
-~~~
-
-When no colon is specified (such as the type `~Foo`), it is inferred that the
-value ascribes to no bounds. They must be added manually if any bounds are
-necessary for usage.
+* `~Trait:Send` is equivalent to `~Trait`.
+* `&Trait:` is equivalent to `&Trait`.
 
 Builtin kind bounds can also be specified on closure types in the same way (for
 example, by writing `fn:Send()`), and the default behaviours are the same as

branches/try/src/etc/zsh/_rust

@@ -40,7 +40,7 @@ _rustc_opts_switches=(
 )
 _rustc_opts_lint=(
     'attribute-usage[detects bad use of attributes]'
-    'ctypes[proper use of libc types in foreign modules]'
+    'ctypes[proper use of std::libc types in foreign modules]'
     'dead-assignment[detect assignments that will never be read]'
     'dead-code[detect piece of code that will never be used]'
     'default-type-param-usage[prevents explicitly setting a type parameter with a default]'

branches/try/src/libcollections/dlist.rs

@@ -582,16 +582,16 @@ impl<A> DoubleEndedIterator<A> for MoveItems<A> {
 }
 
 impl<A> FromIterator<A> for DList<A> {
-    fn from_iterator<T: Iterator<A>>(iterator: T) -> DList<A> {
+    fn from_iterator<T: Iterator<A>>(iterator: &mut T) -> DList<A> {
         let mut ret = DList::new();
         ret.extend(iterator);
         ret
     }
 }
 
 impl<A> Extendable<A> for DList<A> {
-    fn extend<T: Iterator<A>>(&mut self, mut iterator: T) {
-        for elt in iterator { self.push_back(elt); }
+    fn extend<T: Iterator<A>>(&mut self, iterator: &mut T) {
+        for elt in *iterator { self.push_back(elt); }
     }
 }