D recently added an "ImportC" feature like this.
The implementation was only 4klocs, which is pretty cool:
https://github.com/dlang/dmd/pull/12507/files…
It feels like you have this when using Rust in AOSP because you never need to use bindgen. You depend on the library, call the C code and when you modify the C code, the ABI has changed for the Rust code built with it too. So rustc doesn't do it, but it feels like it's doing it.
Cargo could provide comparable UX but I think it just doesn't have the ambition / goal to provide this. You would get better error messages from rustc being aware of it, but I don't think it's essential. I can't really see it either happening though.
Rust has a strong culture of wanting to delegate solving problem to standalone projects maintained by other people and I think it makes it a lot harder to successfully land something like this.
Before Rust cared about wanting independence from LLVM, it could have used libclang.
I think the cool thing about rustc doing it is you wouldn't need to have the intermediate output and could actually have compiler errors referring to C code instead of intermediate output that a human didn't write.
Only other thing that annoys me is that Rust code ends up not being able to use inline variants of C functions automatically and that would be a lot harder than just handling declarations. Going to be a major perf hit for Rust modules in the Linux kernel without using LTO builds.
Well, I'm assuming there's quite a difference between being able to understand the declarations and a full understanding of how to compile C code with support for all the commonly used GNU extensions, etc.