-
Notifications
You must be signed in to change notification settings - Fork 707
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added Objc category inheritance #1784
Conversation
* Added items_mut to BindgenContext * Added Clone to ObjCInterface, ObjCMethod and FunctionSig :/ * Added references to the ObjCInterfaces for categories that extend a given ObjCInterface
* Added a bunch more tests to prevent future breakage.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know enough about objective-c categories, but iterating all the items like that is not acceptable.
The way bindgen is designed to deal with this kind of stuff is via type references. Is there a way you can inspect the categories from the clang ast while parsing the original interface?
@@ -37,6 +37,9 @@ pub struct ObjCInterface { | |||
/// The list of protocols that this interface conforms to. | |||
pub conforms_to: Vec<ItemId>, | |||
|
|||
/// The list of categories (and the template tags) that this interface is extended by. | |||
pub categories: Vec<(String, Vec<String>)>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why shouldn't these be ItemId
s?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These should probably be ItemId
s. After seeing #1889, it looks like you can use categories to add more protocol conformance :/
I've tried a few things to use
it actually turns out to be the id of the class (the If I do:
it segfaults which is neat. If I do:
it returns an opaque type for that id when I try to do generation. So, I'm not sure how to get the
yields the |
What's the stack for that? It might be that you're overflowing the stack.
Why do you need to mutably borrow it? |
Yeah, after a adding some debug statements, it looks like that call ends up overflowing the stack. Though, it doesn't yield a stack trace nor a normal rust error like In hindsight, I forgot to answer this question:
Hmm. https://clang.llvm.org/doxygen/structclang_1_1serialization_1_1ObjCCategoriesInfo.html#details seems promising. I'm not sure how to use it though.
If we can't get the list of categories while parsing the original class, the only way I think we can get the |
…category-inheritance
…category-inheritance
…category-inheritance
…category-inheritance
…category-inheritance
43240cf
to
996af2e
Compare
@scoopr are you available for a review? This PR adds a key feature to bindgen for objective-c support. |
I did a fairly quick look at the diff, and from what I gather it looks good to me! Can't really comment on the specifics of the implementation as I'm not too familiar with that anymore. The expectation test result look great to me :) |
src/codegen/mod.rs
Outdated
@@ -3913,6 +3913,28 @@ impl CodeGenerator for ObjCInterface { | |||
} | |||
}; | |||
result.push(impl_trait); | |||
for (category_name, category_template_names) in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So here's a thought, is there any reason we can't just implement this when generating code for the ObjCInterface
?
It feels weird that stuff that would be blacklisted would implement these traits and so on. It should also avoid the weird lookup, right?
As in, instead of keeping the category
as a String
in the interface, you would keep the ItemId
. Then when doing code generation you can do the lookup just fine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is an interesting idea. I'm not a big fan of String
for the type of category
. I'll try this out.
…category-inheritance
…category-inheritance
…category-inheritance
…ndgen into objc-category-inheritance
…ndgen into objc-category-inheritance
☔ The latest upstream changes (presumably 4f714ab) made this pull request unmergeable. Please resolve the merge conflicts. |
f540a82
to
78bf091
Compare
After some messing around with trying to make Anyway, @emilio thoughts on the way forward? |
☔ The latest upstream changes (presumably 11ae350) made this pull request unmergeable. Please resolve the merge conflicts. |
☔ The latest upstream changes (presumably #2284) made this pull request unmergeable. Please resolve the merge conflicts. |
This closes #1779.
This is done by adding:
items_mut
onBindgenContext
which is justiter_mut
on the items because a category needs to modify an item to add the name of a category, and the template names from that category. This method most certainly results in very very bad performance but I really don't know how to get a reference to theObjCInterface
using just a name. So :/Vec<(String, Vec<String>)>
. I'm open to making this a struct, I just kinda don't know what to call it.I originally had the
categories
field as aVec<Box<ObjCInterface>>
and thenclone()
ed the interface after it was finished being built. You can see what that's like here. It required derivingClone
onObjCInterface
,ObjCMethod
, andFuncionSig
. I thinkVec<(String, Vec<String>)>
is cleaner but still a bit gross.I also noticed that there's a lot of the templates when generating bindings. Here's an example for the Foundation Framework. So, I added a bunch of tests for the different inheritance cases - categories, templates, and categories that are templates.