Cargo.lock pins hts-sys 2.2.0 (bindgen 0.69), which fails to build against current LLVM

[BenjaminDEMAILLE]

Building v0.2.1 on Linux with a current LLVM (22.1.8, via LIBCLANG_PATH) fails in rust-htslib with 11 errors, all of the same shape:

error[E0609]: no field `n_targets` on type `sam_hdr_t`
     |
1460 |         unsafe { slice::from_raw_parts(inner.target_len, inner.n_targets as usize) };
     |                                                                ^^^^^^^^^ unknown field
     = note: available field is: `_address`

error[E0609]: no field `block_address` on type `hts_sys::BGZF`
error[E0609]: no field `text` on type `sam_hdr_t`
...
error: could not compile `rust-htslib` (lib) due to 11 previous errors

The _address-only fields are the giveaway: bindgen emitted sam_hdr_t and BGZF as opaque types instead of parsing the htslib struct definitions, so rust-htslib's own code no longer compiles against its generated bindings.

Cause: Cargo.lock pins hts-sys 2.2.0, which requires bindgen ^0.69.4 (resolving to 0.69.5). That bindgen release predates the libclang versions now shipping and mis-parses the headers.

hts-sys 2.2.1 moved to bindgen ^0.72.1, which handles current clang. Since rust-htslib 1.0.0 (and 1.0.1) both declare hts-sys ^2.2.0, a lockfile refresh is enough, no manifest change needed:

cargo update --package hts-sys

Would you be willing to bump the lockfile and cut a release with it? Distro packaging builds from the tagged tarball with --locked, so the pinned 2.2.0 is what gets compiled, and the build only succeeds if an older libclang happens to be installed.

For reference the macOS build is unaffected, since the Command Line Tools ship an older libclang than Homebrew's current llvm.

Context: packaging RustQC for Homebrew; its Linux CI has the current LLVM. Happy to send the lockfile PR if that helps.

[ewels]

Yes can do. Thanks for investigating!

[BenjaminDEMAILLE]

Yes can do. Thanks for investigating!

Done (and some other)