Rust-bindgen is a crucial tool for integration of Rust into existing C/C++ projects, and for the use of libraries written in C/C++. However, it doesn't seem to be getting the level of attention it needs. It's not that it's un-maintained (last commit was Thursday, and there is a steady stream of commits) but that some pull requests seem to linger waiting for review indefinitely.
Macro support is currently not great (Bindings for define statements using scientific notation · Issue #2881 · rust-lang/rust-bindgen · GitHub, bindgen generating `i64` instead of `u64` · Issue #2874 · rust-lang/rust-bindgen · GitHub, Signedness mismatch · Issue #1594 · rust-lang/rust-bindgen · GitHub, UINTMAX64 can never be generated · Issue #2822 · rust-lang/rust-bindgen · GitHub, Missing constant defines when definition is a cast · Issue #2732 · rust-lang/rust-bindgen · GitHub), and a re-write of macro support has been an open PR since 2022, with the last review comments being from 2023. (I haven't reviewed that PR myself so I'm not saying "merge this now!" - but good macro support is important.)
I've had a soundness fix open since January 2023 with no review - Block function bindings which pass extended floats by value by GKFX · Pull Request #2403 · rust-lang/rust-bindgen · GitHub. Out of 25 open PRs, there are about 10 older PRs which have just been left awaiting review, which is not that many in terms of the amount of additional maintenance time needed, but is an indicator that the existing level of resources aren't keeping pace. I think it would be helpful for the bindgen repository to enable Rustbot's waiting-on-author/waiting-on-review tag mechanism so there is visibility of what is blocking each PR.
There also hasn't been a release since February, despite requests for one.
I'm not sure how the Rust Project or Foundation allocate resources in terms of maintainers, or whether the current two maintainers are doing this in a paid capacity etc. However, there is a sharp contrast with rust-lang/rust, where reviews are very prompt.
Lastly, I don't want this to seems in any way critical of the current two maintainers, who are doing excellent work. It just looks like more resources are needed.