`bindgen` support

[madsmtm]

See rust-lang/rust-bindgen#109.

I would like to create a (temporary?) fork of bindgen that generates bindings targetting objc2. In particular, Encode and RefEncode impls, but the Message/MessageReceiver stuff has also changed.

In the end, what I really want is the ability to generate safe apis, but that's probably not gonna happen, it would at least require us to enrich every method with mutability information (NSData -length is immutable, while NSMutableData -setLength: is not), and we're never going to be able to generate a safe API for e.g. NSData -initWithBytesNoCopy:length:deallocator:.

[madsmtm]

Maybe bindgen is really only useful for -sys crates. Though that shouldn't be undermined, it would be a huge help instead of the current situation where you have to verify every single argument by hand!

[madsmtm]

Ideally the design of the bindings should make it easily possible to conform to our preferred design (that we haven't chosen yet, see #58).

Idea: In the end we have something like this:

pub struct NSBundle(ffi::NSBundle);

unsafe impl objc::Message for NSBundle {}

impl std::ops::Deref for NSBundle {
    type Target = NSObject;
    fn deref(&self) -> &Self::Target {
        NSObject::from_raw(*self.0) // Uses ffi::NSBundle's Deref impl
    }
}

impl NSBundle {
    pub fn new_with_path(path: &Path) -> Id<Self, Owned> {
        let nsstring = NSString::from(path);
        // NSString into ffi::NSString
        let obj = unsafe { ffi::NSBundle::alloc().initWithPath_(nsstring.into()) } as *mut NSBundle;
        Id::new(NonNull::new(obj).unwrap())
    }
    // new_with_url

    pub fn main() -> Option<&'static Self> { // Or Id or autorelease stuff
        let obj = unsafe { ffi::NSBundle::mainBundle() } as *mut NSBundle;
        unsafe { NonNull::new(obj).as_ref() }
    }

    pub fn path(&self) -> &NSString {
        unsafe { NSString::from_raw(self.0.bundlePath()) }
    }
}

Which uses the automatically generated bindings. The difference is as follows:

 #[repr(transparent)]
-pub struct NSBundle(NSObject);
+pub struct NSBundle(ffi::NSBundle);
 
 unsafe impl objc::Message for NSBundle {}
 
 impl std::ops::Deref for NSBundle {
     type Target = NSObject;
     fn deref(&self) -> &Self::Target {
-        self.0
+        NSObject::from_raw(*self.0) // Uses ffi::NSBundle's Deref impl
     }
 }
 
 impl NSBundle {
     pub fn new_with_path(path: &Path) -> Id<Self, Owned> {
         let nsstring = NSString::from(path);
-        let obj: *mut NSBundle = unsafe { msg_send![class!(NSBundle), alloc] };
-        let obj: *mut NSBundle = unsafe { msg_send![obj, initWithPath: &nsstring] };
+        // NSString into ffi::NSString
+        let obj = unsafe { ffi::NSBundle::alloc().initWithPath_(nsstring.into()) } as *mut NSBundle;
         Id::new(NonNull::new(obj).unwrap())
     }
     // new_with_url
 
     pub fn main() -> Option<&'static Self> { // Or Id or autorelease stuff
-        let obj: *mut NSBundle = unsafe { msg_send![class!(NSBundle), mainBundle] };
+        let obj = unsafe { ffi::NSBundle::mainBundle() } as *mut NSBundle;
         unsafe { NonNull::new(obj).as_ref() }
     }
 
     pub fn path(&self) -> &NSString {
-        unsafe { msg_send![self, bundlePath] }
+        unsafe { NSString::from_raw(self.0.bundlePath()) }
     }
 }

The benefit here is that message sends would be properly typed, and hence can't go horribly wrong like they usually can; however, it also adds an extra layer of indirection, extra compile time and just extra stuff you have to know about. So I'm not sure it's worth it like this :/

[madsmtm]

