rust-bindgen
rust-bindgen copied to clipboard
c++ constexpr breaks with Mac OS native clang
The native Clang (Apple clang version 12.0.0 (clang-1200.0.32.28)) on Macs (Mac OS 10.15.7 anyway), seems to break bindgen's support for c++ header files. c header files seem fine. In particular, it seems to break the constexpr keyword.
$ echo 'constexpr int test = 1;' > test.hpp
$ bindgen --version
bindgen 0.56.0
$ bindgen test.hpp
test.hpp:1:1: error: unknown type name 'constexpr'
test.hpp:1:1: error: unknown type name 'constexpr', err: true
thread 'main' panicked at 'Unable to generate bindings: ()', /Users/ccouzens/.cargo/registry/src/github.com-1ecc6299db9ec823/bindgen-0.56.0/src/main.rs:54:36
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
$ PATH="/usr/local/opt/llvm/bin:$PATH" bindgen test.hpp
/* automatically generated by rust-bindgen 0.56.0 */
pub const test: ::std::os::raw::c_int = 1;
$ clang --version
Apple clang version 12.0.0 (clang-1200.0.32.28)
Target: x86_64-apple-darwin19.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
$ PATH="/usr/local/opt/llvm/bin:$PATH" clang --version
clang version 11.0.0
Target: x86_64-apple-darwin19.6.0
Thread model: posix
InstalledDir: /usr/local/opt/llvm/bin
Clang 12 hasn't yet been released. So it's odd that it's the version Apple is shipping. And it's not reasonable for bindgen to support a prerelease version.
I wanted to raise an issue:
- To help other people seeing this problem.
- To help the bindgen team prepare for clang 12 (if that's possible and reasonable)
- So that I (or someone else) can upgrade documentation such as requirements and the main readme.
https://github.com/ccouzens/tesseract-sys/issues/4
Hmm, this is interesting, thanks for filing. Of the recently-landed commits on LLVM, https://github.com/llvm/llvm-project-staging/commit/72131423cc952ccbd6d8e021ff7c04fa22297fe3 looks the most suspect, but it needs to be double-checked / bisected to be sure.
It'd be great if I can get to this before LLVM12 is released, but if someone can tackle this it'd be awesome.
I haven't been able to reproduce this error when building clang myself.
I tried clang built from https://github.com/llvm/llvm-project/tree/llvmorg-11.0.0, https://github.com/llvm/llvm-project/tree/llvmorg-12-init and master (llvm/llvm-project@164bcbd40e6d10cd8a01477e2e9029b955fea93b).
I tried llvm/llvm-project-staging@7213142 and staging/apple (llvm/llvm-project-staging@8e505ae71e3a493593884c692544f788e9c884ce).
Maybe this means other distributions of clang 12 won't have the problem. And when Apple next updates clang their version might not have the problem either?
Is there a way to find out what commit Apple built Apple clang version 12.0.0 (clang-1200.0.32.28) from? I couldn't find anything online.
Update: still having this issue with clang 13 as distributed with Xcode 13. Quite frustrating.
It seems really to be a apple clang specific problem, because with a brew install of llvm (Homebrew clang version 13.0.0) it works as below:
$ clang --version
Homebrew clang version 13.0.0
Target: arm64-apple-darwin21.2.0
Thread model: posix
InstalledDir: /opt/homebrew/Cellar/llvm/13.0.0_2/bin
$ bindgen --version
bindgen 0.59.2
$ echo 'constexpr int test = 1;' > test.hpp
$ bindgen test.hpp
/* automatically generated by rust-bindgen 0.59.2 */
pub const test: ::std::os::raw::c_int = 1;
However, when using the build in clang (Apple clang version 13.0.0 (clang-1300.0.29.30)) so the same major version, it fails:
$ clang --version
Apple clang version 13.0.0 (clang-1300.0.29.30)
Target: arm64-apple-darwin21.2.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
$ bindgen test.hpp
test.hpp:1:1: error: unknown type name 'constexpr'
test.hpp:1:1: error: unknown type name 'constexpr', err: true
thread 'main' panicked at 'Unable to generate bindings: ()', /Users/d34dl0ck/.cargo/registry/src/github.com-1ecc6299db9ec823/bindgen-0.59.2/src/main.rs:52:36
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace