Looks good. Thanks and welcome to Rust Qt Binding Generator.

Nice work, Carl.

The implementation language of RQBG has changed from C++ to Rust. This affects the files src/cpp.cpp and src/rust.cpp which are now src/cpp.rs and src/rust.rs.

Sure, i can give comments via Phabricator.

This could certainly become a separate experimental branch. You have commit access and also the ability to make a new branch (I think). Note however, that branches are not easily deleted on KDE infrastructure. Creating a branch moveable_objects is fine with me.

Deleting the QObject is now no memory issue. That's good progress.
I'm still wondering about the Rust side of the replaceableObject. The Rust struct should be tied to the replaceableObject.
A good practice might be to use something like

rust
struct InnerObjectData {
    ...
}
type InnerObject = Arc<Mutex<InnerObjectData>>;

Better safe than sorry. I was not familiar with this practice. I looked for some information on it and found these https://www.kdab.com/kdab-contributions-to-qt-5-0-part-5/ I found no qt.io docs on QT_NO_SIGNALS_SLOTS_KEYWORDS but using Q_SIGNALS is listed as a good idea at http://doc.qt.io/qt-5/qobject.html#Q_SIGNALS.

Very good. Weirdly, my compiler did not complain about this.

Here is test that could be added for the delete functionality:

void TestRustObjects::testObjectSetterDelete()
{
    // GIVEN
    Person person;
    InnerObject* inner = new InnerObject();
    QSignalSpy spy(&person, &Person::replaceableObjectChanged);

The reason why the above test works is

rust
#[derive(Clone)]
pub struct InnerObjectEmitter {
    qobject: Arc<Mutex<*const InnerObjectQObject>>,
    description_changed: fn(*const InnerObjectQObject),
}

The qobject is in an Arc, so when you clone it, it's not cloned, but another reference is created. When that referenced object is set to null, the reference in Person will also be null.
However any other information that got cloned is probably not wrapped in Rc or Arc. The question is if that is cloning is the intended behavior or if a single reference is desired.
The current patch allows both, but requires the user to be aware of the issue. This could be helped by documenting clearly how this works.

I tried to find an easy error in the patch with this code:

Person person;
InnerObject* inner = new InnerObject();
person.setReplaceableObject(inner);
delete inner;
QCOMPARE(person.replaceableObject(), nullptr);

To my astonishment, this test passes. How does the code know that the object is null?

No more copy constructors saves a lot of code. :-) I'll continue the review with this new version.

The Qt documentation says that QObject and derived classes should not have copy constructor or assignment operator. Is it possible to make the same functionality without them?

The copy constructor that is causing the double free is not used in the test code. Where is it needed? I've thought about it some more and see that copying the object causes more problems. If you copy an object, what do you do with the signal/slot bindings? Only one of the copies will have the binding, so when you want to remove the binding you'll have to remove it from the same copy.

This is a good start to making the nesting of binding objects more flexible.

Similar code has been committed a while ago.

The null_mut is not urgent and can be made nice later. A good test that shows how to use the features is required to let he code be maintainable.

This code is quite tricky, so I'd like it if it had some tests.

Good fixes. Just some small naming suggestions.

Looks good. Certainly good enough. I think it's readable.

If you want to be really correct, you have to remove foreign elements first or parse in a way that you ignore foreign elements.

QDomDocument is lazy, you have to explicitly ask for namespace processing.

Don't feel bad. I'm not even sure what this patch will do. I guess KRename has some renaming rules where you can use extracted information.

Apart from that I do not see any bugs, just differences in taste which I commented on and you can take as you see fit.

I added a comment that was apparently lost in my first review.

Nice addition! You might want to apply some of the suggested changes.