[Development] QTBUG-111330: moc help needed: parsing QtDBus Q_NOREPLY
Fabian Kosmale
fabian.kosmale at qt.io
Mon Mar 13 16:46:03 CET 2023
Hi,
I can look into fixing this from the moc side. Is there any smaller, self-contained reproducer than KWallet?
Regards,
Fabian
________________________________________
Von: Development <development-bounces at qt-project.org> im Auftrag von Thiago Macieira <thiago.macieira at intel.com>
Gesendet: Montag, 13. März 2023 16:38
An: development at qt-project.org
Betreff: [Development] QTBUG-111330: moc help needed: parsing QtDBus Q_NOREPLY
This is a P1 blocker for 6.5.0.
TL;DR: This is a regression; I broke parsing of previously working code and
don't know how to fix it.
The Q_NOREPLY marker is emitted by qdbusxml2cpp to use a little known moc
feature of extracting "tags" from meta-method declarations and having them
available in the QMetaMethod::tag(). This has been in use in QtDBus since 4.2
in 2006, and it's a feature that predated QtDBus. I just made use of it then.
The feature was designed based on where GCC put the __attribute__ markers and
MSVC put the __declspec markers back in the day. It's NOT where C++11 decided
to put the [[attribute]] markers. So when Q_DECL_DEPRECATED is [[deprecated]],
the emitted marker was in the wrong position. Commit
f67b32e735cbbed6848b5d40a61329f71f54a14d fixed that by moving the
Q_DECL_DEPRECATED to the right position, which is the left. I also moved
Q_NOREPLY.
That broke moc and the task was created:
"error: Not a signal or slot declaration"
So I partially reverted in 5d563135e8b32d8cd2508bcfac36561b469c3c6c because I
didn't know how to fix moc. Now moc no longer emits that error, but produces
nonsensical code according to the reporter.
QtPrivate::TypeAndForceComplete<Q_NOREPLY, std::false_type>,
Since I've already moved Q_NOREPLY to where it was, I don't know what's wrong.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
More information about the Development
mailing list