---

yaml
---
r: 129022
b: refs/heads/auto
c: 08a3453
h: refs/heads/master
v: v3

Author: vhbit

[refs]

@@ -13,7 +13,7 @@ refs/heads/try3: 9387340aab40a73e8424c48fd42f0c521a4875c0
 refs/tags/release-0.3.1: 495bae036dfe5ec6ceafd3312b4dca48741e845b
 refs/tags/release-0.4: e828ea2080499553b97dfe33b3f4d472b4562ad7
 refs/tags/release-0.5: 7e3bcfbf21278251ee936ad53e92e9b719702d73
-refs/heads/auto: 5fe5e3947bc1dbc7551941aedcd01ec4e45fb00d
+refs/heads/auto: 08a34531111ce02e0db9c7deed291f65508593bd
 refs/heads/servo: af82457af293e2a842ba6b7759b70288da276167
 refs/tags/release-0.6: b4ebcfa1812664df5e142f0134a5faea3918544c
 refs/tags/0.1: b19db808c2793fe2976759b85a355c3ad8c8b336

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

@@ -263,13 +263,12 @@ Rust code:
 
 ~~~~no_run
 
-#[repr(C)]
 struct RustObject {
     a: i32,
     // other members
 }
 
-extern "C" fn callback(target: *mut RustObject, a:i32) {
+extern fn callback(target: *mut RustObject, a:i32) {
     println!("I'm called from C with value {0}", a);
     unsafe {
         // Update the value in RustObject with the value received from the callback
@@ -507,16 +506,16 @@ to define a block for all windows systems, not just x86 ones.
 
 # Interoperability with foreign code
 
-Rust guarantees that the layout of a `struct` is compatible with the platform's representation in C
-only if the `#[repr(C)]` attribute is applied to it.  `#[repr(C, packed)]` can be used to lay out
-struct members without padding.  `#[repr(C)]` can also be applied to an enum.
+Rust guarantees that the layout of a `struct` is compatible with the platform's representation in C.
+A `#[packed]` attribute is available, which will lay out the struct members without padding.
+However, there are currently no guarantees about the layout of an `enum`.
 
-Rust's owned boxes (`Box<T>`) use non-nullable pointers as handles which point to the contained
+Rust's owned and managed boxes use non-nullable pointers as handles which point to the contained
 object. However, they should not be manually created because they are managed by internal
-allocators. References can safely be assumed to be non-nullable pointers directly to the type.
-However, breaking the borrow checking or mutability rules is not guaranteed to be safe, so prefer
-using raw pointers (`*`) if that's needed because the compiler can't make as many assumptions about
-them.
+allocators. References can safely be assumed to be non-nullable pointers directly to the
+type. However, breaking the borrow checking or mutability rules is not guaranteed to be safe, so
+prefer using raw pointers (`*`) if that's needed because the compiler can't make as many assumptions
+about them.
 
 Vectors and strings share the same basic memory layout, and utilities are available in the `vec` and
 `str` modules for working with C APIs. However, strings are not terminated with `\0`. If you need a

branches/auto/src/doc/guide.md

@@ -1073,8 +1073,8 @@ destructuring `let`.
 ## Enums
 
 Finally, Rust has a "sum type", an **enum**. Enums are an incredibly useful
-feature of Rust, and are used throughout the standard library. This is an enum
-that is provided by the Rust standard library:
+feature of Rust, and are used throughout the standard library. Enums look
+like this:
 
 ```{rust}
 enum Ordering {
@@ -1084,8 +1084,9 @@ enum Ordering {
 }
 ```
 
-An `Ordering` can only be _one_ of `Less`, `Equal`, or `Greater` at any given
-time. Here's an example:
+This is an enum that is provided by the Rust standard library. An `Ordering`
+can only be _one_ of `Less`, `Equal`, or `Greater` at any given time. Here's
+an example:
 
 ```{rust}
 fn cmp(a: int, b: int) -> Ordering {
@@ -3667,173 +3668,6 @@ In order to truly understand this error, we have to learn a few new concepts:
 
 ## Ownership, borrowing, and lifetimes
 
-Whenever a resource of some kind is created, something must be responsible
-for destroying that resource as well. Given that we're discussing pointers
-right now, let's discuss this in the context of memory allocation, though
-it applies to other resources as well.
-
-When you allocate heap memory, you need a mechanism to free that memory.  Many
-languages let the programmer control the allocation, and then use a garbage
-collector to handle the deallocation. This is a valid, time-tested strategy,
-but it's not without its drawbacks. Because the programmer does not have to
-think as much about deallocation, allocation becomes something commonplace,
-because it's easy. And if you need precise control over when something is
-deallocated, leaving it up to your runtime can make this difficult.
-
-Rust chooses a different path, and that path is called **ownership**. Any
-binding that creates a resource is the **owner** of that resource.  Being an
-owner gives you three privileges, with two restrictions:
-
-1. You control when that resource is deallocated.
-2. You may lend that resource, immutably, to as many borrowers as you'd like.
-3. You may lend that resource, mutably, to a single borrower. **BUT**
-4. Once you've done so, you may not also lend it out otherwise, mutably or
-   immutably.
-5. You may not lend it out mutably if you're currently lending it to someone.
-
-What's up with all this 'lending' and 'borrowing'? When you allocate memory,
-you get a pointer to that memory. This pointer allows you to manipulate said
-memory. If you are the owner of a pointer, then you may allow another
-binding to temporarily borrow that pointer, and then they can manipulate the
-memory. The length of time that the borrower is borrowing the pointer
-from you is called a **lifetime**.
-
-If two distinct bindings share a pointer, and the memory that pointer points to
-is immutable, then there are no problems. But if it's mutable, both pointers
-can attempt to write to the memory at the same time, causing a **race
-condition**. Therefore, if someone wants to mutate something that they've
-borrowed from you, you must not have lent out that pointer to anyone else.
-
-Rust has a sophisticated system called the **borrow checker** to make sure that
-everyone plays by these rules. At compile time, it verifies that none of these
-rules are broken. If there's no problem, our program compiles successfully, and
-there is no runtime overhead for any of this. The borrow checker works only at
-compile time. If the borrow checker did find a problem, it will report a
-**lifetime error**, and your program will refuse to compile.
-
-That's a lot to take in. It's also one of the _most_ important concepts in
-all of Rust. Let's see this syntax in action:
-
-```{rust}
-{ 
-    let x = 5i; // x is the owner of this integer, which is memory on the stack.
-
-    // other code here...
-   
-} // privilege 1: when x goes out of scope, this memory is deallocated
-
-/// this function borrows an integer. It's given back automatically when the
-/// function returns.
-fn foo(x: &int) -> &int { x } 
-
-{ 
-    let x = 5i; // x is the owner of this integer, which is memory on the stack.
-
-    // privilege 2: you may lend that resource, to as many borrowers as you'd like
-    let y = &x;
-    let z = &x;
-
-    foo(&x); // functions can borrow too!
-
-    let a = &x; // we can do this alllllll day!
-} 
-
-{ 
-    let mut x = 5i; // x is the owner of this integer, which is memory on the stack.
-
-    let y = &mut x; // privilege 3: you may lend that resource to a single borrower,
-                    // mutably
-}   
-```
-
-If you are a borrower, you get a few privileges as well, but must also obey a
-restriction:
-
-1. If the borrow is immutable, you may read the data the pointer points to.
-2. If the borrow is mutable, you may read and write the data the pointer points to.
-3. You may lend the pointer to someone else in an immutable fashion, **BUT**
-4. When you do so, they must return it to you before you must give your own
-   borrow back.
-
-This last requirement can seem odd, but it also makes sense. If you have to
-return something, and you've lent it to someone, they need to give it back to
-you for you to give it back! If we didn't, then the owner could deallocate
-the memory, and the person we've loaned it out to would have a pointer to
-invalid memory. This is called a 'dangling pointer.'
-
-Let's re-examine the error that led us to talk about all of this, which was a
-violation of the restrictions placed on owners who lend something out mutably.
-The code:
-
-```{rust,ignore}
-let mut x = 5i;
-let y = &mut x;
-let z = &mut x;
-```
-
-The error:
-
-```{notrust,ignore}
-error: cannot borrow `x` as mutable more than once at a time
-     let z = &mut x;
-                  ^
-note: previous borrow of `x` occurs here; the mutable borrow prevents subsequent moves, borrows, or modification of `x` until the borrow ends
-     let y = &mut x;
-                  ^
-note: previous borrow ends here
- fn main() {
-     let mut x = 5i;
-     let y = &mut x;
-     let z = &mut x;
- }
- ^
-```
-
-This error comes in three parts. Let's go over each in turn.
-
-```{notrust,ignore}
-error: cannot borrow `x` as mutable more than once at a time
-     let z = &mut x;
-                  ^
-```
-
-This error states the restriction: you cannot lend out something mutable more
-than once at the same time. The borrow checker knows the rules!
-
-```{notrust,ignore}
-note: previous borrow of `x` occurs here; the mutable borrow prevents subsequent moves, borrows, or modification of `x` until the borrow ends
-     let y = &mut x;
-                  ^
-```
-
-Some compiler errors come with notes to help you fix the error. This error comes
-with two notes, and this is the first. This note informs us of exactly where
-the first mutable borrow occurred. The error showed us the second. So now we
-see both parts of the problem. It also alludes to rule #3, by reminding us that
-we can't change `x` until the borrow is over.
-
-```{notrust,ignore}
-note: previous borrow ends here
- fn main() {
-     let mut x = 5i;
-     let y = &mut x;
-     let z = &mut x;
- }
- ^
-```
-
-Here's the second note, which lets us know where the first borrow would be over.
-This is useful, because if we wait to try to borrow `x` after this borrow is
-over, then everything will work.
-
-These rules are very simple, but that doesn't mean that they're easy. For more
-advanced patterns, please consult the [Lifetime Guide](guide-lifetimes.html).
-You'll also learn what this type signature with the `'a` syntax is:
-
-```{rust,ignore}
-pub fn as_maybe_owned(&self) -> MaybeOwned<'a> { ... }
-```
-
 ## Boxes
 
 All of our references so far have been to variables we've created on the stack.

branches/auto/src/doc/rust.md

@@ -1308,9 +1308,6 @@ struct Cookie;
 let c = [Cookie, Cookie, Cookie, Cookie];
 ~~~~
 
-The precise memory layout of a structure is not specified. One can specify a
-particular layout using the [`repr` attribute](#ffi-attributes).
-
 By using the `struct_inherit` feature gate, structures may use single inheritance. A Structure may only
 inherit from a single other structure, called the _super-struct_. The inheriting structure (sub-struct)
 acts as if all fields in the super-struct were present in the sub-struct. Fields declared in a sub-struct
@@ -1944,23 +1941,6 @@ interpreted:
 - `linkage` - on a static, this specifies the [linkage
   type](http://llvm.org/docs/LangRef.html#linkage-types).
 
-On `enum`s:
-
-- `repr` - on C-like enums, this sets the underlying type used for
-  representation. Takes one argument, which is the primitive
-  type this enum should be represented for, or `C`, which specifies that it
-  should be the default `enum` size of the C ABI for that platform. Note that
-  enum representation in C is undefined, and this may be incorrect when the C
-  code is compiled with certain flags.
-
-On `struct`s:
-
-- `repr` - specifies the representation to use for this struct. Takes a list
-  of options. The currently accepted ones are `C` and `packed`, which may be
-  combined. `C` will use a C ABI comptible struct layout, and `packed` will
-  remove any padding between fields (note that this is very fragile and may
-  break platforms which require aligned access).
-
 ### Miscellaneous attributes
 
 - `export_name` - on statics and functions, this determines the name of the
@@ -1978,6 +1958,12 @@ On `struct`s:
   crate at compile-time and use any syntax extensions or lints that the crate
   defines. They can both be specified, `#[phase(link, plugin)]` to use a crate
   both at runtime and compiletime.
+- `repr` - on C-like enums, this sets the underlying type used for
+  representation. Useful for FFI. Takes one argument, which is the primitive
+  type this enum should be represented for, or `C`, which specifies that it
+  should be the default `enum` size of the C ABI for that platform. Note that
+  enum representation in C is undefined, and this may be incorrect when the C
+  code is compiled with certain flags.
 - `simd` - on certain tuple structs, derive the arithmetic operators, which
   lower to the target's SIMD instructions, if any; the `simd` feature gate
   is necessary to use this attribute.

branches/auto/src/libcore/mem.rs

@@ -19,16 +19,6 @@ use ptr;
 
 pub use intrinsics::transmute;
 
-/// Moves a thing into the void.
-///
-/// The forget function will take ownership of the provided value but neglect
-/// to run any required cleanup or memory management operations on it.
-///
-/// This function is the unsafe version of the `drop` function because it does
-/// not run any destructors.
-#[stable]
-pub use intrinsics::forget;
-
 /// Returns the size of a type in bytes.
 #[inline]
 #[stable]
@@ -347,6 +337,17 @@ pub fn replace<T>(dest: &mut T, mut src: T) -> T {
 #[stable]
 pub fn drop<T>(_x: T) { }
 
+/// Moves a thing into the void.
+///
+/// The forget function will take ownership of the provided value but neglect
+/// to run any required cleanup or memory management operations on it.
+///
+/// This function is the unsafe version of the `drop` function because it does
+/// not run any destructors.
+#[inline]
+#[stable]
+pub unsafe fn forget<T>(thing: T) { intrinsics::forget(thing) }
+
 /// Interprets `src` as `&U`, and then reads `src` without moving the contained
 /// value.
 ///

branches/auto/src/libcore/simd.rs

@@ -40,7 +40,6 @@
 #[experimental]
 #[simd]
 #[deriving(Show)]
-#[repr(C)]
 pub struct i8x16(pub i8, pub i8, pub i8, pub i8,
                  pub i8, pub i8, pub i8, pub i8,
                  pub i8, pub i8, pub i8, pub i8,
@@ -49,26 +48,22 @@ pub struct i8x16(pub i8, pub i8, pub i8, pub i8,
 #[experimental]
 #[simd]
 #[deriving(Show)]
-#[repr(C)]
 pub struct i16x8(pub i16, pub i16, pub i16, pub i16,
                  pub i16, pub i16, pub i16, pub i16);
 
 #[experimental]
 #[simd]
 #[deriving(Show)]
-#[repr(C)]
 pub struct i32x4(pub i32, pub i32, pub i32, pub i32);
 
 #[experimental]
 #[simd]
 #[deriving(Show)]
-#[repr(C)]
 pub struct i64x2(pub i64, pub i64);
 
 #[experimental]
 #[simd]
 #[deriving(Show)]
-#[repr(C)]
 pub struct u8x16(pub u8, pub u8, pub u8, pub u8,
                  pub u8, pub u8, pub u8, pub u8,
                  pub u8, pub u8, pub u8, pub u8,
@@ -77,30 +72,25 @@ pub struct u8x16(pub u8, pub u8, pub u8, pub u8,
 #[experimental]
 #[simd]
 #[deriving(Show)]
-#[repr(C)]
 pub struct u16x8(pub u16, pub u16, pub u16, pub u16,
                  pub u16, pub u16, pub u16, pub u16);
 
 #[experimental]
 #[simd]
 #[deriving(Show)]
-#[repr(C)]
 pub struct u32x4(pub u32, pub u32, pub u32, pub u32);
 
 #[experimental]
 #[simd]
 #[deriving(Show)]
-#[repr(C)]
 pub struct u64x2(pub u64, pub u64);
 
 #[experimental]
 #[simd]
 #[deriving(Show)]
-#[repr(C)]
 pub struct f32x4(pub f32, pub f32, pub f32, pub f32);
 
 #[experimental]
 #[simd]
 #[deriving(Show)]
-#[repr(C)]
 pub struct f64x2(pub f64, pub f64);