Associated constants don't take the prefix into account properly

[kvark]

#234 is missing a test for preffixed bindings. This is what we get:

typedef uint32_t WGPUTextureUsageFlags;
#define WGPUTextureUsageFlags_TRANSFER_DST (TextureUsageFlags){ .bits = 2 }

This doesn't compile, clearly, since there is no TextureUsageFlags.

cc @IGI-111

[IGI-111]

I'm taking a look at this, will have to possibly add an alternative to LiteralExpr so that the prefixing can take place.

[kvark]

Thank you @IGI-111 !
I tried to test this today and faced other issues.
First of all, the #[repr(transparent)] isn't taken into account here, since the macro tries to assign the .bits field, and there are no fields on uint32_t.

Secondly, something strange is going on when I run wgpu-bindings:

kvark@ant /mnt/base/moz/wgpu $ cargo +nightly run --manifest-path wgpu-bindings/Cargo.toml
    Finished dev [unoptimized + debuginfo] target(s) in 0.07s                                                                                                               
     Running `target/debug/wgpu-bindings`
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: CargoExpand("wgpu-native", Compile("    Finished dev [unoptimized + debuginfo] target(s) in 0.07s\n"))', libcore/result.rs:1009:5
note: Run with `RUST_BACKTRACE=1` for a backtrace.

It looks like the compilation is successful, but something returns an error?

[IGI-111]

Supporting #repr(transparent) should be pretty straightforward since the we're only interested in the first field. Open a separate issue and i'll look into it, no promises though since I didn't even know that was a thing. The more you know I guess.

As for that error message, which unwrap is failing here? Might be something completely unrelated. Can you post the backtrace?

[kvark]

It's the unwrap from this code on our side:

    cbindgen::Builder::new()
        .with_crate(source_dir)
        .with_config(config)
        .with_parse_expand(&["wgpu-native"])
        .generate()
        .unwrap()
        .write_to_file(crate_dir.join("wgpu.h"));

[IGI-111]

That is quite a weird Err value indeed. I bet something just fails silently inside and the output is just misleading because it's missing a proper error message.

[kvark]

@IGI-111 how can I investigate this / provide more info?

[IGI-111]

I'd start by figuring out where that Err is generated, and then finding the source of the failure, it's probably wise to pull out gdb here.

Maybe run cbindgen on only part of the offending codebase, or on all files individually? I mean with a relatively minimal example we could start to speculate on the cause.

Best you can do is open an issue with the smallest offending code you can find.

[grovesNL]

@kvark I don't know the reason, but running cargo clean and retrying seems to resolve it for me.

It seems like the command cbindgen runs for with_parse_expand causes the issue occasionally:

"/Users/josh/.rustup/toolchains/nightly-x86_64-apple-darwin/bin/cargo" "rustc" "--lib" "--manifest-path" "/Users/josh/Projects/wgpu-native/wgpu-native/Cargo.toml" "-p" "wgpu-native:0.1.0" "--" "-Z""unstable-options" "--pretty=expanded"

Sometimes this seems to produce empty output, and instead results in an exit status of 0 with that message in stderr and empty stdout. I'm not sure how to reproduce it consistently though, and cargo clean seems to have fixed it for me (at least at the moment).

Does anyone know why --pretty=expanded would not result in output for a successful compilation?

[grovesNL]

I'm able to reproduce this consistently now.

λ "/Users/josh/.rustup/toolchains/nightly-x86_64-apple-darwin/bin/cargo" "rustc" "--lib" "--manifest-path" "/Users/josh/Projects/wgpu-native/wgpu-native/Cargo.toml" "-p" "wgpu-native:0.1.0" "--" "-Z""unstable-options" "--pretty=expanded" > out1
   Compiling wgpu-native v0.1.0 (file:///Users/josh/Projects/wgpu-native/wgpu-native)
    Finished dev [unoptimized + debuginfo] target(s) in 0.94s
λ "/Users/josh/.rustup/toolchains/nightly-x86_64-apple-darwin/bin/cargo" "rustc" "--lib" "--manifest-path" "/Users/josh/Projects/wgpu-native/wgpu-native/Cargo.toml" "-p" "wgpu-native:0.1.0" "--" "-Z""unstable-options" "--pretty=expanded" > out2
    Finished dev [unoptimized + debuginfo] target(s) in 0.33s

out1 contains the expanded source as expected.
out2 is empty.

This reminded me of behavior I noticed with rust-clippy, so I went looking for a similar issue. It seems we're blocked by the same issue as rust-lang/rust-clippy#2604, so macro expansion will only work when recompilation is required.