--generate-block panics on typedef F (^Blk) when F is a function typedef

Input C/C++ Header

typedef void F(int);
typedef F (^Blk);
int take(Blk b, int t);

Bindgen Invocation

$ bindgen input.h --generate-block -- -x c -std=gnu11 -fblocks

Actual Results

bindgen aborts:

panicked at bindgen/codegen/mod.rs:957:25:
invalid block typedef: Item { ... kind: Alias(...) ... }

clang accepts this (-fblocks). Blk is a block pointer whose pointee is the typedef F. --generate-block codegen of TypeKind::BlockPointer resolves the pointee with through_type_refs() only, then requires TypeKind::Function.

typedef void (^Blk)(int); does not panic (inner is already FunctionProto). The same header without --generate-block maps Blk to *mut c_void (the documented default) and does not panic.

tests/headers/blocks.hpp only uses void (^)(void) / typedef bool (^name)(...), where the inner type is already Function.

Expected Results

Do not abort. Peel the typedef (through_type_aliases() / canonical_type()) and emit *const Block<(c_int,), ()> like the direct-syntax form.

Environment

bindgen: 0.73.1 (rust-lang/rust-bindgen 77cbc723)
clang/libclang: Homebrew clang 21.1.8
rustc: 1.97.1
target: aarch64-apple-darwin
OS: macOS

Start in bindgen/codegen/mod.rs around line 957 and inspect the TypeKind::BlockPointer path, especially its use of through_type_refs(). Compare this with through_type_aliases() and canonical_type(). Use tests/headers/blocks.hpp and the reported header as regression inputs; done means the typedef-based block no longer panics and produces the expected Block binding.