What could cause clang to error, but gcc compiles it anyway?

[fcarney]

I have this code:
"this" is an object that inherits from QObject

QObject::connect(this, SIGNAL(doQuit()), qApp, SLOT(quit()), Qt::QueuedConnection);

The error:

/home/fcarney/git/xm3-controller/controller-gui/xmui.cpp:97: error: no matching member function for call to 'connect'

Like I said it compiles but throws an error up. We have the exact same code for the same object in another project that does not throw this error. So I can only assume there is something wonky in this project. I don't see anything significantly different between the different projects that use this code.

I am also seeing errors where it throws an error for missing parameters on functions that have default args. It will say too few args, but all the non-optional args have been supplied. And it does compile and work fine. It is just annoying that qt creator is showing errors in the source code and the error/warning log. I don't want to get used to seeing errors in my log. Then it will be harder to find real issues.

[kshegunov]

@fcarney said in What could cause clang to error, but gcc compiles it anyway?:

Like I said it compiles but throws an error up.

What does? The compiler, the code model, clazy or at runtime?

(To me it looks like the compiler)

[fcarney]

@kshegunov said in What could cause clang to error, but gcc compiles it anyway?:

What does? The compiler, the code model, clazy or at runtime?

It shows up with all the warnings. It also paints a redline under the line of code with the same message. But gcc (for arm) still creates the executable and it runs. The same code compiles with gcc (for x86) in a different project, but does not show or report errors.

It looks like a compiler error to me. So I don't see how it can create the executable.

[fcarney]

Is there a setting for a project to show Semantic Issues as errors? I just noticed it says Semantic Issue. I will try and hunt that down.

[mchinand]

@fcarney said in What could cause clang to error, but gcc compiles it anyway?:

QObject::connect(this, SIGNAL(doQuit()), qApp, SLOT(quit()), Qt::QueuedConnection);

Do you still get the warning if you use the (not so) new connect syntax?

connect(this, &YourObjectType::doQuit, qApp, &QApplication::quit, Qt::QueuedConnection);

It probably doesn't matter, but do you still get the warning if you don't include the connection-type parameter, Qt::QueuedConnection?

[fcarney]

    QObject::connect(this, SIGNAL(doQuit()), qApp, SLOT(quit()), Qt::QueuedConnection);

    QObject::connect(WebSocketClient::instance(), SIGNAL(connected()),
                     this, SLOT(webSct_connected()));
    QObject::connect(WebSocketClient::instance(), SIGNAL(disconnected()),
                     this, SLOT(webSct_disconnected()));
    QObject::connect(WebSocketClient::instance(), SIGNAL(ping_status(int, int)),
                     this, SLOT(webSct_ping_status(int, int)));

    QObject::connect(this, &XMUI::doQuit, qApp, &QApplication::quit, Qt::QueuedConnection);

The first lines have semantic errors. The last line no errors. But this does not explain why. I have other weird errors that don't affect the compile. Like telling me I don't have enough args for a function when the function has default args. I am thinking this is something to do with my arm compiler. The desktop gcc compiler isn't doing this. So I have to assume the arm compiler is configured weird. I will try to see where that takes me.

Just to give more info. The other connects are saying that they cannot convert XMUI (QObject derived) to const QObject*. That is the "this" parameter.

/home/fcarney/git/xmc-tools/cl-sysroot/cortexa15hf-vfp-neon-linux-gnueabi/usr/local/Qt-5.15.1/include/QtCore/qobject.h:222: candidate function not viable: no known conversion from 'XMUI *' to 'const QObject *' for 1st argument

However, the last connect should be saying exactly the same thing.

[fcarney]

I built the same project with the desktop gcc (x86) and the errors are gone. There is something weird about the arm gcc.

[mchinand]

What versions of Qt and QtCreator are you using?

[kshegunov]

@fcarney said in What could cause clang to error, but gcc compiles it anyway?:

The first lines have semantic errors. The last line no errors. But this does not explain why. I have other weird errors that don't affect the compile. Like telling me I don't have enough args for a function when the function has default args. I am thinking this is something to do with my arm compiler. The desktop gcc compiler isn't doing this. So I have to assume the arm compiler is configured weird. I will try to see where that takes me.

This has nothing to do with the actual compiler, it's the code model that generates them (hence my original question). Personally I hate the machine telling me what kind of garbage code I write, so I use the good ol' stupid code model that doesn't generate no such diagnostics. :D

[mchinand]

Do have the Q_OBJECT macro in your XMUI header?

[fcarney]

@mchinand It doesn't matter if I have Q_OBJECT in there (it does). Compiling with a different Kit made all the errors disappear. I have something wrong with my Kit or Arm compiler installation. The gcc kit for the OS doesn't cause this. The Arm kit does. Strangely, a guy I work with has same exact kit and doesn't see these errors when compiling to Arm.

@kshegunov
I will have to research what "code model" means and why it might affect the error messages. Thanks for the tip.

[fcarney]

Now I tested with minimal project same kit (Arm):

#include <QCoreApplication>
#include <QObject>

class TestObj: public QObject
{
    Q_OBJECT

public:
    TestObj(QObject* parent=nullptr){

    }

signals:
    void doexit(int code);
};

int main(int argc, char *argv[])
{
    QCoreApplication a(argc, argv);

    TestObj testobj;

    QObject::connect(&testobj, &TestObj::doexit, qApp, &QCoreApplication::exit);
    QObject::connect(&testobj, SIGNAL(doexit()), qApp, SLOT(exit()));

    return a.exec();
}

#include "main.moc"

No errors at all. So that leads me to believe something in the original arm project is causing this with the arm kit.

I tried resetting the code model and it seemed to have no effect on the errors.

[fcarney]

I found an error in my kit. The qmake was pointing to a qmake in another directory than the compiler directories. The kits were identical. However, this did not make the errors go away. Now, if I compile it never produces those errors. But if I run qmake it does a lot of thinking and then puts those errors in the log window. The errors around the actual code never go away. I am going to try updating qt creator next. Really baffled as to what I am even looking at.

[kshegunov]

@fcarney said in What could cause clang to error, but gcc compiles it anyway?:

Really baffled as to what I am even looking at.

Open the documentation for Creator and check how to disable the clang code model (I think it was disabling the plugin somewhere in the menus). Report back whether the 'errors' went away.

[fcarney]

@kshegunov said in What could cause clang to error, but gcc compiles it anyway?:

Report back whether the 'errors' went away.

The errors are no more. qmake and rebuild.

[kshegunov]

If you still want to use it, tweak the flags to suit your need after re-enabling:
https://doc.qt.io/qtcreator/creator-clang-codemodel.html

[fcarney]

How can clang produce errors for one kit on the project, but not produce errors for the same project on another kit? Same exact code. Same exact clang settings. This sounds like to me some temporary file is not getting cleared.

[kshegunov]

Dunno. It shouldn't, but I don't use it because it is fat.

[fcarney]

I am gonna say this is solved. I am tired of wasting time on this. Thanks for your help everyone.
If I figure this out later I will post something here. I am going to be reevaluating my arm compiler installation later. Maybe that will find something.