Integer type not generated properly when it's a template argument

[upsuper]

If I have a type nsTArray<uint16_t>, it is expected that I would get nsTArray<u16> from bindgen. However, I get nsTArray<::std::os::raw::c_ushort> instead.

It seems the uint16_t-to-u16 conversion is done in type_from_named inside codegen mod. I suspect that the uint16_t in template argument list is converted to unsigned short in parsing phase, and consequently codegen has nothing to do with it.

[emilio]

Hmm... It's not that. It's a combination of two bugs.

First, clang represents that as an Unexposed type. Since it has a canonical type which is an exposed one (nsTArray<unsigned short>) we pick the first branch in the match in Type::from_clang_ty.

[emilio]

The other one is that even with that fixed, the function clang_Type_getTemplateArgumentAsType returns UShort to us :(

[upsuper]

Is it possible to treat those types as opaque types and force clang to hand over them to us?

[emilio]

I don't think so. I suspect the spelling of the opaque type would be
correct, though.

We can move the scanning of "known" typedefs over to parsing without too
much effort (though I'm not extremely happy about it). That would fix
the integer types for example, but not other types of typedefs.

On Fri, Oct 07, 2016 at 05:00:43PM -0700, Xidorn Quan wrote:

Is it possible to treat those types as opaque types and force clang to hand over them to us?

You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#75 (comment)

[upsuper]

What do you mean by "move the scanning ... over"?

If we cannot hack into libclang to get the names right, we can probably do some other hacks.

One idea occurs to me is to build a fake stdint.h, and make clang to use it first, and in that fake header, we define the integer types as opaque types, so that clang wouldn't replace them with the builtin types. That works for u?int{8,16,32,64,ptr}_t, but doesn't work for size_t and ptrdiff_t, because they are from builtin includes, and clang would ignore any further definition of them.

Another idea is that, we inject a normal header via -include, with content like the following

#include <stdint.h>
enum __builtin_uint16_t : uint16_t;
#define uint16_t __builtin_uint16_t

This would work reliably for all those types as far as it doesn't try to compile any calculation.

But these hacks may break some type traits, I guess...

[upsuper]

Yeah, it would definitely break any integer-related traits. I guess it's probably impossible to have a solution which doesn't break any trait while makes clang report those types.

[upsuper]

Probably I should just make some opaque struct and teach bindgen to treat them as nsTArray in the Rust side.

[emilio]

This is fixed by clang 4.0+, so the only regression pending fixing from that change is the default template parameters one (#585). Luckily that doesn't affect stylo.

There's no way to get the proper parameter from libclang <4.0, so there's nothing left to be done here.