[BUG] `surface_control.h` and `*font*.h` contains C++ constructs

[MarijnS95]

Description

I maintain the Rust ndk and ndk-sys crates, and they rely on bindgen to parse C headers.

Unfortunately, while attempting to generate these for the font headers and later surface_control.h Rust's bindgen utility complains that the headers are not valid C (these things only work in C++):

~/Android/Sdk/ndk/26.0.10404224/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/android/font.h:102:18: error: must use 'struct' tag to refer to type 'AFont'
~/Android/Sdk/ndk/26.0.10404224/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/android/font.h:124:50: error: must use 'struct' tag to refer to type 'AFont'
~/Android/Sdk/ndk/26.0.10404224/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/android/font.h:194:32: error: must use 'struct' tag to refer to type 'AFont'
~/Android/Sdk/ndk/26.0.10404224/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/android/font.h:204:27: error: must use 'struct' tag to refer to type 'AFont'
~/Android/Sdk/ndk/26.0.10404224/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/android/font.h:218:45: error: must use 'struct' tag to refer to type 'AFont'
~/Android/Sdk/ndk/26.0.10404224/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/android/font.h:232:39: error: must use 'struct' tag to refer to type 'AFont'
~/Android/Sdk/ndk/26.0.10404224/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/android/font.h:265:33: error: must use 'struct' tag to refer to type 'AFont'
~/Android/Sdk/ndk/26.0.10404224/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/android/font.h:280:33: error: must use 'struct' tag to refer to type 'AFont'
~/Android/Sdk/ndk/26.0.10404224/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/android/font.h:295:32: error: must use 'struct' tag to refer to type 'AFont'
~/Android/Sdk/ndk/26.0.10404224/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/android/font_matcher.h:135:1: error: must use 'struct' tag to refer to type 'AFontMatcher'
~/Android/Sdk/ndk/26.0.10404224/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/android/font_matcher.h:144:27: error: must use 'struct' tag to refer to type 'AFontMatcher'
~/Android/Sdk/ndk/26.0.10404224/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/android/font_matcher.h:159:9: error: must use 'struct' tag to refer to type 'AFontMatcher'
~/Android/Sdk/ndk/26.0.10404224/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/android/font_matcher.h:175:9: error: must use 'struct' tag to refer to type 'AFontMatcher'
~/Android/Sdk/ndk/26.0.10404224/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/android/font_matcher.h:190:9: error: must use 'struct' tag to refer to type 'AFontMatcher'
~/Android/Sdk/ndk/26.0.10404224/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/android/font_matcher.h:211:1: error: must use 'struct' tag to refer to type 'AFont'
~/Android/Sdk/ndk/26.0.10404224/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/android/font_matcher.h:212:15: error: must use 'struct' tag to refer to type 'AFontMatcher'
~/Android/Sdk/ndk/26.0.10404224/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/android/surface_control.h:343:57: error: C does not support default arguments
~/Android/Sdk/ndk/26.0.10404224/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/android/surface_control.h:355:48: error: must use 'enum' tag to refer to type 'ADataSpace'
~/Android/Sdk/ndk/26.0.10404224/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/android/surface_control.h:379:83: error: expected ')'
~/Android/Sdk/ndk/26.0.10404224/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/android/surface_control.h:378:37: note: to match this '('

Missing struct and enum tags

These are easy enough (but ugly) to work around with typedefs:

typedef enum ADataSpace ADataSpace;
typedef struct AFont AFont;
typedef struct AFontMatcher AFontMatcher;
typedef struct ASystemFontIterator ASystemFontIterator;

Language features we cannot work around

Default function arguments

~/Android/Sdk/ndk/26.0.10404224/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/android/surface_control.h:343:57:

void ASurfaceTransaction_setBuffer(ASurfaceTransaction* transaction,
                                   ASurfaceControl* surface_control, AHardwareBuffer* buffer,
                                   int acquire_fence_fd = -1) __INTRODUCED_IN(29);

C++ references instead of pointers

/home/marijn/Android/Sdk/ndk/26.0.10404224/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/android/surface_control.h:379:83 (and at more places):

void ASurfaceTransaction_setGeometry(ASurfaceTransaction* transaction,
                                     ASurfaceControl* surface_control, const ARect& source,
                                     const ARect& destination, int32_t transform)
                                     __INTRODUCED_IN(29);

Affected versions

r25, r26

Canary version

No response

Host OS

Linux

Host OS version

Arch Linux

Affected ABIs

armeabi-v7a, arm64-v8a, x86, x86_64

Build system

Other (specify below)

Other build system

bindgen on headers only

minSdkVersion

Irrelevant for header codegen

Device API level

No response

[DanAlbert]

Hmm. I'd like to fix this in r26 but that particular component has gotten tricky to update now that rv64 is in the development branch. It isn't a regression in r26, so this may slip to r27. I don't think that would be a problem for your use case because you could just update those projects from the canary anyway. Really you probably don't even need an NDK and could just pull the sysroot from ci.android.com.

[enh-google]

(and i guess this is another vote for "we really should get around to setting up the 'check that every header can be included in .c files' test" that comes up every year or so...)

[MarijnS95]

I could even fix the signatures locally to get it to build. Generating from canary might be more worrisome if that includes possibly unstabilized/unfinished APIs?

Generating from the NDK means we have a stable version our userbase can go off of.

[DanAlbert]

Generating from canary might be more worrisome if that includes possibly unstabilized/unfinished APIs?

The data needed to avoid those is there (__attribute__((availability))), but you're probably right that cbindgen doesn't read it.

[MarijnS95]

I don't think we get those passed on, neither do we see the __INTRODUCED_IN(29) even though those would be super useful to automatically generate #[cfg(feature = "api-level-{}")] on the Rust side.

Maybe we can with a custom bindgen callback though.

[DanAlbert]

For most APIs (doesn't work for libc/libm because reasons) you need https://android.googlesource.com/platform/ndk/+/master/docs/BuildSystemMaintainers.md#Weak-symbols-for-API-definitions or the decl will be hidden from cbindgen.

[MarijnS95]

This is not enabled by default because, unless used cautiously, this method is prone to deferring build failures to run-time (and only on older devices, since newer devices will have the API).

It would be helpful for us for similar reasons: if we build-test our NDK high-level wrapper crate against every API version, we can very easily spot mismatches (when a symbol is used in the high-level wrapper without the appropriate cfg-guard).