Support #define old_function new_function

[davidben]

Input C/C++ Header

void new_function_name(void);
#define old_function_name new_function_name

Bindgen Invocation

$ bindgen header.h

Actual Results

/* automatically generated by rust-bindgen 0.65.1 */

extern "C" {
    pub fn new_function_name();
}

Expected Results

Ideally old_function_name would also be available as an alias for new_function_name. This pattern is quite common in C libraries.

In OpenSSL, they like to define compatibility aliases like this:
https://github.com/openssl/openssl/blob/master/include/openssl/x509.h.in#L732-L742

In glibc, these may not even be compatibility aliases but the actual intended public API. E.g. my system headers say:

#   define gmtime_r __gmtime64_r
#   define localtime_r __localtime_r

It's also used to fake something like C++ inline namespace, when you want the symbol to have a prefixed name to avoid collisions, but to support callers writing another.

On the C library authoring side, we would like to do this for deprecated functions in BoringSSL, as it's much less tedious than defining a parallel function or an inline wrapper. But, were we do to this, it would break bindgen output due to bindgen insufficiently faithfully supporting C semantics. Of course, fully faithfully supporting C macros is Hard, but this case seems straightforward and common enough to be worth picking up. (When the destination is a single symbol that is a function you already know to bind.)

One caveat when doing this, the feature should not break things like this:

void foo(void);
#define foo foo

We have to do that sometimes in BoringSSL for... very dumb reasons. :-)

[KarelPeeters]

The cuda headers also do this, for example in cuda v12.2 header cuda_runtime_api.h:

#define cudaGetDeviceProperties cudaGetDeviceProperties_v2