Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

QCoreApplication::aboutToQuit is not a signal



  • Yesterday I updated Qt Creator:

    Qt Creator 4.14.0
    Based on Qt 5.15.2
    Built on Dec 17 2020 07:57:30
    

    This morning I re-compiled my project and a bunch of warnings are displayed with a yellow background:

    QCoreApplication::aboutToQuit is not a signal [clazy-connect-non-signal]
    

    The code this appears on:

    QObject::connect(QCoreApplication::instance(), &QCoreApplication::aboutToQuit , this, &clsModHelper::terminateModule);
    

    So I thought perhaps it has been changed, so I googled and found the documentation:
    https://doc.qt.io/qt-5/qcoreapplication.html#signals
    Which is the latest and current version of the SDK, its still a signal so why the warning?

    When I then looked closed at the context help in Qt Creator when removing a ':' and retyping ':'. It seems that aboutToQuit is now a QPrivateSignal ?


  • Lifetime Qt Champion

    Hi
    Did you clean the build folder completely and rebuild it?

    It could be a false positive from clazy.



  • @mrjj , I just did a clean, then Run qmake, then Rebuild.

    Still the same, also there are others in a class I've written clsListener:

        class clsListener;
        typedef std::map<quint16, clsListener*> mpListeners;
    
        class clsListener : public QObject {
        Q_OBJECT
    
        private:
            static mpListeners msmpListeners;
            static quint16 msuint16NextPort;
    
            QTcpSocket* mpClient;
            QTcpServer* mpServer;
            quint16 muint16Port;
    
        public:
            clsListener(quint16 uint16Port, QObject* pParent = nullptr);
            ~clsListener();
    
            static void commonDecode(QAbstractSocket* psckIn);
            static clsListener* pGetListener(quint16 uint16Port);
            QTcpSocket* psckClient() { return mpClient; }
            QTcpServer* psckServer() { return mpServer; }
            static quint16 uint16NextPort() { return ++clsListener::msuint16NextPort; }
            quint16 uint16Port() { return muint16Port; }
    
        signals:
            void newConnection(QTcpSocket& robjClient);
    
        public slots:
            void onAcceptError(QAbstractSocket::SocketError socketError);
            void onDataIn();
            void onErrorOccurred(QAbstractSocket::SocketError socketError);
            void onNewConnection();
        };
    

    Now:

    QObject::connect(mpobjListener, &clsListener::newConnection  ,this, &clsModHelper::onNewConnWithSocket);
    

    The line above also has the same message for the signal newConnection.

    The same is true for other classes including QTimer::timeout:

    QObject::connect(&mstmrWatchdog, &QTimer::timeout, this, &clsModHelper::terminateModule);
    

  • Lifetime Qt Champion

    hi
    Seems the clazy plugin is a bit confused.
    They are both private signals but that just means user code cannot emit them, not
    that they are not signals at all.
    So seems like you got a new version of clazy and it warns about those privat signals.



  • @mrjj, thank you, also finding other things along the way which makes me wonder how much testing goes into this before its released? This kind of thing seems pretty fundamental.



  • @SPlatten
    Agreed, but why did you just update Qt Creator?? For precisely this reason, why don't you stick with a stable version of Qt Creator/Qt version and stick with them for a quite a while? If you want to update every time there is a new, latest version, this sort of thing happens....



  • @JonB , because I’m a fool



  • @SPlatten
    :) As you please, just saying this leads to these probs! Anyway, either it's a bug in clazy, or delete everything in the build output folder, in case there are "hidden"/other files left lying around after "build clean", which is what I do when I don't think an error is mine, and certainly after installing/upgrading anything.



  • @JonB , just tried that still exactly the same, did:

    ls -la
    

    then remove everything including hidden files.



  • @SPlatten
    The it looks like a (new) clazy issue....



  • @JonB , today I uninstalled and re-downloaded Qt and installed again, this installed Qt Creator 4.14 by default with Qt 5.15.2, the same problems are still present in this build.


  • Moderators

    @SPlatten So I had the same issue where clazy would faulty flag timeout from QTimer as not a signal, which is of course nonsense.

    But it somehow went away, and I'm not sure what caused it.

    Try one or both of the following:

    • Change the kit, it should force a revelation of your code
    • Close the project, delete the *.pro.user file, and open it again


  • @J-Hilk , I did just that, deleted build folders, removed all .pro.user.* files then re-setup project build folders and then rebuilt, unfortunately it still does the same.



  • Got the same issue with latest Qt Creator on MacOS (with iOS as project target). Clazy constantly complains about emitting and connecting non-signals - both in my own code as well as with signals from Qt classes like QTimer::timeout and so on. Full clean, rebuild from scratch and so on doesn't help.



  • @KoneTaH , I do wonder what the release criteria is before products like Qt Creator are deemed fit for release....as this is quite obvious.



  • I'm experiencing this as well.

    Could it be related to the updated version of clang included with Xcode 12? In addition to updating Qt Creator recently, I also updated Xcode on my machine (macOS 10.15).

    Looks like Qt Creator distributes its own version of clang. I'm assuming this is what the mac kits are supposed to use by default?


  • Lifetime Qt Champion

    @evan_y said in QCoreApplication::aboutToQuit is not a signal:

    Looks like Qt Creator distributes its own version of clang. I'm assuming this is what the mac kits are supposed to use by default?

    No, that clang version is for the tooling provided by Qt Creator. Qt is not built with it, only the official Apple released Xcode clang is supported.



  • @SGaist Good. That is how my environment is set up and how it's supposed to be.

    I'm still seeing the behavior reported by the OP.



  • I've also observed other odd clazy messages:

    QString strKey = QString("%1%2").arg(clsJSON::mscszAck).arg(clsJSON::mscszCmdHB);
    

    Results in:

    Use multi-arg instead [clazy-qstring-arg]
    

    This is clearly rubbish, because the other arguments in .arg are for formatting the same argument and what I have done works perfectly. I've submitted another bug for this tonight.



  • @SPlatten What are the types of those clsJSON::mscszAck and clsJSON::mscszCmdHB? If they are both strings, this clazy warning is probably correct because there are overloads with multiple string arguments:

    https://doc.qt.io/qt-5/qstring.html#arg-14

    Your code should work perfectly as well, but it may be suboptimal.


  • Lifetime Qt Champion

    You should read the documentation of the suggested arg overload before opening a report.



  • @KoneTaH they are static const char*, the prefix:

    m = member
    s = static
    c = const
    sz = null terminated string

    clsJSON is the name of the class they belong to. I tried using the multi-arg version, its just not right. As I said, regardless of the message the code works and does exactly what I intended.



  • @SGaist I have and I'm using the multi-arg version elsewhere in my code.



  • @SPlatten
    If you want to know why you are getting this warning, I suggest that https://www.kdab.com/uncovering-32-qt-best-practices-compile-time-clazy/, 29. qstring-arg, is giving you the answer:

    Detects chained QString::arg() calls which should be replaced by the multi-arg overload to save memory allocations.

        QString("%1 %2").arg(a).arg(b); // Bad
        QString("%1 %2").arg(a, b); // one less temporary heap allocation
    

    As @KoneTaH noted

    Your code should work perfectly as well, but it may be suboptimal.



  • @JonB , the problem with:

    QString("%1 %2").arg(a, b);
    

    Is that the arguments for arg depend on the types being passed, there are 22 overloaded versions, here's the first:
    (Screenshot 2021-01-15 at 07.39.49.png


  • Lifetime Qt Champion

    @SPlatten said in QCoreApplication::aboutToQuit is not a signal:

    Is that the arguments for arg depend on the types being passed, there are 22 overloaded versions, here's the first:

    This is wrong. What others are talking about is: https://doc.qt.io/qt-5/qstring.html#arg-22
    Which is a template with arbitrary number of parameters and types. The only requirements is:
    "Args can consist of anything that implicitly converts to QString, QStringView or QLatin1String.".



  • SPlatten,

    I am getting these same errors now as well. Did you ever find a solution?

    Thanks.



  • @Zetrick , No, it still does it, I've reported the bugs.



  • SPlatten,
    I'm writing this code:

    connect(set_Btn,&QPushButton::clicked,this,&Shudu::showQipan);
    

    and the qt creator also brings a prob that says:

    QAbstractButton::clicked is not a signal [clazy-connect-non-signal]
    

    do u have and idea or it's the same problem you have?



  • @Justinxiang , its a rubbish message, there are lots of issues like this where signals that are signals are reported as not being signals...check the headers and documentation you will see that your code is ok.


  • Moderators

    I disabled the check, because it drove me nuts :D
    cac4d1e7-4071-48d8-95d0-40947ae69cd8-image.png

    seems to be a MacOS problem only, doesn't happen in the same project on my Windows VM


Log in to reply