---

yaml
---
r: 178138
b: refs/heads/tmp
c: 425f232
h: refs/heads/master
v: v3

Author: alexcrichton

[refs]

@@ -34,4 +34,4 @@ refs/heads/building: 126db549b038c84269a1e4fe46f051b2c15d6970
 refs/heads/beta: 44a287e6eb22ec3c2a687fc156813577464017f7
 refs/heads/windistfix: 7608dbad651f02e837ed05eef3d74a6662a6e928
 refs/tags/1.0.0-alpha: e42bd6d93a1d3433c486200587f8f9e12590a4d7
-refs/heads/tmp: f6414b0187bfc6e5b563a17c85a9f790d6257551
+refs/heads/tmp: 425f2328d0d6d2848a399424ab26dde4800edcf9

branches/tmp/COPYRIGHT

@@ -23,12 +23,12 @@ The following third party packages are included, and carry
 their own copyright notices and license terms:
 
 * Two header files that are part of the Valgrind
-  package. These files are found at src/rt/vg/valgrind.h and
-  src/rt/vg/memcheck.h, within this distribution. These files
+  package. These files are found at src/rt/valgrind/valgrind.h and
+  src/rt/valgrind/memcheck.h, within this distribution. These files
   are redistributed under the following terms, as noted in
   them:
 
-  for src/rt/vg/valgrind.h:
+  for src/rt/valgrind/valgrind.h:
 
     This file is part of Valgrind, a dynamic binary
     instrumentation framework.
@@ -74,7 +74,7 @@ their own copyright notices and license terms:
     USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY
     OF SUCH DAMAGE.
 
-  for src/rt/vg/memcheck.h:
+  for src/rt/valgrind/memcheck.h:
 
     This file is part of MemCheck, a heavyweight Valgrind
     tool for detecting memory errors.
@@ -120,18 +120,6 @@ their own copyright notices and license terms:
     USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY
     OF SUCH DAMAGE.
 
-* The auxiliary file src/etc/pkg/modpath.iss contains a
-  library routine compiled, by Inno Setup, into the Windows
-  installer binary. This file is licensed under the LGPL,
-  version 3, but, in our legal interpretation, this does not
-  affect the aggregate "collected work" license of the Rust
-  distribution (MIT/ASL2) nor any other components of it. We
-  believe that the terms governing distribution of the
-  binary Windows installer built from modpath.iss are
-  therefore LGPL, but not the terms governing distribution
-  of any of the files installed by such an installer (such
-  as the Rust compiler or runtime libraries themselves).
-
 * The src/rt/miniz.c file, carrying an implementation of
   RFC1950/RFC1951 DEFLATE, by Rich Geldreich
   <[email protected]>. All uses of this file are

branches/tmp/src/doc/intro.md

