Incorrect doc-comments generated for enum variants

[Michael-F-Bryan]

It looks like bindgen sees a doc-comment for a particular enum variant then keeps using the same doc-comment for every variant afterwards, instead of just the variant being documented.

Input C/C++ Header

typedef enum parameter_t {
    speed,
    acceleration,
    /// The amount of backlash in the system.
    backlash,
    desired_speed,
    position,
    desired_position,
} parameter_t;

Bindgen Invocation

$ bindgen input.h

Actual Results

pub const parameter_t_speed: parameter_t = 0;
pub const parameter_t_acceleration: parameter_t = 1;
/// The amount of backlash in the system.
pub const parameter_t_backlash: parameter_t = 2;
/// The amount of backlash in the system.
pub const parameter_t_desired_speed: parameter_t = 3;
/// The amount of backlash in the system.
pub const parameter_t_position: parameter_t = 4;
/// The amount of backlash in the system.
pub const parameter_t_desired_position: parameter_t = 5;
pub type parameter_t = i32;

Expected Results

pub const parameter_t_speed: parameter_t = 0;
pub const parameter_t_acceleration: parameter_t = 1;
/// The amount of backlash in the system.
pub const parameter_t_backlash: parameter_t = 2;
pub const parameter_t_desired_speed: parameter_t = 3;
pub const parameter_t_position: parameter_t = 4;
pub const parameter_t_desired_position: parameter_t = 5;
pub type parameter_t = i32;

[Michael-F-Bryan]

Nice issue template, by the way. It had everything I needed to fill out the issue, so the entire process was just a case of copy-pasting my minimal case across 🙂

[kulp]

Thank you for the report. I will try to look into this tomorrow. What version of bindgen are you using ?

[Michael-F-Bryan]

$ bindgen --version
bindgen 0.54.1
$ rustc --version --verbose
rustc 1.46.0-nightly (346aec9b0 2020-07-11)
binary: rustc
commit-hash: 346aec9b02f3c74f3fce97fd6bda24709d220e49
commit-date: 2020-07-11
host: x86_64-pc-windows-msvc
release: 1.46.0-nightly
LLVM version: 10.0
$ cargo --version --verbose
cargo 1.46.0-nightly (4f74d9b2a 2020-07-08)
release: 1.46.0
commit-hash: 4f74d9b2a771c58b7ef4906b2668afd075bc8081
commit-date: 2020-07-08

[kulp]

I reproduced the issue easily on my Mac.

Using dbg!() I traced this back through enum_ty.rs :

rust-bindgen/src/ir/enum_ty.rs

Line 132 in f94036f

let comment = cursor.raw_comment();

to the call to libclang's clang_Cursor_getRawCommentText :

rust-bindgen/src/clang.rs

Lines 315 to 324 in f94036f

	pub fn raw_comment(&self) -> Option<String> {
	let s = unsafe {
	cxstring_into_string(clang_Cursor_getRawCommentText(self.x))
	};
	if s.is_empty() {
	None
	} else {
	Some(s)
	}
	}

The immediately preceding code has already established that the Cursor is of kind CXCursor_EnumConstantDecl, which is what I would expect, and which rules out that we are pointing at the whole enum instead of one of its variants.

The undesired behavior seems to come directly from libclang. The behavior does not seem very useful in the way it is implemented. I will try to look into whether this is a libclang bug.

@emilio, does what I wrote make sense ?

[emilio]

Yeah, this seems like a libclang bug. Thanks for chasing it down!

bugs.llvm.org requires an account, let me know if you can't file it and I can do that. Generally folks in there have been receptive at our bugfixes for bindgen, though it's sometimes hard to find reviewers. If you end up fixing it upstream please drop a link here and I can make sure the right folks look at it.

[kulp]

I have requested an account on bugs.llvm.org. I will try within the next week to make a reproducer for this that does not require Rust.