bindgen generates duplicate definitions

[jsgf]

This command and input generates two distinct definitions for std_char_traits. I tried both --enable-cxx_namespaces and --disable-name-namespacing, but neither made a significant difference.

Command: bindgen stdcxx.i -- -x c++ -std=c++14

Input:

namespace std
{
  template < typename > struct char_traits;
    template < typename _CharT, typename _Traits =
    char_traits < _CharT > >class basic_fbstring;
}
namespace __gnu_cxx
{
  template < typename > struct char_traits;
}
namespace std
{
  template < class _CharT > struct char_traits:__gnu_cxx::char_traits <
    _CharT >
  {
  };
}

[jsgf]

Output:

#[repr(C)]
#[derive(Debug, Copy)]
pub struct std_char_traits {
    pub _address: u8,
}
impl Clone for std_char_traits {
    fn clone(&self) -> Self { *self }
}
#[repr(C)]
#[derive(Debug, Copy, Clone)]
pub struct std_char_traits<_CharT> {
    pub _address: u8,
    pub _phantom_0: ::std::marker::PhantomData<_CharT>,
}
#[repr(C)]
#[derive(Debug, Copy, Clone)]
pub struct std_basic_fbstring<_CharT, _Traits> {
    pub _address: u8,
    pub _phantom_0: ::std::marker::PhantomData<_CharT>,
    pub _phantom_1: ::std::marker::PhantomData<_Traits>,
}

[fitzgen]

Thanks for the bug report!

[emilio]

Yep, we saw the exact same thing with opencv in a previous report, but I didn't have the time to construct a test case that wasn't the stdlib, so thanks! :).

Short term solution thing is probably to --blacklist-type std::char_traits.

BTW, if you're binding complex C++ it's probably ok to use bindgen's namespace support with --enable-cxx-namespaces. We should make it the default some time soon.

[emilio]

Gah, this test case is tricky. A bit more minimized:

namespace std
{
  template < typename > struct char_traits;
}
namespace __gnu_cxx
{
  template < typename > struct char_traits;
}
namespace std
{
  template < class _CharT > struct char_traits:__gnu_cxx::char_traits <
    _CharT >
  {
  };
}

Basically, what we're doing is: When we see the forward declaration, we go to the definition and parse it, then we assume that the base class specifier needs to be a complete type, and assume we're going to find it as already resolved. But that's not true, sigh.

I think I have a fix, but I'll have to test it a bit more.

[emilio]

But that's not true, sigh.

And since it's not true, we go ahead and parse it as-if it was in our own namespace, which is wrong, and then we generate the duplicate definition.

[emilio]

See #360. Thanks for the test case again, was super helpful to figure out what was going on!

[jsgf]

No problem! creduce is magic.

[fitzgen]

Indeed it is :)