Rust-bindgen: bindgen chokes on non-empty macro prefix to namespaces

[jonhoo]

Input C/C++ Header

#define nssv_inline_ns inline
nssv_inline_ns namespace literals {}

Bindgen Invocation

$ bindgen input.h -- --std=c++11 -x c++

Actual Results

thread 'main' panicked at 'Unknown token while processing namespace: ClangToken { spelling: CXString { data: 0x7f00940c0978, private_flags: 0 }, kind: 2 }', /home/jon/.cargo/registry/src/github.com-1ecc6299db9ec823/bindgen-0.51.1/src/ir/context.rs:2164:21
stack backtrace:
...
  13: bindgen::ir::context::BindgenContext::module
  14: <bindgen::ir::item::Item as bindgen::parse::ClangItemParser>::parse
  15: bindgen::parse_one
  16: bindgen::clang::visit_children

Expected Results

I would expect bindgen to not crash, and to instead produce the same results as if it were given

inline namespace literals {}

Which compiles just fine (and produces an empty generated file).

Interestingly enough, this code also compiles fine:

#define nssv_inline_ns
nssv_inline_ns namespace literals {}

[emilio]

Hmm, this one is tricky because clang tokens don't let us easily see through the ifdef tokens. Ideally there'd be a better way to extract this information...

[jonhoo]

It's also a bit awkward, because if this pattern appears anywhere in the header hierarchy, then bindgen cannot be run on it. No amount of blacklisting will make bindgen not walk into the relevant header file, and then fail during parsing.

[emilio]

Yeah we should probably be more resilient to this and not crash, at least, even if it means making the namespace non-inline if we choke or something.

[jonhoo]

@emilio Do you have an idea of how difficult such a feature would be to add and how I might go about it? It's currently blocking me from generating Rust bindings for Ray (it transitively depends on Apache Arrow, which has that pattern).

[emilio]

Probably a matter of turning this panic! into an error!, and landing a test?

https://github.com/rust-lang/rust-bindgen/blob/8d85c3b2cfa55b16b28cd72a4e8fa6cff387b68d/src/ir/context.rs#L2170

[jonhoo]

@emilio PR filed in #1678 :)

[jonhoo]

Do you have a sense for when the next bindgen release with this fix will be published?

[emilio]

I published 0.52.0 a bit ago, sorry for the lag.