@@ -424,7 +424,7 @@ Let's see an example. This Rust code will not compile:
 use std::thread::Thread;
 
 fn main() {
-    let mut numbers = vec![1is, 2, 3];
+    let mut numbers = vec![1, 2, 3];
 
     for i in 0..3 {
         Thread::spawn(move || {
@@ -478,7 +478,7 @@ use std::thread::Thread;
 use std::sync::{Arc,Mutex};
 
 fn main() {
-    let numbers = Arc::new(Mutex::new(vec![1is, 2, 3]));
+    let numbers = Arc::new(Mutex::new(vec![1, 2, 3]));
 
     for i in 0us..3 {
         let number = numbers.clone();
@@ -539,7 +539,7 @@ safety check that makes this an error about moved values:
 use std::thread::Thread;
 
 fn main() {
-    let vec = vec![1is, 2, 3];
+    let vec = vec![1, 2, 3];
 
     for i in 0us..3 {
         Thread::spawn(move || {

branches/tmp/src/doc/reference.md

@@ -268,7 +268,7 @@ cases mentioned in [Number literals](#number-literals) below.
 ##### Suffixes
 | Integer | Floating-point |
 |---------|----------------|
-| `is` (`isize`), `us` (`usize`), `u8`, `i8`, `u16`, `i16`, `u32`, `i32`, `u64`, `i64` | `f32`, `f64` |
+| `u8`, `i8`, `u16`, `i16`, `u32`, `i32`, `u64`, `i64`, `is` (`isize`), `us` (`usize`) | `f32`, `f64` |
 
 #### Character and string literals
 
@@ -468,27 +468,29 @@ Like any literal, an integer literal may be followed (immediately,
 without any spaces) by an _integer suffix_, which forcibly sets the
 type of the literal. There are 10 valid values for an integer suffix:
 
-* The `is` and `us` suffixes give the literal type `isize` or `usize`,
-  respectively.
 * Each of the signed and unsigned machine types `u8`, `i8`,
   `u16`, `i16`, `u32`, `i32`, `u64` and `i64`
   give the literal the corresponding machine type.
+* The `is` and `us` suffixes give the literal type `isize` or `usize`,
+  respectively.
 
 The type of an _unsuffixed_ integer literal is determined by type inference.
 If an integer type can be _uniquely_ determined from the surrounding program
 context, the unsuffixed integer literal has that type. If the program context
-underconstrains the type, it is considered a static type error; if the program
-context overconstrains the type, it is also considered a static type error.
+underconstrains the type, it defaults to the signed 32-bit integer `i32`; if
+the program context overconstrains the type, it is considered a static type
+error.
 
 Examples of integer literals of various forms:
 
 ```
-123is;                             // type isize
-123us;                             // type usize
-123_us;                            // type usize
+123i32;                            // type i32
+123u32;                            // type u32
+123_u32;                           // type u32
 0xff_u8;                           // type u8
 0o70_i16;                          // type i16
 0b1111_1111_1001_0000_i32;         // type i32
+0us;                               // type usize
 ```
 
 ##### Floating-point literals
@@ -1135,8 +1137,8 @@ used as a type name.
 
 When a generic function is referenced, its type is instantiated based on the
 context of the reference. For example, calling the `iter` function defined
-above on `[1, 2]` will instantiate type parameter `T` with `isize`, and require
-the closure parameter to have type `fn(isize)`.
+above on `[1, 2]` will instantiate type parameter `T` with `i32`, and require
+the closure parameter to have type `fn(i32)`.
 
 The type parameters can also be explicitly supplied in a trailing
 [path](#paths) component after the function name. This might be necessary if
@@ -2747,9 +2749,9 @@ constant expression that can be evaluated at compile time, such as a
 [literal](#literals) or a [static item](#static-items).
 
 ```
-[1is, 2, 3, 4];
+[1, 2, 3, 4];
 ["a", "b", "c", "d"];
-[0is; 128];            // array with 128 zeros
+[0; 128];              // array with 128 zeros
 [0u8, 0u8, 0u8, 0u8];
 ```
 
@@ -2922,7 +2924,7 @@ moves](#moved-and-copied-types) its right-hand operand to its left-hand
 operand.
 
 ```
-# let mut x = 0is;
+# let mut x = 0;
 # let y = 0;
 
 x = y;
@@ -3308,11 +3310,11 @@ fn main() {
 ```
 
 Patterns can also dereference pointers by using the `&`, `&mut` and `box`
-symbols, as appropriate. For example, these two matches on `x: &isize` are
+symbols, as appropriate. For example, these two matches on `x: &i32` are
 equivalent:
 
 ```
-# let x = &3is;
+# let x = &3;
 let y = match *x { 0 => "zero", _ => "some" };
 let z = match x { &0 => "zero", _ => "some" };
 
@@ -3333,7 +3335,7 @@ Multiple match patterns may be joined with the `|` operator. A range of values
 may be specified with `...`. For example:
 
 ```
-# let x = 2is;
+# let x = 2;
 
 let message = match x {
   0 | 1  => "not many",
@@ -3674,16 +3676,16 @@ The type of a closure mapping an input of type `A` to an output of type `B` is
 An example of creating and calling a closure:
 
 ```rust
-let captured_var = 10is;
+let captured_var = 10;
 
 let closure_no_args = |&:| println!("captured_var={}", captured_var);
 
-let closure_args = |&: arg: isize| -> isize {
+let closure_args = |&: arg: i32| -> i32 {
   println!("captured_var={}, arg={}", captured_var, arg);
   arg // Note lack of semicolon after 'arg'
 };
 
-fn call_closure<F: Fn(), G: Fn(isize) -> isize>(c1: F, c2: G) {
+fn call_closure<F: Fn(), G: Fn(i32) -> i32>(c1: F, c2: G) {
   c1();
   c2(2);
 }
@@ -3715,7 +3717,7 @@ trait Printable {
   fn stringify(&self) -> String;
 }
 
-impl Printable for isize {
+impl Printable for i32 {
   fn stringify(&self) -> String { self.to_string() }
 }
 
@@ -3724,7 +3726,7 @@ fn print(a: Box<Printable>) {
 }
 
 fn main() {
-   print(Box::new(10is) as Box<Printable>);
+   print(Box::new(10) as Box<Printable>);
 }
 ```
 

branches/tmp/src/liballoc/arc.rs

@@ -39,7 +39,7 @@
 //!
 //! let five = Arc::new(5);
 //!
-//! for _ in 0u..10 {
+//! for _ in 0..10 {
 //!     let five = five.clone();
 //!
 //!     Thread::spawn(move || {
@@ -56,7 +56,7 @@
 //!
 //! let five = Arc::new(Mutex::new(5));
 //!
-//! for _ in 0u..10 {
+//! for _ in 0..10 {
 //!     let five = five.clone();
 //!
 //!     Thread::spawn(move || {
@@ -101,7 +101,7 @@ use heap::deallocate;
 ///     let numbers: Vec<_> = (0..100u32).map(|i| i as f32).collect();
 ///     let shared_numbers = Arc::new(numbers);
 ///
-///     for _ in 0u..10 {
+///     for _ in 0..10 {
 ///         let child_numbers = shared_numbers.clone();
 ///
 ///         Thread::spawn(move || {
@@ -661,7 +661,7 @@ mod tests {
 
     #[test]
     fn test_cowarc_clone_make_unique() {
-        let mut cow0 = Arc::new(75u);
+        let mut cow0 = Arc::new(75);
         let mut cow1 = cow0.clone();
         let mut cow2 = cow1.clone();
 
@@ -685,7 +685,7 @@ mod tests {
 
     #[test]
     fn test_cowarc_clone_unique2() {
-        let mut cow0 = Arc::new(75u);
+        let mut cow0 = Arc::new(75);
         let cow1 = cow0.clone();
         let cow2 = cow1.clone();
 
@@ -708,7 +708,7 @@ mod tests {
 
     #[test]
     fn test_cowarc_clone_weak() {
-        let mut cow0 = Arc::new(75u);
+        let mut cow0 = Arc::new(75);
         let cow1_weak = cow0.downgrade();
 
         assert!(75 == *cow0);

branches/tmp/src/liballoc/boxed.rs

@@ -102,6 +102,52 @@ impl<T> Box<T> {
     }
 }
 
+impl<T : ?Sized> Box<T> {
+    /// Constructs a box from the raw pointer.
+    ///
+    /// After this function call, pointer is owned by resulting box.
+    /// In particular, it means that `Box` destructor calls destructor
+    /// of `T` and releases memory. Since the way `Box` allocates and
+    /// releases memory is unspecified, so the only valid pointer to
+    /// pass to this function is the one taken from another `Box` with
+    /// `box::into_raw` function.
+    ///
+    /// Function is unsafe, because improper use of this function may
+    /// lead to memory problems like double-free, for example if the
+    /// function is called twice on the same raw pointer.
+    #[unstable(feature = "alloc",
+               reason = "may be renamed or moved out of Box scope")]
+    pub unsafe fn from_raw(raw: *mut T) -> Self {
+        mem::transmute(raw)
+    }
+}
+
+/// Consumes the `Box`, returning the wrapped raw pointer.
+///
+/// After call to this function, caller is responsible for the memory
+/// previously managed by `Box`, in particular caller should properly
+/// destroy `T` and release memory. The proper way to do it is to
+/// convert pointer back to `Box` with `Box::from_raw` function, because
+/// `Box` does not specify, how memory is allocated.
+///
+/// Function is unsafe, because result of this function is no longer
+/// automatically managed that may lead to memory or other resource
+/// leak.
+///
+/// # Example
+/// ```
+/// use std::boxed;
+///
+/// let seventeen = Box::new(17u32);
+/// let raw = unsafe { boxed::into_raw(seventeen) };
+/// let boxed_again = unsafe { Box::from_raw(raw) };
+/// ```
+#[unstable(feature = "alloc",
+           reason = "may be renamed")]
+pub unsafe fn into_raw<T : ?Sized>(b: Box<T>) -> *mut T {
+    mem::transmute(b)
+}
+
 #[stable(feature = "rust1", since = "1.0.0")]
 impl<T: Default> Default for Box<T> {
     #[stable(feature = "rust1", since = "1.0.0")]