I think a place where it could be really useful would be in helping with upholding the memory management rules; e.g. returning proper types for alloc methods (so you can't accidentally call something before properly initializing it), ensuring init, copy, mutableCopy and new methods return Id/Retained-like types, and helping with autorelease stuff on all other methods.

[madsmtm]

For example, the code above is probably wrong, because bundlePath returns an autoreleased NSString (header says @property(readonly, copy) NSString *bundlePath).

So if the bindings could have generated this (or however we do the autoreleasing) instead:

pub unsafe fn bundlePath(&self, &'pool AutoreleasePool) -> &'pool NSString { ... }

It would have done me a favor!

[madsmtm]

But again, an alternative is just to use macros for most of this stuff, like objrs does.

[simlay]

Hey hey, just wanted to drop in and share some thoughts. Full disclosure... I've not really written much objective-c. Most of my knowledge of objective-c comes from adding the not-perfect-but-better-than-it-was objective-c support for bindgen so I could be wrong about some things.

I would like to create a (temporary?) fork of bindgen that generates bindings targetting objc2

I never got around to finishing/merging rust-lang/rust-bindgen#1784 but this adds the hierarchy inheritance to the categories from the objective-c. The biggest issue with this PR is that it has to do a linear search on all the objects to find the ty which is a costly look up. I found it rather necessary for doing a lot of calls.

Maybe bindgen is really only useful for -sys crates. Though that shouldn't be undermined, it would be a huge help instead of the current situation where you have to verify every single argument by hand!

Yeah, this is how I felt about it. I spent a bunch of time doing my best to have the objective-c bindgen'd stuff be as ergonomic as I could without adding anything unsound or causing UB. I really like the #[transparent] structs that are generated with a pointer to the underlying objective-c but allows for the rust to semi-typecheck stuff.

I think a place where it could be really useful would be in helping with upholding the memory management rules; e.g. returning proper types for alloc methods (so you can't accidentally call something before properly initializing it), ensuring init, copy, mutableCopy and new methods return Id/Retained-like types, and helping with autorelease stuff on all other methods.

I tried to add impl Drop and impl Clone for objective-c structs via the "manual retain-release" counter calls. For me, this caused memory leaks as the counter could increase when an object was passed over to the objective-c side. If I recall correctly, when I passed in a UIButton to a UIView the button's counter would increase by one more than expected and this would cause a memory leak. I admit that I didn't have/implement more fine grained access things like mutableCopy and such which may have been part of this. I also admit to not actually knowing how to deal with objective-c memory management well.

Random thoughts:

• I also spent a couple days trying to figure out how to use the Nullability but couldn't figure out how to get it out of clang/llvm.
• With uikit-sys, when building it, it runs bindgen on just about every framework that uikit depends on which is a lot and this causes the compile time to be ridiculous (~3 minutes for my macbook pro). Using a blocklist or something might be helpful. I just never got around to it.
• I feel like I recall seeing stuff about bindgen getting comments near a given call but I'm not sure how to get it out of the LLVM tree. It would be very helpful for the docs if it had the documentation around a given objective-c call. This would be super helpful for the user of a given -sys crate as they wouldn't have to have two sets of documentation open (the rust and the objective-c).
• I really like the From and TryFrom implementations for various structs to allow for upcasting/downcasting. Now that I re-think it, I'd actually have some of the generated instantiation calls like initWithFrame_(self, frame: CGRect) actually do something like initWithFrame_(self, frame: S) where S: Into<CGRect>
• Not to say that bindgen should be used for uikit but the fact that the uikit-sys crate has ~50 traits for UITextView definitely is overwhelming. I'm not sure what to do about this type of problem though.

[madsmtm]

Thanks for your input @simlay! I've also been looking at your bindgen implementations, they're definitely a nice starting point! I've also read your blog posts, actually that's a really good way to document your progress!

I tried to add impl Drop and impl Clone for objective-c structs via the "manual retain-release" counter calls

I think I've improved the situation in this crate, e.g. making it so that you don't accidentally pass Drop types to msg_send! calls.

Rough idea for how I would generate the bindings:

pub struct UIView(Object); // Instead of `id`; this means you would use `*mut UIView` where `UIView` was previously expected.

// Would be defined in `objc`
pub struct Alloc<T>(NonNull<T>);
pub struct Retained<T>(NonNull<T>);

impl IUIView {
    // Returns a type that can only be used after calling `init` on it.
    pub unsafe fn alloc() -> Alloc<Self> { ... }

    // Returns a reference-counting wrapper.
    // Need to figure this out some more, see #87
    pub unsafe fn init(s: Alloc<Self>) -> Retained<Self> { ... }

    // Alternative:
    // - self: *mut Self
    // - view: *mut UIView
    // - view: Retained<UIView> (if `addSubview:` took responsibility of releasing the object; in this case, it doesn't)
    pub unsafe fn addSubview_(&self, view: &UIView) { ... }
}

how to use the Nullability

Yeah, I can't figure that out either, I think they're bundled into the CXCursor_UnexposedAttr, changes to libclang would probably need to happen if we were to extract these.

runs bindgen on just about every framework that uikit depends

I would also really like to improve this! Especially needed if we were to have e.g. foundation-sys, it would be nice to have uikit-sys depend on the types from foundation-sys instead of defining them itself.

compile time to be ridiculous (~3 minutes for my macbook pro)

I would probably pre-generate the bindings using the latest SDKs, and try using the __API_AVAILABLE / __OS_AVAILABLE / NS_AVAILABLE / ... macros to add availability hints that would make the functions unavailable when MACOSX_DEPLOYMENT_TARGET / IPHONEOS_DEPLOYMENT_TARGET / ... is set too low.

Another idea is to use cargo features, where enabling e.g. the nsstring feature would only include <Foundation/NSString.h>.

comments near a given call

Yup, that would be reeeeally nice!

I really like the From and TryFrom implementations for various structs to allow for upcasting/downcasting. Now that I re-think it, I'd actually have some of the generated instantiation calls like initWithFrame_(self, frame: CGRect) actually do something like initWithFrame_(self, frame: S) where S: Into<CGRect>

I'm not totally sure TryFrom is safe, see discussion in #58, something something lifetimes, but will definitely consider it. Another argument against it is that it's extra code for something I suspect you use relatively rarely (and you'd have to implement in your safe wrapper as well), but I could very well be wrong about that!
Agree about the where S: Into<CGRect> though!

[madsmtm]

I think I found a way forward on the nullability, see rust-lang/rust-bindgen#1791 (comment)!