Very strange cwd-dependent behavior

[CAD97]

Input C/C++ Header

I'm sorry, I have absolutely no idea how to go about minimizing this. (However, the linked headers have no system dependencies, at least.)

Bindgen Invocation

In this repo:

/crates/fmod-studio-sys>     bindgen inc/fmod_studio.h -o bindings.rs --no-prepend-enum-name \
    --blocklist-file inc/fmod.h \
    --blocklist-file inc/fmod_codec.h \
    --blocklist-file inc/fmod_common.h \
    --blocklist-file inc/fmod_dsp.h \
    --blocklist-file inc/fmod_dsp_effects.h \
    --blocklist-file inc/fmod_errors.h \
    --blocklist-file inc/fmod_output.h

/crates/fmod-studio-sys/inc> bindgen     fmod_studio.h -o bindings.rs --no-prepend-enum-name \
    --blocklist-file     fmod.h \
    --blocklist-file     fmod_codec.h \
    --blocklist-file     fmod_common.h \
    --blocklist-file     fmod_dsp.h \
    --blocklist-file     fmod_dsp_effects.h \
    --blocklist-file     fmod_errors.h \
    --blocklist-file     fmod_output.h

Expected Results

These two invocations would generate identical or nearly identical results.

Actual Results

The invocation from /crates/fmod-studio-sys uses old rust-target idioms (e.g. __BindgenUnionField instead of union) and does not include the definitions from the blocklisted files.

The invocation from /crates/fmod-studio-sys/inc uses current rust-target idioms (e.g. union instead of __BindgenUnionField) and includes the definitions from the blocklisted files.

--dump-preprocessed-input shows the only preprocessed input difference as the line directives' filenames. Something spooky is going on.

> bindgen --version
bindgen 0.59.2

[emilio]

This is an issue with file blocklisting (haven't dug if it's a bug or just a weird side effect of whatever's going on).

If you diff the generated bindings, you'll see that the inc/ version has a bunch of constants that the other version doesn't like FMOD_DSP_TYPE_TREMOLO. So the --blocklist-file fmod_dsp_effects.h flag is not working as expected.

[emilio]

It seems like the filename we're testing against is ./fmod_dsp_effects.h rather than fmod_dsp_effects.h... This comes directly from clang_getFileName, it seems a bit unexpected

[CAD97]

The use of symlinks in the linked repo might also be relevant.

[CAD97]

Ok... I've just regenerated bindings with rust-bindgen 0.60.1 (previously 0.59.2), and found something interesting:

bindgen fmod_studio.h --blocklist-file ./fmod_common.h blocklists the items from fmod_common.h but uses __BindgenUnionField. bindgen fmod_studio.h --blocklist-file fmod_common.h fails to blocklist the items from fmod_common.h and uses union.

I retain my assessment that something spooky is going on. It seems though that maybe the cwd stuff is libclang, but the blocklist stuff is bindgen (somehow), given this difference.

[emilio]

The difference between __BindgenUnionField or not depends on the blocklist behavior, because it depends on whether bindgen thinks it can safely derive Copy for those things. So that sounds expected at least.

[CAD97]

With modern Rust at least you can make a union of any type if you wrap it in ManuallyDrop, so perhaps that's just a missing feature (wrap unknown Copy types in ManuallyDrop rather than using __BindgenUnionField).