Change:
} for &arg_ty in tys.fn_ty.arg_tys.iter() { <ins> if arg_ty.is_ignore() { continue; } </ins> // skip padding if arg_ty.pad.is_some() { i += 1; }

Discussion:
I'm interfacing an external DLL which I'm creating with Visual Studio 2012. I've tried to pass a struct by-value from C to Rust in a callback. The struct and the callback are defined as follows: However the struct received in is corrupted and contains not the data which is sent in C++. I wrote a test program to isolate and reproduce the issue. The gist therefore is here: It can be cloned from It includes the source code for the library with a visual studio project to built it and the rust test program. I also included to build it on Linux. However in Linux I can't reproduct the issue. The struct get's copied correctly there. This is the output from my test program: The first line is the content of the notification in bytes in C++, the second the content in Rust. You can see that the last bytes of the notification structure are different in C++ in Rust. Interesting hereby is also that the last field ( == 9) gets copied into notification.valueid.d (verified this with using other values for ) and the remaining notification fields are garbage.
on IRC mentioned that this could be related to However I'm not sure because that issue is about structs as return values. In my case the struct is a function argument and not the return value.
Issue is also similar. However I could successfully pass structs from Rust to C before - but mine didn't contain u8 values but only pointers and i32/u32 values. Maybe the issue is related to u8/i8 types in structs? Because in my example the problem also exists at the first u8 location.
Update: As on IRC suggested I have created a more compact example and included LLVM IR: The error happens on all structs with more than a single u8 or u16 value. The new test tests are passing a struct with 4 u8 or 4 u16 parameters from Rust to C as well as from C to Rust. I also switched the C side from a C++ project with extern C declarations to a pure C project, so that this issue can be ruled out.
You can bypass the problem by using external LLVM to compile bitcode. I wrote small utility to do that: , and it worked with rsfml.

I prepared some files that should illustrate the problem: Struct Color is passed incorrectly to function in C library. I pass {1,2,3,4} but receive {1,0,0,0}. It happens on Windows 7 64bit, but not on Linux Mint 64bit. Using external LLVM to compile bitcode (on Windows) works too.
Can you provide a slightly more minimized test case? It would also be useful to have content hosted in a github gist instead of a 7z archive that's much more easily accessible.
Sure:
Thanks! cc
It appears that gcc treats the struct as an immediate 32-bit value (one register), and our call to the function generate a function call with 4 arguments. I would copy-paste more assembly, but I'm not sure how to copy out of a windows VM...
These parts are probably relevant: was generated by LLVM integrated with rust was generated by my own LLVM build and it works OK Are there some parameters passed to integrated LLVM that could cause this?
I wrote a small utility to bypass the problem: It worked with rsfml, though I guess rust uses LLVM fork for a reason.

See run-pass/extern-pass- and run_pass/extern-
it seems to be related to issue .
Still reproduces.
These appear to have been fixed as part of
Closing an issue without un-xfailing the tests! The horror! (I'm landing the un-xfail in .)
Aaaaaand, it looks like this isn't fixed:
gah sorry! I was looking at instead of . My bad.
triage: still broken