Open cbourjau opened 7 years ago
Thanks for the bug report!
RUST_LOG=bindgen
did not yield additional output
FYI, to get the logging, this should be set when running bindgen, not when compiling Rust code emitted by bindgen. There's been some confusion over this point in the past before and we should probably make the instructions more clear.
Also, thanks for the reduced test case, this helps a lot!
Here is a further reduced version of the test case:
// bindgen-flags: -- -std=c++11
template <typename T>
class Outer {
// Declaration, but no inline definition.
class Inner;
};
// Out of line definition.
template <typename U>
class Outer<U>::Inner {
U inner_member;
};
and the IR graph we construct from it:
I guess the problem is that we don't understand that effectively T == U
, but understanding that seems kind of hard, at first blush.
And here is the clang cursor AST:
You guys do magic with bindgen, thats for sure! I'm afraid that I am out of my depth a bit...
I think the only way to determine that T == U
would be if we used de Bruijn indexing for template arguments, which we should probably do sometime down the road (clang does this internally and you can see this in the canonical spelling of type parameters) but it is definitely not on my docket for the foreseeable future.
Ok, thanks a lot for taking the time to look into this, though! I think I can get by making a bunch of types opaque in my use case.
Ok, thanks a lot for taking the time to look into this, though!
No problem!
I think I can get by making a bunch of types opaque in my use case.
Yep, this is the reality of working with C++ in bindgen, unfortunately.
I have encountered a similar case.
template < typename T, T v > struct S
{
static constexpr T value = v;
};
template < typename T, T v > constexpr T S < T, v >::value;
I have encountered a similar case.
Thanks for the additional test case; it's not 100% clear to me that this isn't a different bug. It involves non-type template parameters, which are not supported by bindgen at the moment. Ideally, we should avoid generating any code for S::value
so that the rest of the bindings are still usable.
Using the magic of
creduce
I found an issue on nested templates which apparently lurk somewhere in a large library that I try to wrap. I think this is a bug, or am I doing something wrong?Input C/C++ Header
Bindgen Invocation
Actual Results
The generated rust code uses undefined types:
which yields the following error when compiled
Expected Results
I would expect the
_Traits
type to be defined in the rust code.RUST_LOG=bindgen
OutputRUST_LOG=bindgen
did not yield additional output