--clang-macro-fallback duplicate definitions

[ojeda]

The macros that --clang-macro-fallback generates may conflict with the ones from e.g. an enum.

For instance, given a header that would benefit from --clang-macro-fallback, such as:

enum { A, B, MAX };
#define MAX (MAX - 1)

Then

bindgen x.h --clang-macro-fallback

generates a duplicate definition:

pub const MAX: u32 = 1;
pub const MAX: _bindgen_ty_1 = 2;

The former is the one generated by --clang-macro-fallback. The latter is the one that would normally be generated even without the option. The values may happen to differ too, as shown.

This was reduced from trying to use the --clang-macro-fallback feature in the Linux kernel (mailing list post including a kernel patch to test/debug the feature), where the compiler complains about 13 cases like this currently (i.e. with the subset of headers we pass to bindgen), e.g. https://elixir.bootlin.com/linux/v6.12.6/source/include/uapi/linux/pkt_sched.h#L598-L604

A possible workaround is to blocklist, e.g. --blocklist-item MAX (and --blocklist-var MAX) would block the first generated definition (the one from --clang-macro-fallback). Another workaround, if the enum has a name (unlike above), is to block that one instead.

Some ideas:

• It may be ideal to provide a way to control (allow/block) the ones from --clang-macro-fallback (but I may have missed how to do so), e.g. --blocklist-macro.

• It may make sense to provide a way to get these into another namespace or with a suffix or similar (I recall similar discussions for other cases/features).

• Orthogonally, it may be a good idea to have bindgen warn about this case and suggest a solution.

Cc @jbaublitz

[pvdrz]

I think there's no way to add macros to the blocklist, but you can blocklist the enum with --blocklist-item.

[ojeda]

I think I mention that above (i.e. --blocklist-item MAX) -- or do you mean something different?

Thanks!

[ojeda]

Ah, you mean the other one, i.e. if the enum has a name. (Edit: added above)

[jbaublitz]

I would be open to a prefix, but I worry that that might get confusing. I would almost prefer namespacing. I'm not sure if there's an easy answer to this, but I'm happy to do anything you two are on board with and feel would fit your use cases.