Please publish v2.0.1 crate: SourceRange::tokenize() crashes in debug builds on Rust >= 1.78 — PR #58 has been merged for ~22 months

[sethml]

I'm filing this to request a new crates.io release that includes the fix from PR #58.

The bug

SourceRange::tokenize() passes the raw pointer returned by clang_tokenize directly to slice::from_raw_parts without a null check. clang_tokenize can return null (e.g. for macro-expanded expressions or compiler builtins), which is undefined behavior. Starting with Rust 1.78, debug builds include precondition checks that catch this and abort:

unsafe precondition(s) violated: slice::from_raw_parts requires the pointer to be aligned and non-null

This means any user of clang v2.0.0 on current stable Rust will crash in debug builds when tokenizing certain source ranges.

The fix

@madsmtm identified and fixed this in PR #58, which was merged on April 27, 2024. The fix is a simple null check — a one-liner change. It has been sitting merged and unreleased for nearly two years.

Request

Could you please publish v2.0.1 to crates.io with this fix included? This is a soundness/crash bug that affects all downstream users on Rust 1.78+.

If you no longer have time to maintain the crate, would you be willing to either:

1. Grant publish access on crates.io to @madsmtm or another active contributor, or
2. Transfer the crate to a community-maintained account?
   In the meantime, downstream crates are forced to use release-mode workarounds or complex git-dep pins (which have their own issues — later commits in the repo fail to compile with current Rust due to a separate unsafe fn coercion breakage).

Thanks for your work on this crate!

[KyleMayes]

I'm down to transfer this crate to whoever.
I have no interest in maintaining this or clang-sys.
Just tell me what to do.

[KyleMayes]

I was going to publish a v2.0.1 in the meantime, but the crate doesn't even compile with the current version of rustc I have installed.
Maybe tomorrow.

[madsmtm]

I'd be up for passively maintaining this and clang-sys

[madsmtm]

Oh, and the compile error is fixed by #60

[KyleMayes]

I've invited @madsmtm as a collaborator on this crate and clang-sys.
I guess I can fully transfer the crates over too, if desired.

[madsmtm]

Cool, I've accepted the invites. Whether it makes sense to transfer the repositories or not IMO depends on what your plans for staying around are?

Planning a bit ahead, if you'll be available for like the next 5 years for when I need to make CI changes or branch protection or adding new collaborators, then it's fine for me to let it stay under your account. If not, then maybe we should consider transferring the repo as well (either to me or to a new GH org?). But we can also take that discussion later.

I'll also need access to the crates themselves.

[madsmtm]

Also, since bindgen is the largest consumer of clang-sys, I've informed them about this on Zulip.

[sethml]

Great, @madsmtm thanks for taking this on! I'd volunteer, but so far my use of clang-rs has been AI slop, so I'm not sure I'd be a good person for it.

@KyleMayes I think you can add Mads as a crate owner by just running:
cargo owner --add madsmtm
Having multiple responsible owners generally seems like a good thing to me.

[madsmtm]

I've merged some of the outstanding PRs and filed a few issues in clang-sys for improving the API, I intend to do more but that's probably gonna be it for this week.

[madsmtm]

I've been added as crate owners of clang and clang-sys, so I'll be able to publish things now.

Still, will take me a week or two to get fully up to speed.