Add a lifetime parameter to QMetaObjectConnectionGuard

[jnbooth]

Instead of requiring 'static closures, connection signal handlers now accept lifetime parameters:

pub fn on_mysignal<'a, F>(self: Pin<&mut Self>, closure: F) -> QMetaObjectConnectionGuard<'a>
where
    F: FnMut(Pin<&mut Self>) + 'a + Send,

This makes it possible to attach callbacks to signals that use scoped variables. Only QMetaObjectConnectionGuard<'static> can use .release(), so the Drop implementation will ensure all other closures are disconnected once their lifetimes have expired.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 100.00%. Comparing base (c7a92c5) to head (908dbfc).

Additional details and impacted files

@@            Coverage Diff            @@
##              main     #1263   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           73        73           
  Lines        12634     12634           
=========================================
  Hits         12634     12634           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[LeonMatthesKDAB]

Hi @jnbooth, that sounds like a nice restriction to lift.

IMO, the 'static lifetime will still be used in most cases, so ideally we should keep this case simple and ideally backwards compatible.

Can you try turning QMetaObjetConnectionGuard into a type alias, e.g.:

type QMetaObjetConnectionGuard = QScopedMetaObjectConnectionGuard<'static>;

And then rename the old QMetaObjectConnectionGuard to QScopedMetaObjectConnectionGuard (or another name if you have a better idea).

That should allow us to keep backwards compatibility.

[LeonMatthesKDAB]

Hi, this mostly looks good, but @ahayzen-kdab and I just discussed whether there's any safety concerns we need to think about here.

We found that this can probably introduce UB if the QScopedMetaObjectConnectionGuard is Send.
In theory, you could send the guard, then drop it, which could cause a race condition between the thread running the disconnection and any slot invocations inside the thread that created the connection.

One way to solve this would be to make QMetaObjectConnection not Send.
The easiest way to do this is to change it to:

#[repr(C)]
pub struct QMetaObjectConnection {
    _space: MaybeUninit<*const std::ffi::c_void>,
}

As any pointer member type will make it no longer Send and Sync.

[jnbooth]

I don't follow how that would result in UB, but I will take your word for it!