auto merge of rust-lang#16499 : cmr/rust/struct-undef-repr, r=pcwalton

r? @pcwalton

src/doc/guide-ffi.md

@@ -263,12 +263,13 @@ Rust code:
 
 ~~~~no_run
 
+#[repr(C)]
 struct RustObject {
     a: i32,
     // other members
 }
 
-extern fn callback(target: *mut RustObject, a:i32) {
+extern "C" 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
@@ -506,16 +507,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.
-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 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's owned and managed boxes use non-nullable pointers as handles which point to the contained
+Rust's owned boxes (`Box<T>`) 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

src/doc/rust.md

@@ -1308,6 +1308,9 @@ 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
@@ -1941,6 +1944,23 @@ 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
@@ -1958,12 +1978,6 @@ interpreted:
   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.

src/libcore/simd.rs

@@ -40,6 +40,7 @@
 #[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,
@@ -48,22 +49,26 @@ 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,
@@ -72,25 +77,30 @@ 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);

src/libgreen/context.rs

@@ -15,6 +15,7 @@ use std::rt::stack;
 use std::raw;
 #[cfg(target_arch = "x86_64")]
 use std::simd;
+use libc;
 
 // FIXME #7761: Registers is boxed so that it is 16-byte aligned, for storing
 // SSE regs.  It would be marginally better not to do this. In C++ we
