Skip to content

Non-type template parameters and failing layout tests #569

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 Mar 9, 2017 · 1 comment
Closed

Non-type template parameters and failing layout tests #569

fitzgen opened this issue Mar 9, 2017 · 1 comment

Comments

@fitzgen
Copy link
Member

fitzgen commented Mar 9, 2017

Input C/C++ Header

template <int, typename> struct a {};
enum { b };
namespace JS {
template <typename c> using d = a<b, c>;
template <typename c> class e { d<c> f; };
class AutoIdVector : e<int> {};
}

Bindgen Invokation

$ bindgen input.hpp -- -std=c++14

Actual Results

/* automatically generated by rust-bindgen */

pub const b: _bindgen_ty_1 = _bindgen_ty_1::b;
#[repr(u32)]
#[derive(Debug, Copy, Clone, PartialEq, Eq, Hash)]
pub enum _bindgen_ty_1 { b = 0, }
pub type JS_d = ();
#[repr(C)]
pub struct JS_e {
    pub f: JS_d,
}
#[repr(C)]
pub struct JS_AutoIdVector {
    pub _base: JS_e,
}
#[test]
fn bindgen_test_layout_JS_AutoIdVector() {
    assert_eq!(::std::mem::size_of::<JS_AutoIdVector>() , 1usize , concat ! (
               "Size of: " , stringify ! ( JS_AutoIdVector ) ));
    assert_eq! (::std::mem::align_of::<JS_AutoIdVector>() , 1usize , concat !
                ( "Alignment of " , stringify ! ( JS_AutoIdVector ) ));
}
#[test]
fn __bindgen_test_layout_JS_e_instantiation_16() {
    assert_eq!(::std::mem::size_of::<JS_e>() , 1usize , concat ! (
               "Size of template specialization: " , stringify ! ( JS_e ) ));
    assert_eq!(::std::mem::align_of::<JS_e>() , 1usize , concat ! (
               "Alignment of template specialization: " , stringify ! ( JS_e )
               ));
}

Compiling with --test and running the generated layout tests results in these failures:

running 2 tests
test root::JS::bindgen_test_layout_AutoIdVector ... FAILED
test root::__bindgen_test_layout_e_instantiation_16 ... FAILED

failures:

---- root::JS::bindgen_test_layout_AutoIdVector stdout ----
	thread 'root::JS::bindgen_test_layout_AutoIdVector' panicked at 'assertion failed: `(left == right)` (left: `0`, right: `1`): Size of: AutoIdVector', ./js.rs:22
note: Run with `RUST_BACKTRACE=1` for a backtrace.

---- root::__bindgen_test_layout_e_instantiation_16 stdout ----
	thread 'root::__bindgen_test_layout_e_instantiation_16' panicked at 'assertion failed: `(left == right)` (left: `0`, right: `1`): Size of template specialization: root :: JS :: e', ./js.rs:31


failures:
    root::JS::bindgen_test_layout_AutoIdVector
    root::__bindgen_test_layout_e_instantiation_16

test result: FAILED. 0 passed; 2 failed; 0 ignored; 0 measured

Expected Results

Although we generally can't support non-type template parameters and instantiations of templates with such parameters, we shouldn't be generating code + layout tests that fail. We need to do a better job of detecting this and emitting an opaque blob instead, or even completely skipping this stuff in codegen (which we do some of the time but not always it seems).

@fitzgen
Copy link
Member Author

fitzgen commented Mar 9, 2017

Ok so this issue seems to involve our choice of () as the default representation for when a template definition has non-type parameters.

fitzgen added a commit to fitzgen/rust-bindgen that referenced this issue Mar 9, 2017
When instantiating templates whose definitions have non-type generic parameters,
prefer the layout of the instantiation type to the garbage we get from the
definition's layout. In general, an instantiation's layout will always be a
better choice than the definition's layout, regardless of non-type parameters.

Fixes rust-lang#569
bors-servo pushed a commit that referenced this issue Mar 9, 2017
Generate better opaque blobs in the face of non-type parameters

When instantiating templates whose definitions have non-type generic parameters, prefer the layout of the instantiation type to the garbage we get from the definition's layout. In general, an instantiation's layout will always be a better choice than the definition's layout, regardless of non-type parameters.

Fixes #569

r? @emilio
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant