Skip to content
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

Incorrect type resolving for differently scoped types of same name #199

Closed
regexident opened this issue Aug 21, 2018 · 1 comment
Closed

Comments

@regexident
Copy link
Contributor

A minimalistic crate like this …

// lib.rs

pub mod foo {
    pub struct Foobar<T> { pub field: T }
}

pub mod bar {
    pub struct Foobar { pub field: u8 }

    #[no_mangle]
    pub unsafe extern "C" fn placebo(_foobar: &Foobar) {}
}

… generates a header like this …

// lib.h

#include <cstdint>
#include <cstdlib>

template<typename T>
struct Foobar;

extern "C" {

void placebo(const Foobar *_foobar);

} // extern "C"

… while it should generate something like this instead:

#include <cstdint>
#include <cstdlib>

struct Foobar;

extern "C" {

void placebo(const Foobar *_foobar);

} // extern "C"

What's wrong:

  1. Foobar<T> is not used in any exported fn and hence shouldn't be generated.
  2. Foobar however is used in an exported fn and hence should be generated.

Observations:

  1. Changing the order of mod foo and mod bar makes it behave correctly.
  2. Adding #[repr(C)] to bar::Foobar makes it behave correctly, strangely enough.
  3. The <T> doesn't seem to be strictly necessary for triggering this bug, but makes things easier to spot in the generated header.

Looks like there's a name collision in the type registration. Probably by using their local instead of fully qualified names for lookup?

@eqrion
Copy link
Collaborator

eqrion commented Aug 21, 2018

This is a duplicate of the root issue of #7. Essentially cbindgen doesn't understand fully qualified names, and it doesn't understand imports and aliases. This is a longstanding issue, unfortunately.

I'll close this here. If you'd provide some of these details in that issue, I'd greatly appreciate that.

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

2 participants