@@ -69,7 +70,7 @@ impl Context {
         // overflow). Additionally, their coroutine stacks are listed as being
         // zero-length, so that's how we detect what's what here.
         let stack_base: *const uint = stack.start();
-        let bounds = if sp as uint == stack_base as uint {
+        let bounds = if sp as libc::uintptr_t == stack_base as libc::uintptr_t {
             None
         } else {
             Some((stack_base as uint, sp as uint))
@@ -166,7 +167,7 @@ fn new_regs() -> Box<Registers> {
 #[cfg(target_arch = "x86")]
 fn initialize_call_frame(regs: &mut Registers, fptr: InitFn, arg: uint,
                          procedure: raw::Procedure, sp: *mut uint) {
-
+    let sp = sp as *mut uint;
     // x86 has interesting stack alignment requirements, so do some alignment
     // plus some offsetting to figure out what the actual stack should be.
     let sp = align_down(sp);
@@ -188,13 +189,15 @@ fn initialize_call_frame(regs: &mut Registers, fptr: InitFn, arg: uint,
 // windows requires saving more registers (both general and XMM), so the windows
 // register context must be larger.
 #[cfg(windows, target_arch = "x86_64")]
+#[repr(C)]
 struct Registers {
-    gpr:[uint, ..14],
+    gpr:[libc::uintptr_t, ..14],
     _xmm:[simd::u32x4, ..10]
 }
 #[cfg(not(windows), target_arch = "x86_64")]
+#[repr(C)]
 struct Registers {
-    gpr:[uint, ..10],
+    gpr:[libc::uintptr_t, ..10],
     _xmm:[simd::u32x4, ..6]
 }
 
@@ -234,30 +237,30 @@ fn initialize_call_frame(regs: &mut Registers, fptr: InitFn, arg: uint,
     unsafe { *sp = 0; }
 
     rtdebug!("creating call frame");
-    rtdebug!("fptr {:#x}", fptr as uint);
+    rtdebug!("fptr {:#x}", fptr as libc::uintptr_t);
     rtdebug!("arg {:#x}", arg);
     rtdebug!("sp {}", sp);
 
     // These registers are frobbed by rust_bootstrap_green_task into the right
     // location so we can invoke the "real init function", `fptr`.
-    regs.gpr[RUSTRT_R12] = arg as uint;
-    regs.gpr[RUSTRT_R13] = procedure.code as uint;
-    regs.gpr[RUSTRT_R14] = procedure.env as uint;
-    regs.gpr[RUSTRT_R15] = fptr as uint;
+    regs.gpr[RUSTRT_R12] = arg as libc::uintptr_t;
+    regs.gpr[RUSTRT_R13] = procedure.code as libc::uintptr_t;
+    regs.gpr[RUSTRT_R14] = procedure.env as libc::uintptr_t;
+    regs.gpr[RUSTRT_R15] = fptr as libc::uintptr_t;
 
     // These registers are picked up by the regular context switch paths. These
     // will put us in "mostly the right context" except for frobbing all the
     // arguments to the right place. We have the small trampoline code inside of
     // rust_bootstrap_green_task to do that.
-    regs.gpr[RUSTRT_RSP] = sp as uint;
-    regs.gpr[RUSTRT_IP] = rust_bootstrap_green_task as uint;
+    regs.gpr[RUSTRT_RSP] = sp as libc::uintptr_t;
+    regs.gpr[RUSTRT_IP] = rust_bootstrap_green_task as libc::uintptr_t;
 
     // Last base pointer on the stack should be 0
     regs.gpr[RUSTRT_RBP] = 0;
 }
 
 #[cfg(target_arch = "arm")]
-type Registers = [uint, ..32];
+type Registers = [libc::uintptr_t, ..32];
 
 #[cfg(target_arch = "arm")]
 fn new_regs() -> Box<Registers> { box {[0, .. 32]} }
@@ -277,17 +280,17 @@ fn initialize_call_frame(regs: &mut Registers, fptr: InitFn, arg: uint,
     // ARM uses the same technique as x86_64 to have a landing pad for the start
     // of all new green tasks. Neither r1/r2 are saved on a context switch, so
     // the shim will copy r3/r4 into r1/r2 and then execute the function in r5
-    regs[0] = arg as uint;              // r0
-    regs[3] = procedure.code as uint;   // r3
-    regs[4] = procedure.env as uint;    // r4
-    regs[5] = fptr as uint;             // r5
-    regs[13] = sp as uint;                          // #52 sp, r13
-    regs[14] = rust_bootstrap_green_task as uint;   // #56 pc, r14 --> lr
+    regs[0] = arg as libc::uintptr_t;              // r0
+    regs[3] = procedure.code as libc::uintptr_t;   // r3
+    regs[4] = procedure.env as libc::uintptr_t;    // r4
+    regs[5] = fptr as libc::uintptr_t;             // r5
+    regs[13] = sp as libc::uintptr_t;                          // #52 sp, r13
+    regs[14] = rust_bootstrap_green_task as libc::uintptr_t;   // #56 pc, r14 --> lr
 }
 
 #[cfg(target_arch = "mips")]
 #[cfg(target_arch = "mipsel")]
-type Registers = [uint, ..32];
+type Registers = [libc::uintptr_t, ..32];
 
 #[cfg(target_arch = "mips")]
 #[cfg(target_arch = "mipsel")]
@@ -304,12 +307,12 @@ fn initialize_call_frame(regs: &mut Registers, fptr: InitFn, arg: uint,
     // The final return address. 0 indicates the bottom of the stack
     unsafe { *sp = 0; }
 
-    regs[4] = arg as uint;
-    regs[5] = procedure.code as uint;
-    regs[6] = procedure.env as uint;
-    regs[29] = sp as uint;
-    regs[25] = fptr as uint;
-    regs[31] = fptr as uint;
+    regs[4] = arg as libc::uintptr_t;
+    regs[5] = procedure.code as libc::uintptr_t;
+    regs[6] = procedure.env as libc::uintptr_t;
+    regs[29] = sp as libc::uintptr_t;
+    regs[25] = fptr as libc::uintptr_t;
+    regs[31] = fptr as libc::uintptr_t;
 }
 
 fn align_down(sp: *mut uint) -> *mut uint {

src/libgreen/stack.rs

@@ -68,7 +68,8 @@ impl Stack {
 
         // FIXME: Using the FFI to call a C macro. Slow
         stk.valgrind_id = unsafe {
-            rust_valgrind_stack_register(stk.start(), stk.end())
+            rust_valgrind_stack_register(stk.start() as *const libc::uintptr_t,
+                                         stk.end() as *const libc::uintptr_t)
         };
         return stk;
     }