merge into upstream!

[Yamakaky]

Did you consider to merge your modifications into my repo? We both added a lot of features, it would be great if we could join forces.

[Manishearth]

We'd love to. Some of the modifications might be servo-specific though, so we should be careful when merging.

[metajack]

We've consolidated all the forks we knew about in servo/rust-bindgen. I don't think we were aware of yours.

It would be highly preferable for there to be a single rust-bindgen. If it looks possible to consolidate these, I think we'd love to do it. Perhaps we should ask the Rust team if this is appropriate to move to rustlang/bindgen or something more official.

[Yamakaky]

In fact, crabtw transfered me the ownership since he was inactive since a few months and I was the only commiter ^^

[metajack]

Huh. I thought we had asked crabtw to transfer it to us a long time ago and he preferred not to do that. In any case, it's all water under the bridge and we should try and get down to a single bindgen if at all possible.

[Yamakaky]

I agree. What do you suggest?

[metajack]

Someone needs to look at the commit history since the forks diverged and see how much work it is to unify, and then we need to do the unification.

And then we need to decide where the official repo will be, and then recreate personal forks to be from that one.

Finally, we'll need to hook up CI and decide on reviewers and such. I think there are approximately 3-4 people on the Servo team who've been contributing to bindgen.

The main piece of work is the first part. The rest is relatively trivial.

[emilio]

So I tried the "YOLO rebase the world on top of upstream approach" a while ago, and it didn't work as well as I'd expected, there are a lot of non-trivial changes, so I think the way to go is upstreaming features individually. But that's a really time consuming thing to do.

Probably one of the easiest part that would simplify a lot upstreaming more features is upstreaming the types.rs changes first, since that file hasn't been modified a lot upstream.

On top of that, I think the best approach is porting our tests, and making them pass one at a time, since there are a few tricky cases there. I'd love to do this, but unfortunately I don't think I'll have the time to do it near-term.

Nonetheless, does that approach sound good to you?

[Yamakaky]

yeah, yolo is not a good approch in this case ^^
I also think it would be easier. We can also start with clang.rs.
BTW, I replaced the manual argument parsing with docopt, and clangll.rs by the crate clang-sys.
I will start by integrating types.rs in my repo.

[Yamakaky]

in fact, WIP on clang.rs

[Yamakaky]

Just finished clang.rs. It changes the supported clang version requirement:

= 3.6: clang_Cursor_getTemplateArgumentValue and Kind, clang_Cursor_getMangling
= 3.8: clang_getCursorVisibility, clang_CXXField_isMutable
= 3.9: clang_Type_getNamedType, clang_Cursor_isFunctionInlined
WIP KyleMayes/clang-sys#35 for all the HTML and Comment functions.

See http://llvm.org/releases/. Ok for 3.6, but 3.8 was released on march and 3.9 even after, so it may not be too supported. Are these functions really needed?

[emilio]

That's one of the reasons we haven't switched to clang-sys completely. We need to be able to compile on stable clang, but llvm 3.9 is needed for SpiderMonkey bindings.

We use conditional compilation for that, and it seems to me that clang-sys have added support for that, so we could keep compiling conditionally.

[Yamakaky]

Could you list the features that needs clang 3.9?

[emilio]

Basically the ability to detect if a function is inlined and don't generate bindings for these, because they generated missing symbols.

The other 3.9 function is the named type thing, which is a backwards incompatible change from clang that was needed to fix bindgen on llvm 3.9

[emilio]

In #31 I'm adding the last test from upstream that isn't in our test suite. @Yamakaky, would you consider making this bindgen the canonical one? I think there's no situation yours can handle that ours doesn't, and even though we lose some things, like the change from manual option parsing to docopt, I don't consider those a priority right now.

[Yamakaky]

Did you go through https://github.com/Yamakaky/rust-bindgen/blob/master/Changelog.md to check?
Also, your --help is outdated, it misses all the switches you added. With docopt, it would not be a problem. The change is not hard (Yamakaky@b6f9f95).
And did you consider using clang_sys instead of clangll.rs?