Auto merge of #27914 - pnkfelix:fix-fcnr-for-valgrind, r=alexcrichton

Fix (and extend) src/test/run-pass/foreign-call-no-runtime.rs

While going over various problems signaled by valgrind when running `make check` on a build configured with `--enable-valgrind`, I discovered a bug in this test case.

Namely, the test case was previously creating an `i32` (originally an `int` aka `isize` but then we changed the name and the fallback rules), and then reading from a `*const isize`. Valgrind rightly complains about this, since we are reading an 8 byte value on 64-bit systems, but in principle only 4 bytes have been initialized.

(I wish this was the only valgrind unclean test, but unfortunately there are a bunch more. This was just the easiest/first one that I dissected.)

Author: bors

src/test/run-pass/foreign-call-no-runtime.rs

@@ -25,15 +25,39 @@ extern {
 pub fn main() {
     unsafe {
         thread::spawn(move|| {
-            let i = 100;
-            rust_dbg_call(callback, mem::transmute(&i));
-        }).join();
+            let i: isize = 100;
+            rust_dbg_call(callback_isize, mem::transmute(&i));
+        }).join().unwrap();
+
+        thread::spawn(move|| {
+            let i: i32 = 100;
+            rust_dbg_call(callback_i32, mem::transmute(&i));
+        }).join().unwrap();
+
+        thread::spawn(move|| {
+            let i: i64 = 100;
+            rust_dbg_call(callback_i64, mem::transmute(&i));
+        }).join().unwrap();
     }
 }
 
-extern fn callback(data: libc::uintptr_t) {
+extern fn callback_isize(data: libc::uintptr_t) {
     unsafe {
         let data: *const isize = mem::transmute(data);
         assert_eq!(*data, 100);
     }
 }
+
+extern fn callback_i64(data: libc::uintptr_t) {
+    unsafe {
+        let data: *const i64 = mem::transmute(data);
+        assert_eq!(*data, 100);
+    }
+}
+
+extern fn callback_i32(data: libc::uintptr_t) {
+    unsafe {
+        let data: *const i32 = mem::transmute(data);
+        assert_eq!(*data, 100);
+    }
+}