impl on MyObjectCpp

[LeonMatthesKDAB]

As discussed in #149, we probably don't want to impl everything on RustObj, as that doesn't have access to C++ methods, like emit.

Therefore, we actually want to impl on some kind of "rich pointer" that has access to both Rust & C++.
For this, why not implement on the MyObjectCpp. We could use a Qt for syntactic sugar to make this more explicit.

Example code:

#[cxx_qt::bridge]
mod ffi {
    #[cxx_qt::qobject(base=QAbstractItemModel)]
    #[cxx_qt::qobject]
    struct MyObject {
        #[qproperty]
        prop: i32,

        private_stuff: MySpecialType,
    }

    #[cxx_qt::signals(MyObject)]
    enum MySignals {
        Ready,
    }

    impl Default for MyObject {
        Self {
            prop: 42,
            private_stuff: ...,
        }
    }

    impl cxx_qt<MyObject> {
        #[invokable]
        pub fn add(self: Pin<&mut Self>) {
            let prop = self.as_ref().get_prop();
            self.as_mut().set_prop(prop + 1);

            self.as_ref().rust().thing()
        }
    }

    impl MyObject {
        fn thing(&self) {

        }
    }
}

Which would then generate:

#[cxx::bridge]
pub mod ffi {
    extern "Rust" {
        #[cxx_name="MyObjectRust"]
        pub type MyObject;

        fn get_prop(self: &MyObject) -> i32;
        fn set_prop(cpp: Pin<&mut MyObjectQt>, value: i32);
        fn create_rs() -> Box<MyObject>;

        // Rust::MyObject::add(this);
        fn add(cpp: Pin<&mut MyObjectQt>);
        // this would be better but unfortunately isn't available in CXX:
        // fn add(self: Pin<&mut MyObjectQt>);
    }

    unsafe extern "C++" {
        include!("myobject.h");

        #[cxx_name = "MyObject"]
        type MyObjectQt;

        fn rust(self: &MyObjectQt) -> &MyObject;
        #[cxx_name = "propChanged"]
        fn prop_changed(self: Pin<&mut MyObjectQt>);
        //fn my_thing(self: &MyObjectCpp) -> bool;
    }

    extern "C++" {
        unsafe fn rust_mut(self: Pin<&mut MyObjectQt>) -> Pin<&mut MyObject>;
    }
}

/* Better scoping:*/
pub use self::cxx_qt_ffi::*;
mod cxx_qt_ffi {
    use super::ffi::*;
    use std::pin::Pin;

    pub struct MyObject {
        pub prop: i32,
    }
    
    impl MyObject {
        pub fn get_prop(self: &MyObject) -> i32 {
            self.prop
        }
    }

    impl MyObjectQt {
        pub fn set_prop(mut self: Pin<&mut Self>, value: i32) {
            unsafe {
                self.as_mut().rust_mut().prop = value;
            }
            self.as_mut().prop_changed();
        }
    
        pub fn get_prop(self: &Self) -> i32 {
            self.rust().prop
        }
    
        pub fn add(mut self: Pin<&mut Self>) {
            let prop = self.as_ref().get_prop();
            self.as_mut().set_prop(prop + 1);
        }
    }

    #[cxx::bridge(namespace = "myobject::internals")]
    mod ffi {
        extern "Rust" {
            fn add(cpp: Pin<&mut MyObjectQt>);
        }

        unsafe extern "C++" {
            #[namespace = ""]
            #[cxx_name = "MyObject"]
            type MyObjectQt = super::super::ffi::MyObjectQt;
        }
    }

    pub fn create_rs() -> Box<MyObject> {
        Box::new(MyObject { prop: 42 })
    }
    
    pub fn set_prop(cpp: Pin<&mut ffi::MyObjectQt>, value: i32) {
        cpp.set_prop(value);
    }
    
    // this can work as our wrapper function, if necessary
    pub fn add(cpp: Pin<&mut ffi::MyObjectQt>) {
        cpp.add();
    }
    
}

// myobject.h
#pragma once

#include "rust/cxx.h"

#include <QtCore/QObject>

#include <memory>

class MyObjectRust;

class MyObject : public QObject
{
    Q_OBJECT

    Q_PROPERTY(int prop READ getProp WRITE setProp NOTIFY propChanged)

public:
    MyObject(QObject* parent = nullptr);
    const MyObjectRust& rust() const;
    MyObjectRust& rust_mut();

    Q_INVOKABLE void add();

    int getProp() const;
    void setProp(int value);

Q_SIGNALS:
    void propChanged();

private:
    rust::Box<MyObjectRust> m_rust;
};

// myobject.cpp
#include "myobject.h"

#include "lib.rs.h"

MyObject::MyObject(QObject* parent)
    : QObject(parent)
    , m_rust(create_rs())
{

}

void MyObject::add()
{
    // mutex

    // namespaced, myobject::internals::add(this)
    ::add(*this);
}

const MyObjectRust& MyObject::rust() const
{
    return &m_rust.get();
}

