---

yaml
---
r: 60343
b: refs/heads/master
c: 5af8646
h: refs/heads/master
i:
  60341: 371ef8b
  60339: 4a4746c
  60335: b25ae8c
v: v3

Author: brson

[refs]

@@ -1,5 +1,5 @@
 ---
-refs/heads/master: 729708d1124bc7318b98b69aadca987e7fe80a8d
+refs/heads/master: 5af8646a8b6caf0bc71fb258225ba4f814152c1d
 refs/heads/snap-stage1: e33de59e47c5076a89eadeb38f4934f58a3618a6
 refs/heads/snap-stage3: 2d28d645422c1617be58c8ca7ad9a457264ca850
 refs/heads/try: c50a9d5b664478e533ba1d1d353213d70c8ad589

trunk/configure

@@ -695,9 +695,6 @@ do
             # host lib dir
             make_dir $h/stage$i/$CFG_LIBDIR
 
-            # host test dir
-            make_dir $h/stage$i/test
-
             # target bin dir
             make_dir $h/stage$i/$CFG_LIBDIR/rustc/$t/bin
 

trunk/doc/rust.md

@@ -618,7 +618,7 @@ each of which may have some number of [attributes](#attributes) attached to it.
 
 ~~~~~~~~ {.ebnf .gram}
 item : mod_item | fn_item | type_item | struct_item | enum_item
-     | static_item | trait_item | impl_item | extern_block ;
+     | 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
@@ -752,11 +752,10 @@ link_attr : ident '=' literal ;
 ~~~~~~~~
 
 An _`extern mod` declaration_ specifies a dependency on an external crate.
-The external crate is then bound into the declaring scope
-as the `ident` provided in the `extern_mod_decl`.
+The external crate is then bound into the declaring scope as the `ident` provided in the `extern_mod_decl`.
 
-The external crate is resolved to a specific `soname` at compile time,
-and a runtime linkage requirement to that `soname` is passed to the linker for
+The external crate is resolved to a specific `soname` at compile time, and a
+runtime linkage requirement to that `soname` is passed to the linker for
 loading at runtime. The `soname` is resolved at compile time by scanning the
 compiler's library path and matching the `link_attrs` provided in the
 `use_decl` against any `#link` attributes that were declared on the external
@@ -993,10 +992,10 @@ Thus the return type on `f` only needs to reflect the `if` branch of the conditi
 #### Extern functions
 
 Extern functions are part of Rust's foreign function interface,
-providing the opposite functionality to [external blocks](#external-blocks).
-Whereas external blocks allow Rust code to call foreign code,
-extern functions with bodies defined in Rust code _can be called by foreign
-code_. They are defined in the same way as any other Rust function,
+providing the opposite functionality to [foreign modules](#foreign-modules).
+Whereas foreign modules allow Rust code to call foreign code,
+extern functions with bodies defined in Rust code _can be called by foreign code_.
+They are defined in the same way as any other Rust function,
 except that they have the `extern` modifier.
 
 ~~~
@@ -1012,8 +1011,7 @@ let fptr: *u8 = new_vec;
 ~~~
 
 The primary motivation for extern functions is
-to create callbacks for foreign functions that expect to receive function
-pointers.
+to create callbacks for foreign functions that expect to receive function pointers.
 
 ### Type definitions
 
@@ -1310,61 +1308,64 @@ impl Seq<bool> for u32 {
 }
 ~~~~
 
-### External blocks
+### Foreign modules
 
 ~~~ {.ebnf .gram}
-extern_block_item : "extern" '{' extern_block '} ;
-extern_block : [ foreign_fn ] * ;
+foreign_mod_item : "extern mod" ident '{' foreign_mod '} ;
+foreign_mod : [ foreign_fn ] * ;
 ~~~
 
-External blocks form the basis for Rust's foreign function interface.
-Declarations in an external block describe symbols
-in external, non-Rust libraries.
-
-Functions within external blocks
-are declared in the same way as other Rust functions,
-with the exception that they may not have a body
-and are instead terminated by a semicolon.
+Foreign modules form the basis for Rust's foreign function interface. A
+foreign module describes functions in external, non-Rust
+libraries.
+Functions within foreign modules are declared in the same way as other Rust functions,
+with the exception that they may not have a body and are instead terminated by a semicolon.
 
 ~~~
 # use core::libc::{c_char, FILE};
 # #[nolink]
 
-extern {
+extern mod c {
     fn fopen(filename: *c_char, mode: *c_char) -> *FILE;
 }
 ~~~
 
-Functions within external blocks may be called by Rust code,
-just like functions defined in Rust.
-The Rust compiler automatically translates
-between the Rust ABI and the foreign ABI.
+Functions within foreign modules may be called by Rust code, just like functions defined in Rust.
+The Rust compiler automatically translates between the Rust ABI and the foreign ABI.
+
+The name of the foreign module has special meaning to the Rust compiler in
+that it will treat the module name as the name of a library to link to,
+performing the linking as appropriate for the target platform. The name
+given for the foreign module will be transformed in a platform-specific way
+to determine the name of the library. For example, on Linux the name of the
+foreign module is prefixed with 'lib' and suffixed with '.so', so the
+foreign mod 'rustrt' would be linked to a library named 'librustrt.so'.
 
-A number of [attributes](#attributes) control the behavior of external
-blocks.
+A number of [attributes](#attributes) control the behavior of foreign
+modules.
 
-By default external blocks assume
-that the library they are calling uses the standard C "cdecl" ABI.
-Other ABIs may be specified using the `abi` attribute as in
+By default foreign modules assume that the library they are calling use the
+standard C "cdecl" ABI. Other ABIs may be specified using the `abi`
+attribute as in
 
 ~~~{.xfail-test}
 // Interface to the Windows API
 #[abi = "stdcall"]
-extern { }
+extern mod kernel32 { }
 ~~~
 
-The `link_name` attribute allows the name of the library to be specified.
+The `link_name` attribute allows the default library naming behavior to
+be overridden by explicitly specifying the name of the library.
 
 ~~~{.xfail-test}
 #[link_name = "crypto"]
-extern { }
+extern mod mycrypto { }
 ~~~
 
-The `nolink` attribute tells the Rust compiler
-not to do any linking for the external block.
-This is particularly useful for creating external blocks for libc,
-which tends to not follow standard library naming conventions
-and is linked to all Rust programs anyway.
+The `nolink` attribute tells the Rust compiler not to do any linking for the foreign module.
+This is particularly useful for creating foreign
+modules for libc, which tends to not follow standard library naming
+conventions and is linked to all Rust programs anyway.
 
 ## Attributes
 
@@ -2386,9 +2387,9 @@ enum List<X> { Nil, Cons(X, @List<X>) }
 let x: List<int> = Cons(10, @Cons(11, @Nil));
 
 match x {
-    Cons(_, @Nil) => fail!("singleton list"),
+    Cons(_, @Nil) => fail!(~"singleton list"),
     Cons(*)       => return,
-    Nil           => fail!("empty list")
+    Nil           => fail!(~"empty list")
 }
 ~~~~
 

trunk/doc/tutorial-borrowed-ptr.md

@@ -42,14 +42,14 @@ point, but allocated in a different place:
 ~~~
 # struct Point {x: float, y: float}
 let on_the_stack :  Point =  Point {x: 3.0, y: 4.0};
-let managed_box  : @Point = @Point {x: 5.0, y: 1.0};
-let owned_box    : ~Point = ~Point {x: 7.0, y: 9.0};
+let shared_box   : @Point = @Point {x: 5.0, y: 1.0};
+let unique_box   : ~Point = ~Point {x: 7.0, y: 9.0};
 ~~~
 
 Suppose we wanted to write a procedure that computed the distance between any
 two points, no matter where they were stored. For example, we might like to
-compute the distance between `on_the_stack` and `managed_box`, or between
-`managed_box` and `owned_box`. One option is to define a function that takes
+compute the distance between `on_the_stack` and `shared_box`, or between
+`shared_box` and `unique_box`. One option is to define a function that takes
 two arguments of type `Point`—that is, it takes the points by value. But if we
 define it this way, calling the function will cause the points to be
 copied. For points, this is probably not so bad, but often copies are
@@ -73,11 +73,11 @@ Now we can call `compute_distance()` in various ways:
 ~~~
 # struct Point {x: float, y: float}
 # let on_the_stack :  Point =  Point{x: 3.0, y: 4.0};
-# let managed_box  : @Point = @Point{x: 5.0, y: 1.0};
-# let owned_box    : ~Point = ~Point{x: 7.0, y: 9.0};
+# let shared_box   : @Point = @Point{x: 5.0, y: 1.0};
+# let unique_box   : ~Point = ~Point{x: 7.0, y: 9.0};
 # fn compute_distance(p1: &Point, p2: &Point) -> float { 0f }
-compute_distance(&on_the_stack, managed_box);
-compute_distance(managed_box, owned_box);
+compute_distance(&on_the_stack, shared_box);
+compute_distance(shared_box, unique_box);
 ~~~
 
 Here, the `&` operator takes the address of the variable
@@ -87,11 +87,11 @@ value. We also call this _borrowing_ the local variable
 `on_the_stack`, because we have created an alias: that is, another
 name for the same data.
 
-In contrast, we can pass the boxes `managed_box` and `owned_box` to
+In contrast, we can pass the boxes `shared_box` and `unique_box` to
 `compute_distance` directly. The compiler automatically converts a box like
 `@Point` or `~Point` to a borrowed pointer like `&Point`. This is another form
-of borrowing: in this case, the caller lends the contents of the managed or
-owned box to the callee.
+of borrowing: in this case, the caller lends the contents of the shared or
+unique box to the callee.
 
 Whenever a caller lends data to a callee, there are some limitations on what
 the caller can do with the original. For example, if the contents of a
@@ -155,7 +155,7 @@ let rect_stack   = &Rectangle {origin: Point {x: 1f, y: 2f},
                                size: Size {w: 3f, h: 4f}};
 let rect_managed = @Rectangle {origin: Point {x: 3f, y: 4f},
                                size: Size {w: 3f, h: 4f}};
-let rect_owned   = ~Rectangle {origin: Point {x: 5f, y: 6f},
+let rect_unique  = ~Rectangle {origin: Point {x: 5f, y: 6f},
                                size: Size {w: 3f, h: 4f}};
 ~~~
 
@@ -168,7 +168,7 @@ operator. For example, I could write:
 # struct Rectangle {origin: Point, size: Size}
 # let rect_stack  = &Rectangle {origin: Point {x: 1f, y: 2f}, size: Size {w: 3f, h: 4f}};
 # let rect_managed = @Rectangle {origin: Point {x: 3f, y: 4f}, size: Size {w: 3f, h: 4f}};
-# let rect_owned = ~Rectangle {origin: Point {x: 5f, y: 6f}, size: Size {w: 3f, h: 4f}};
+# let rect_unique = ~Rectangle {origin: Point {x: 5f, y: 6f}, size: Size {w: 3f, h: 4f}};
 # fn compute_distance(p1: &Point, p2: &Point) -> float { 0f }
 compute_distance(&rect_stack.origin, &rect_managed.origin);
 ~~~
@@ -179,7 +179,7 @@ as well as from the managed box, and then compute the distance between them.
 # Borrowing managed boxes and rooting
 
 We’ve seen a few examples so far of borrowing heap boxes, both managed
-and owned. Up till this point, we’ve glossed over issues of
+and unique. Up till this point, we’ve glossed over issues of
 safety. As stated in the introduction, at runtime a borrowed pointer
 is simply a pointer, nothing more. Therefore, avoiding C's problems
 with dangling pointers requires a compile-time safety check.
@@ -258,18 +258,18 @@ fn example2() {
 Now if `x` is reassigned, the pointer `y` will still remain valid. This
 process is called *rooting*.
 
-# Borrowing owned boxes
+# Borrowing unique boxes
 
 The previous example demonstrated *rooting*, the process by which the
 compiler ensures that managed boxes remain live for the duration of a
-borrow. Unfortunately, rooting does not work for borrows of owned
-boxes, because it is not possible to have two references to a owned
+borrow. Unfortunately, rooting does not work for borrows of unique
+boxes, because it is not possible to have two references to a unique
 box.
 
-For owned boxes, therefore, the compiler will only allow a borrow *if
-the compiler can guarantee that the owned box will not be reassigned
+For unique boxes, therefore, the compiler will only allow a borrow *if
+the compiler can guarantee that the unique box will not be reassigned
 or moved for the lifetime of the pointer*. This does not necessarily
-mean that the owned box is stored in immutable memory. For example,
+mean that the unique box is stored in immutable memory. For example,
 the following function is legal:
 
 ~~~
@@ -294,7 +294,7 @@ and `x` is declared as mutable. However, the compiler can prove that
 and in fact is mutated later in the function.
 
 It may not be clear why we are so concerned about mutating a borrowed
-variable. The reason is that the runtime system frees any owned box
+variable. The reason is that the runtime system frees any unique box
 _as soon as its owning reference changes or goes out of
 scope_. Therefore, a program like this is illegal (and would be
 rejected by the compiler):
@@ -342,7 +342,7 @@ which has been freed.
 
 In fact, the compiler can apply the same kind of reasoning to any
 memory that is _(uniquely) owned by the stack frame_. So we could
-modify the previous example to introduce additional owned pointers
+modify the previous example to introduce additional unique pointers
 and structs, and the compiler will still be able to detect possible
 mutations:
 
@@ -366,7 +366,7 @@ invalidate the pointer `y`.
 # Borrowing and enums
 
 The previous example showed that the type system forbids any borrowing
-of owned boxes found in aliasable, mutable memory. This restriction
+of unique boxes found in aliasable, mutable memory. This restriction
 prevents pointers from pointing into freed memory. There is one other
 case where the compiler must be very careful to ensure that pointers
 remain valid: pointers into the interior of an `enum`.
@@ -462,14 +462,14 @@ of a `float` as if it were a struct with two fields would be a memory
 safety violation.
 
 So, in fact, for every `ref` binding, the compiler will impose the
-same rules as the ones we saw for borrowing the interior of a owned
+same rules as the ones we saw for borrowing the interior of a unique
 box: it must be able to guarantee that the `enum` will not be
 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 `&mut Shape`, then the ref binding would be ill-typed.
-Just as with owned boxes, the compiler will permit `ref` bindings
+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.
 
@@ -550,7 +550,7 @@ guarantees; in fact, it cannot guarantee that the pointer will remain
 valid at all once it returns, as the parameter `p` may or may not be
 live in the caller. Therefore, the compiler will report an error here.
 
-In general, if you borrow a managed (or owned) box to create a
+In general, if you borrow a managed (or unique) box to create a
 borrowed pointer, the pointer will only be valid within the function
 and cannot be returned. This is why the typical way to return borrowed
 pointers is to take borrowed pointers as input (the only other case in

trunk/doc/tutorial-ffi.md

@@ -237,8 +237,7 @@ convention to use:
 ~~~~
 #[cfg(target_os = "win32")]
 #[abi = "stdcall"]
-#[link_name = "kernel32"]
-extern {
+extern mod kernel32 {
     fn SetEnvironmentVariableA(n: *u8, v: *u8) -> int;
 }
 ~~~~

trunk/doc/tutorial-macros.md

@@ -223,7 +223,7 @@ match x {
                 // complicated stuff goes here
                 return result + val;
             },
-            _ => fail!("Didn't get good_2")
+            _ => fail!(~"Didn't get good_2")
         }
     }
     _ => return 0 // default value
@@ -265,7 +265,7 @@ macro_rules! biased_match (
 biased_match!((x)       ~ (good_1(g1, val)) else { return 0 };
               binds g1, val )
 biased_match!((g1.body) ~ (good_2(result) )
-                  else { fail!("Didn't get good_2") };
+                  else { fail!(~"Didn't get good_2") };
               binds result )
 // complicated stuff goes here
 return result + val;
@@ -366,7 +366,7 @@ macro_rules! biased_match (
 # fn f(x: t1) -> uint {
 biased_match!(
     (x)       ~ (good_1(g1, val)) else { return 0 };
-    (g1.body) ~ (good_2(result) ) else { fail!("Didn't get good_2") };
+    (g1.body) ~ (good_2(result) ) else { fail!(~"Didn't get good_2") };
     binds val, result )
 // complicated stuff goes here
 return result + val;

trunk/doc/tutorial-tasks.md

@@ -325,7 +325,7 @@ let result: Result<int, ()> = do task::try {
     if some_condition() {
         calculate_result()
     } else {
-        fail!("oops!");
+        fail!(~"oops!");
     }
 };
 assert!(result.is_err());

trunk/doc/tutorial.md

@@ -1779,7 +1779,7 @@ to a borrowed pointer.
 #    fn draw_value(self) { ... }
 # }
 # let s = Circle(Point { x: 1f, y: 2f }, 3f);
-// As with typical function arguments, managed and owned pointers
+// As with typical function arguments, managed and unique pointers
 // are automatically converted to borrowed pointers
 
 (@s).draw_borrowed();