Asynchronous incubation of StateMachine results in non-sensical warnings

When using the declarative state machine framework and instantiating state machines asynchronously with a QQmlIncubator, we often get warning messages like the following:

[W] unknown:0 - (default): QSignalTransition: no such signal: QObject_QML_16::invokeYourself()

The QObject_QML_16 is the type of the sender object of one of the SignalTransitions that we use.

I've dug into the sources and found the reason in SignalTransition::setSender() of the declarative SignalTransition type. Having resolved the sender, it first calls QSignalTransition::setSenderObject(sender) and then QSignalTransition::setSignal(signalMethod.methodSignature()). If the state machine is not yet running, this is fine, as nothing reacts on this (yet).

However, with asynchronous instantiation, the state machine might already be running when the transitions are created. In that case, the first call to setSenderObject() ends up in QStateMachinePrivate::registerSignalTransition(QSignalTransition *transition), where the code tries to match up the sender object and the signal signature. But at this point, it's in an intermediate state: the sender object is changed, but the sender signal signature is still at its default value of SIGNAL(invokeYourself()). So it tries to look up the defaulted signal signature in a completely unrelated metaobject, which leads to the above mentioned warning.

Functionality-wise this should not be an issue, as the next line calls QSignalTransition::setSignal() and should thus immediatly rectify the situation.

It would be nice if the warning would go away, however.

At the moment we're working around this by only setting StateMachine::running to true when everything has finished incubating. That's probably the better thing to do anyway.

I currently fail to produce a minimal test case. If I condense the code, incubation seems to happen in a single pass and will thus not show the above behavior.