Reducing rust-analyzer check time by splitting bridge from implementation

[SanderVocke]

This could be considered a micro-show-and-tell.

I noticed that, at least in VSCode, the time for rust-analyzer to check code on saving (cargo check) is very long when making any kind of change to a Rust file that has a ccx_qt::bridge module in it. It really slows down development, especially since it takes a lock on the cargo directory preventing e.g. running tests.

I don't have a direct solution, but did find that usually, during development we tend to change a lot in method implementations and test cases, but less frequently to the bridge module itself (the object signature).

Therefore, for me it works well to provide the impl MyObject { ... }, along with any helper functions and tests related to the object, in a separate Rust file from the bridge where MyObject is declared. That way, changes to the non-bridge file will recompile very fast since no C++ needs to be generated in the background.

A small example:

qobj_release_focus_notifier_bridge.rs:

use crate::logging::macros::*;
shoop_log_unit!("Frontend.ReleaseFocusNotifier");

#[cxx_qt::bridge(cxx_file_stem="qobj_release_focus_notifier")]
pub mod ffi {
    unsafe extern "RustQt" {
        #[qobject]
        type ReleaseFocusNotifier = super::ReleaseFocusNotifierRust;
    }

    unsafe extern "RustQt" {
        #[qsignal]
        fn focus_released(self: Pin<&mut ReleaseFocusNotifier>);

        #[qinvokable]
        fn notify(self: Pin<&mut ReleaseFocusNotifier>);
    }

    unsafe extern "C++" {
        include!("cxx-qt-shoop/make_unique.h");

        #[rust_name = "make_unique_releasefocusnotifier"]
        fn make_unique() -> UniquePtr<ReleaseFocusNotifier>;
    }

    unsafe extern "C++" {
        include!("cxx-qt-shoop/register_qml_type.h");

        #[rust_name = "register_qml_singleton_releasefocusnotifier"]
        fn register_qml_singleton(inference_example: &ReleaseFocusNotifier,
                                  module_name : &mut String,
                                  version_major : i64, version_minor : i64,
                                  type_name : &mut String);
    }
}

#[derive(Default)]
pub struct ReleaseFocusNotifierRust {}

and the accompanying qobj_release_focus_notifier.rs:

use crate::logging::macros::*;
shoop_log_unit!("Frontend.ReleaseFocusNotifier");

pub use crate::cxx_qt_shoop::qobj_release_focus_notifier_bridge::ffi::ReleaseFocusNotifier;
use crate::cxx_qt_shoop::qobj_release_focus_notifier_bridge::ffi::*;
use std::pin::Pin;

pub fn register_qml_singleton(module_name : &str, type_name : &str) {
    let obj = make_unique_releasefocusnotifier();
    let mut mdl = String::from(module_name);
    let mut tp = String::from(type_name);
    register_qml_singleton_releasefocusnotifier(obj.as_ref().unwrap(), &mut mdl, 1, 0, &mut tp);
}

#[derive(Default)]
pub struct ReleaseFocusNotifierRust {}

impl ReleaseFocusNotifier {
    pub fn notify(self: Pin<&mut ReleaseFocusNotifier>) {
        debug!("Notified of focus release");
        self.focus_released();
    }
}

This example is tiny and only implements one method. But when the number of methods starts to increase this makes a large difference. Especially when working on unit tests: those can be defined in the non-bridge file, so tests can be very quickly added and debugged without re-running code generation.

This might be an obvious thing to Rust veterans, but I was surprised that this division over files is even allowed under Rust's orphaning rules. Maybe it is a bit of advice that could be included in the documentation?

[SanderVocke]

There is one downside I noticed: visibility. In order to have implementations and tests in a separate file, it is often necessary to declare the Rust struct's fields as "pub", otherwise the implementation file cannot see them. To me this is an acceptable drawback.

[ahayzen-kdab]

Yes this is allowed in Rust orphan rules as IIRC these are at the crate level, so you can impl T anywhere in your crate :-)

Note that you can use other visibility such as pub(crate) to allow it to be public to just the crate internals (eg tests) :-)

And yes maybe it is worth us having it under a tips/tricks section 🤔 As it may not be obvious that this is possible.

[LeonMatthesKDAB]

This is a super cool way to optimize build times, thank you for sharing!

Overall we should try to find a way to optimize the build times with CxxQtBuild anyhow, but this is a good workaround for now.
A big issue with the build scripts is that they will re-run if any of the bridge files change, but will then go ahead and recompile all of the bridges 🙈
That's of course an utter waste of resources if only one of the bridges changes, but it also recreates and recompiles all others.
Caching in build scripts is unfortunately not really supported by Cargo, so that would be hard to work around.

I should note that with the recent improvements to our build system, it should at least be possible to split projects into crates more easily.
That should also help speed up the build.