Require libclang 9.0 or newer

[Kriskras99]

Adds a check for the loaded libclang version and returns an error if the version is unsupported.

[emilio]

I think I'd rather do a warning than a hard error. We've had issues detecting versions in e.g. Apple clang.

[Kriskras99]

I have changed the error to a warning, printed using the log crate. If the user has the logging feature disabled they won't see it.

[Kriskras99]

It was removed from the merge queue for some reason

[kulp]

The merge queue has rejected the PR again, apparently due to a workflow failure that is not obvious in the current PR's UI (this seems like a GitHub UX issue to me, but merge queues are new to me).

@Kriskras99 maybe you will be able to see something there? I have only glanced at it so far.

error[E0432]: unresolved import `clang_sys::Version`
  --> bindgen/lib.rs:68:5
   |
68 | use clang_sys::Version;
   |     ^^^^^^^^^^^-------
   |     |          |
   |     |          help: a similar name exists in the module: `CXVersion`
   |     no `Version` in the root

error[E0425]: cannot find function `get_library` in crate `clang_sys`
   --> bindgen/lib.rs:748:26
    |
748 |         match clang_sys::get_library().unwrap().version() {
    |                          ^^^^^^^^^^^ not found in `clang_sys`

warning: unused imports: `Arc` and `OnceLock`
  --> bindgen/lib.rs:79:17
   |
79 | use std::sync::{Arc, OnceLock};
   |                 ^^^  ^^^^^^^^
   |
   = note: `#[warn(unused_imports)]` on by default

Some errors have detailed explanations: E0425, E0432.
For more information about an error, try `rustc --explain E0425`.

[Kriskras99]

I have no immediate ideas, I can look into it after the weekend

[Kriskras99]

It's really weird, the CI passed on my commit and the first attempt at the merge queue.
In the second attempt Rust fails to find clang_sys::Version, which has existed for 4 years already (KyleMayes/clang-sys@04ffbfa)
So it really shouldn't fail. The only thing that changed in the last few days is the Rust for Linux support: d39fc1b
@ojeda and @pvdrz any clue if your commit could break this? Is Rust for Linux using a 4 year old version of clang-sys?

[pvdrz]

That error is unrelated to the rust-for-linux workflow. I can reproduce the error if I run cargo build --no-default-features -p bindgen. My guess is that the error has to do with the runtime feature of clang-sys which is enabled on bindgen's manifest by default. Maybe the missing items actually don't exist when that feature is disabled.

[ojeda]

Thanks Christian -- yeah, I agree.

Is Rust for Linux using a 4 year old version of clang-sys?

No, Rust for Linux is not supposed to require any particular version. The test builds bindgen-cli with the given $CARGO_ARGS, which resolve to --no-default-features in that case as Christian mentions.

[Kriskras99]

Ah, that's what I was missing. Thanks for the help!

Should be fixed now, I've disabled version checks for statically linked libclang as it doesn't support version detection.
(There is clang_getClangVersion but that returns a user friendly version number in an unstable format)