rust-bindgenのupstreamが変わった

cargo:bindgenのupstreamがYamakaky/rust-bindgenからservo/rust-bindgenに変わった。変わった結果どうなったかというと、C++のヘッダのパース機能が大幅に改善したりする。

rust-bindgenを知らなかった人に簡単に解説しておくと、clangを使ってC/C++のヘッダをパースして、それを元にRustのC FFI binding用途のglue codeを生成するcrateのこと。

元々rust-bindgenはRust ProjectではなくJyun-Yan Youが始めたらしい。らしいというのは「git logを辿った限りだとそうなっている」以上のことを言えないから。その後、メンテナー間での移譲があったのかどうかはよくわからないが、2015年末の時点ではYamakaky/rust-bindgenがupstreamとなっていた記憶がある。自信ないけど。

Mozillaがstylo（Quantum CSS）をやる関係でC++で書かれたGeckoとのglue codeを作る必要が出て、2015年の後半ぐらいからservo/rust-bindgenとしてforkしてMozillaのpaid staffが用が足りるようになるまでコードを書いていた（今も続いている）。元々のbindgenはC++サポートはそんなに強く無かったと記憶しているけど、Mozilla側で手を突っ込みまくった結果として改善され、たとえばleveldbのC++ヘッダが丸々パース可能だったりする（実体験）。

で、merge into upstream! · Issue #21 · servo/rust-bindgenというissueが立っていて、色々あったんだけど、最終的にservo側がupstreamを引き継ぐことになった。

RFC 1774で2017年のターゲットの一つにC/C++との相互運用を挙げているし、Servoがupstreamを引き継ぐのは間違っていないのではないかな。RFCを考えるとrust-lang-nurseryが引き継ぐのが一番いいけれども、Rust Project最大のパトロンであるMozillaの一門であるServo Projectの下に置いておくのは妥当なように思う。

生成されるコードは何も指定しないと大きい。依存先を含めてシンボルを再帰的に変換していくので当然といえば当然である。 実用上はpublic apiだけを変換対象のホワイトリストに指定することのほうが多いと思う。なんとか-sysを作るための道具なので、そこで生成したコードをそのままアプリケーションコードから呼ぶべきではない。

使い方？それはREADMEでも読めばいいんじゃないかな。