`--clang-macro-fallback` duplicate definitions

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

Start by reproducing the issue with the provided enum and MAX macro using bindgen's --clang-macro-fallback option. Trace how fallback macros and enum constants are emitted, then verify that generated bindings contain no duplicate definitions and preserve the intended values.