MyObjectRust& MyObject::rust_mut()
{
    return m_rust.get();
}

int MyObject::prop() const
{
    return prop(*this);
}

void MyObject::setProp(int value)
{
    set_prop(*this, value);
}

This actually compiles and works as a proper QObject.

EDITED: Removed extern "Qt" syntax.

This wasn't possible to parse with our procedural macro.

[ahayzen-kdab]

So when implementing this in #159 it has been found that to use a proc_macro_attribute the syntax needs to be valid, this means inside an extern block we can only use items listed here https://docs.rs/syn/1.0.98/syn/enum.ForeignItem.html

Options appear to be

1. Use a mod not extern then we can have any normal Item not ForeignItem
2. Potentially use a function (proc_macro) instead of proc_macro_attribute

What would this look like ?

Modules

#[cxx_qt::bridge]
mod ffi {
    mod qt {
      ...
    }
}

or

#[cxx_qt::bridge]
mod ffi {
    #[qt]
    mod gen {
        ...
    }
}

Function macro

cxx_qt::bridge!(
    mod ffi {
        extern "Qt" {
            ...
        }
    }
);

or

cxx_qt::bridge!(
    #[cxx::bridge]
    mod ffi {
        extern "Qt" {
            ...
        }
    }
);

or

cxx_qt::bridge!(
    extern "Qt" {
        ...
    }
);

[ahayzen-kdab]

To me the function macro doesn't look too bad (assuming it works) the questions i guess then are

• do we generate the mod ffi or the developer? (i think the developer so they know it exists)
• do we generate the #[cxx::bridge] on the mod ffi ? (i suppose the advantage here is that the developer can put the cxx namespace as usual in the top macro ? but we could just allow for a macro on the mod ? so i think probably no, as the developer has already indicated they want a bridge with #[cxx::bridge])
• what elements do we allow inside the cxx_qt::bridge ?
  • do we allow multiple mod ? (maybe ? but not sure what the usecase would be, they would have to have different names?)
  • do we allow other elements ? (no ? not sure of the usecase here, they are outside of a mod but inside our macro, they can just be outside of the macro?)

So with my preferences this would end up like the following, but i'm open to suggestions...

cxx_qt::bridge!(
    #[namespace = "rust"]
    mod ffi {
        extern "Qt" {
            ...
        }
    }
);

[LeonMatthesKDAB]

So, another basic question: Why do we even need an extern "Qt" block in the first place?
We need it so that we know which structs/enums are relevant for cxx_qt.
So alternatively we could allow you to simply state that for each struct:

#[cxx_qt::bridge]
mod ffi {
    #[qobject]
    struct MyObject {
        #[property]
        prop: i32
    }

    impl Qt<MyObject> {
        // ...
    }

    extern "C++" {
        // ...
    }
    extern "Rust" {
        // ...
    }
}

[LeonMatthesKDAB]

This also is a bit more "correct" I guess, as we're not actually defining anything that's "extern" to Qt.
We're defining something in Rust, that we want to expose to our ffi.

[LeonMatthesKDAB]

It's also closer to the way shared types work in CXX, which is sort of what we're doing here, as the properties are "shared" between Rust and Qt.

[LeonMatthesKDAB]

Side note:
Our current goal is an impl Qt<MyObject>.

But we were also discussing something like impl MyObject::Qt.
Unfortunately this just isn't valid syntax atm, so we can't use it.
It is however an unstable feature that we might be able to use in future:
rust-lang/rust#8995

[ahayzen-kdab]

So if there were existing attributes on the module where do they go ? eg if i had

#[attr1]
#[cxx_qt::bridge]
#[attr2]
mod ffi {

}

Do they go onto the CXX mod or onto the cxx_qt one ? or do we just not allow this ?

[ahayzen-kdab]

@LeonMatthesKDAB did we have a plan for locking related to the rust() and rust_mut() methods ? Do we still lock for the invokables/getters/setters ... but what happens in C++ if they call rust()orrust_mut()` are they "on their own" ? As these need to be public and not private for CXX to access them.

[LeonMatthes]

Also, why do we even need the rust and rust_mut functions in C++?
There, the rustobj is a member anyway, so why not just access that directly?

[LeonMatthes]

Ah, no, wait, they are defined in C++, right?
Stupid question then. See first comment though xD

[ahayzen-kdab]

Maybe we can use friend, what are you thinking? Have like another class that we bridge to Rust that is a friend or something ? Guess you could still just include it in C++ though...

[ahayzen-kdab]

And yes the "problem" is that we have a C++ class that has the Rust object as a member. Then when you are in an invokable you get a pinned mutable reference to the C++ instance and you need to be able to reach the Rust object somehow. Above we just put a rust/rust_mut methods, which is fine, just wondering what happens with locking around those or if we ignore that use case. And basically say, if you use rust/rust_mut from C++ then it's your problem.

[LeonMatthes]

Depends on where CXX ends up failing. But it will probably just have a free function somewhere that wraps the C++ member method.
So that function needs to be declared as a friend, then it should work