Enums shadowed by names in module

[mkeeter]

I'm seeing misbehavior where an enum in a module causes mistranslation of a struct containing a #[repr(u32)] enum with the same name.

Here's a very simple test case:
test.rs:

mod uhoh {
    enum BindingType { Buffer, NotBuffer }
}

#[repr(u32)]
pub enum BindingType { Buffer = 0, NotBuffer = 1 }

#[repr(C)]
pub struct BindGroupLayoutEntry {
    pub ty: BindingType, // This is the repr(u32) enum
}

cbindgen.toml

language = "C"

[export]
include = [
    "BindGroupLayoutEntry",
]

Running cbindgen 0.16.0:

$ cbindgen -c cbindgen.toml test.rs
#include <stdarg.h>
#include <stdbool.h>
#include <stdint.h>
#include <stdlib.h>

enum BindingType {
  Buffer = 0,
  NotBuffer = 1,
};
typedef uint32_t BindingType;

typedef struct BindGroupLayoutEntry {
  struct BindingType ty;
} BindGroupLayoutEntry;

Having the member be struct BindingType ty is invalid, because there is no struct BindingType in the header; it should instead be BindingType ty.

[emilio]

Did this use to work? I assume the version in the OP should be 0.16.0, right?

[mkeeter]

Thanks, that seems to fix it! (and yes, I did mean 0.16.0 in the original post 😆)

Would you mind tagging a new release so that wgpu-native's CI can get unblocked on this PR?

I also noticed a weird side effect where it's now flattening chain's of typedefs, e.g.

-typedef WGPUNonZeroU64 WGPUId_Texture_Dummy;
+typedef uint64_t WGPUId_Texture_Dummy;

(where we have typedef unsigned long WGPUOption_NonZeroU64; in the autogen_warning header)

This doesn't break functionality, but discards some of the API intent – should I open another issue for it?

[emilio]

That seems like a consequence of #647, so it seems somewhat expected. Before that we'd generate non-compiling code (and you just happened to fix it up in the autogen_warning).