Skip to content

Getting tests passing with libclang >= 5.0 #615

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
fitzgen opened this issue Apr 5, 2017 · 6 comments
Closed

Getting tests passing with libclang >= 5.0 #615

fitzgen opened this issue Apr 5, 2017 · 6 comments

Comments

@fitzgen
Copy link
Member

fitzgen commented Apr 5, 2017

All that is needed to get libclang 4.0 tests passing is fixing the regression in #585.

With that regression manually patched, for libclang >= 5.0, there are just a few more things.

Constants

It looks like we get different (more?) info about constants, and so we get a bunch of different test results that don't match our extant expectations:

--- expected: "/home/fitzgen/rust-bindgen/tests/expectations/tests/constant-evaluate.rs"
+++ generated from: "/home/fitzgen/rust-bindgen/tests/headers/constant-evaluate.h"
 /* automatically generated by rust-bindgen */
 
 
 #![allow(non_snake_case)]
 
 
 pub const foo: _bindgen_ty_1 = _bindgen_ty_1::foo;
 pub const bar: _bindgen_ty_1 = _bindgen_ty_1::bar;
 #[repr(u32)]
 #[derive(Debug, Copy, Clone, PartialEq, Eq, Hash)]
 pub enum _bindgen_ty_1 { foo = 4, bar = 8, }
 pub type EasyToOverflow = ::std::os::raw::c_ulonglong;
 pub const k: EasyToOverflow = 2147483648;
-pub const k_expr: EasyToOverflow = 0;
-pub const BAZ: ::std::os::raw::c_longlong = 24;
-pub const fuzz: f64 = 51.;
-pub const BAZZ: ::std::os::raw::c_char = 53;
-pub const WAT: ::std::os::raw::c_char = 0;
-pub const bytestring: &'static [u8; 4usize] = b"Foo\x00";
-pub const NOT_UTF8: [u8; 5usize] = [240, 40, 140, 40, 0];
+extern "C" {
+    #[link_name = "k_expr"]
+    pub static k_expr: EasyToOverflow;
+}
+extern "C" {
+    #[link_name = "BAZ"]
+    pub static BAZ: ::std::os::raw::c_longlong;
+}
+extern "C" {
+    #[link_name = "fuzz"]
+    pub static fuzz: f64;
+}
+extern "C" {
+    #[link_name = "BAZZ"]
+    pub static BAZZ: ::std::os::raw::c_char;
+}
+extern "C" {
+    #[link_name = "WAT"]
+    pub static WAT: ::std::os::raw::c_char;
+}
+extern "C" {
+    #[link_name = "bytestring"]
+    pub static mut bytestring: *const ::std::os::raw::c_char;
+}
+extern "C" {
+    #[link_name = "NOT_UTF8"]
+    pub static mut NOT_UTF8: *const ::std::os::raw::c_char;
+}

This seems fine by itself, but the question is how to get this (and related) tests passing.

Different expectations for different libclang versions? And then update them via pushing to CI to get the diffs to apply manually if one doesn't have all the different libclang versions we support handy?

Extend + generalize our // bindgen-unstable thing to // libclang-3.9, // libclang-4, // libclang-5, etc?

stdcall stuff

Not 100% sure what's up here.

We get this warning from libclang: rust-bindgen/tests/headers/call-conv-field.h:10:16: warning: function with no prototype cannot use the stdcall calling convention [-Wmissing-prototype-for-cc], err: false.

And then we get this test expectation diff:

--- expected: "/home/fitzgen/rust-bindgen/tests/expectations/tests/call-conv-field.rs"
+++ generated from: "/home/fitzgen/rust-bindgen/tests/headers/call-conv-field.h"
 /* automatically generated by rust-bindgen */
 
 
 #![allow(non_snake_case)]
 
 
 #[repr(C)]
 #[derive(Copy)]
 pub struct JNINativeInterface_ {
     pub GetVersion: ::std::option::Option<unsafe extern "stdcall" fn(env:
                                                                          *mut ::std::os::raw::c_void)
                                               -> ::std::os::raw::c_int>,
     pub __hack: ::std::os::raw::c_ulonglong,
 }
 #[test]
 fn bindgen_test_layout_JNINativeInterface_() {
     assert_eq!(::std::mem::size_of::<JNINativeInterface_>() , 16usize , concat
                ! ( "Size of: " , stringify ! ( JNINativeInterface_ ) ));
     assert_eq! (::std::mem::align_of::<JNINativeInterface_>() , 8usize ,
                 concat ! (
                 "Alignment of " , stringify ! ( JNINativeInterface_ ) ));
     assert_eq! (unsafe {
                 & ( * ( 0 as * const JNINativeInterface_ ) ) . GetVersion as *
                 const _ as usize } , 0usize , concat ! (
                 "Alignment of field: " , stringify ! ( JNINativeInterface_ ) ,
                 "::" , stringify ! ( GetVersion ) ));
     assert_eq! (unsafe {
                 & ( * ( 0 as * const JNINativeInterface_ ) ) . __hack as *
                 const _ as usize } , 8usize , concat ! (
                 "Alignment of field: " , stringify ! ( JNINativeInterface_ ) ,
                 "::" , stringify ! ( __hack ) ));
 }
 impl Clone for JNINativeInterface_ {
     fn clone(&self) -> Self { *self }
 }
 impl Default for JNINativeInterface_ {
     fn default() -> Self { unsafe { ::std::mem::zeroed() } }
 }
