clang::source::SourceRange::tokenize can construct a slice with a null pointer, which is UB

[saethlin]

This is detectable through the standard library's debug assertions, which are currently only usable on a nightly compiler with -Zbuild-std, or if you build your own compiler and standard library with them enabled. That's what was done in the crater run which yielded this build log: https://crater-reports.s3.amazonaws.com/pr-101929/try%233bbb5242a8064de4ca3af4036745ddf603ddaa85/reg/printimg-0.5.5/log.txt among many others.

The problem (if it exists) is in this code:

clang-rs/src/source.rs

Lines 447 to 449 in 79f83c7

	clang_tokenize(self.tu.ptr, self.raw, raw.as_mut_ptr(), count.as_mut_ptr());
	let (raw, count) = (raw.assume_init(), count.assume_init());
	let raws = slice::from_raw_parts(raw, count as usize);

It's not uncommon for C APIs to return a null pointer and 0 length (font-kit has made the same mistake), but in Rust it's not valid to construct a slice from a null pointer, because slice::from_raw_parts actually returns a reference and references must not be null.

Here is the top of a backtrace from a core dump from one of many crates which depend on opencv, whose build process depends on version 1 of this crate:

#0  core::slice::raw::from_raw_parts::runtime<clang_sys::CXToken> () at /home/ben/rust/library/core/src/slice/raw.rs:93
#1  core::slice::raw::from_raw_parts<clang_sys::CXToken> (data=0x0, len=0)
    at /home/ben/rust/library/core/src/intrinsics.rs:2195
#2  0x0000557e09566b31 in clang::source::SourceRange::tokenize (self=0x7fabfb1ef0f0) at src/source.rs:449
#3  0x0000557e0932c838 in opencv_binding_generator::field::Field::default_value (self=0x7fabfb1ef320) at src/field.rs:98
#4  0x0000557e0933380a in opencv_binding_generator::func::{impl#5}::rendered_doc_comment_with_prefix::{closure#1} (
    out=0x7fabfb1ef638) at src/func.rs:609

I'd be submitting a patch, but one thing here is odd: I can only find these null slices from crates which use version 1 of this crate. Perhaps version 2 is just not used very much yet (it is surely used much less than clang-rs version 1, by about a factor of 9). Or maybe this bug doesn't come up because of some subtle change elsewhere in this library. I'm just not sure, but the fact that the code linked above doesn't check for null is suspicious.

[madsmtm]

I'm hitting this on nightly now that the standard library inlines some debug assertions.

EDIT: You already said that this would be the case...