-extern "stdcall" {
+extern "C" {
     #[link_name = "_bar@0"]
     pub fn bar();
 }

This seems like maybe something we just need to fix in the header itself?

Slightly better understanding of random template code than 3.9 and 4

Here we seem to get slightly more useful information out of clang and generate more IR items, resulting in different test numbering, and method generation that we otherwise wouldn't.

--- expected: "/home/fitzgen/rust-bindgen/tests/expectations/tests/partial-specialization-and-inheritance.rs"
+++ generated from: "/home/fitzgen/rust-bindgen/tests/headers/partial-specialization-and-inheritance.hpp"
 /* automatically generated by rust-bindgen */
 
 
 #![allow(non_snake_case)]
 
 
 #[repr(C)]
 #[derive(Debug, Default, Copy, Clone)]
 pub struct Base {
     pub _address: u8,
 }
 #[repr(C)]
 #[derive(Debug, Default, Copy, Clone)]
 pub struct Derived {
     pub b: bool,
 }
 #[test]
-fn __bindgen_test_layout__bindgen_ty_id_20_instantiation_14() {
+fn __bindgen_test_layout__bindgen_ty_id_21_instantiation_15() {
     assert_eq!(::std::mem::size_of::<[u32; 2usize]>() , 8usize , concat ! (
                "Size of template specialization: " , stringify ! (
                [u32; 2usize] ) ));
     assert_eq!(::std::mem::align_of::<[u32; 2usize]>() , 4usize , concat ! (
                "Alignment of template specialization: " , stringify ! (
                [u32; 2usize] ) ));
 }
 #[repr(C)]
 #[derive(Debug, Default, Copy)]
 pub struct Usage {
     pub _address: u8,
 }
 extern "C" {
     #[link_name = "_ZN5Usage13static_memberE"]
     pub static mut Usage_static_member: [u32; 2usize];
 }
 #[test]
 fn bindgen_test_layout_Usage() {
     assert_eq!(::std::mem::size_of::<Usage>() , 1usize , concat ! (
                "Size of: " , stringify ! ( Usage ) ));
     assert_eq! (::std::mem::align_of::<Usage>() , 1usize , concat ! (
                 "Alignment of " , stringify ! ( Usage ) ));
 }
+extern "C" {
+    #[link_name = "_ZN5UsageC1Ev"]
+    pub fn Usage_Usage(this: *mut Usage);
+}
 impl Clone for Usage {
     fn clone(&self) -> Self { *self }
+}
+impl Usage {
+    #[inline]
+    pub unsafe fn new() -> Self {
+        let mut __bindgen_tmp = ::std::mem::uninitialized();
+        Usage_Usage(&mut __bindgen_tmp);
+        __bindgen_tmp
+    }
 }

Again, the changes in code generation seem fine, but we need to figure out what our desired approach for testing across libclang versions should be.

@fitzgen
Copy link
Member Author

fitzgen commented Apr 5, 2017

cc @emilio opinions here?

@emilio
Copy link
Contributor

emilio commented Apr 5, 2017

It looks like we get different (more?) info about constants, and so we get a bunch of different test results that don't match our extant expectations.

This is exactly the opposite, this is getting the same results as we'd get with libclang 3.8, which is sad :(

@fitzgen
Copy link
Member Author

fitzgen commented Apr 5, 2017

This is exactly the opposite, this is getting the same results as we'd get with libclang 3.8, which is sad :(

Can you file an upstream bug report before this behavior gets frozen in 5.X?

@emilio
Copy link
Contributor

emilio commented Apr 6, 2017

I can't repro it with llvm trunk though

@fitzgen
Copy link
Member Author

fitzgen commented Apr 6, 2017

I can't repro it with llvm trunk though

It is quite possible I messed up which libclang I had installed after tons of bisecting + testing different versions yesterday...

@emilio
Copy link
Contributor

emilio commented Apr 22, 2017

This should be basically #615, so let's use that :)

@emilio emilio closed this as completed Apr 22, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants