Is this a known bug in moc?

[piotr.dobrogost]

I wanted to use the following signal

void QNetworkAccessManager::sslErrors (QNetworkReply * reply, const QList<QSslError> & errors ) [signal]

so I wrote this

QObject::connect(nam, SIGNAL(sslErrors(QNetworkReply*, QList<QSslError> const &)), this, SLOT(ssl(QNetworkReply *)));

and got an error about non-existen signal... Changing above to

QObject::connect(nam, SIGNAL(sslErrors(QNetworkReply*, const QList<QSslError> &)), this, SLOT(ssl(QNetworkReply *)));

solved the problem.

Is this a known bug in moc?

[ChrisW67]

Seems like you are describing correct operation. The slot parameter signature of your working option matches the definition of the signal i.e. the QMetaObject::normalizedSignature method returns that string exactly for the slot. The other doesn't.

[wysota]

If at all then not in moc but rather in QMetaObject::normalizedSignature(). But in general this should work, maybe the problem is somewhere else?

If it's known - that I do not know but you can check that yourself using the task-tracker.

[piotr.dobrogost]

Could you clarify, please?
Do you agree this is a bug or not?

[piotr.dobrogost]

If at all then not in moc but rather in QMetaObject::normalizedSignature().

Yep.


But in general this should work, maybe the problem is somewhere else?

It should work but it doesn't work. We have two identical (from C++ pov) signatures and one is treated differently by moc than the other. Isn't this clearly a bug?
What do you mean by maybe the problem is somewhere else?


If it's known - that I do not know but you can check that yourself using the task-tracker.

There were a couple of tickets about moc and signatures, all fixed.
I created a ticket for this.

[rexi]

Seems like you are describing correct operation. The slot parameter signature of your working option matches the definition of the signal i.e. the QMetaObject::normalizedSignature method returns that string exactly for the slot. The other doesn't.

But in the end, the meaning of both signatures is equivalent. I guess that is what Piotr wanted to point out. I'd say this is a bug, then.

[wysota]

It should work but it doesn't work. We have two identical (from C++ pov) signatures and one is treated differently by moc than the other. Isn't this clearly a bug?
The documentation gives an example almost identical to yours (it uses a pointer and not a reference), so I assume they checked that it works. You might check if changing the reference to a pointer makes it work.


What do you mean by maybe the problem is somewhere else?
In some other part of the code or because of some non-printable character. I'm just guessing, it's simply hard to believe the example from the docs doesn't work.


There were a couple of tickets about moc and signatures, all fixed.

But moc has nothing to do with this...

[piotr.dobrogost]

I'm just guessing, it's simply hard to believe the example from the docs doesn't work.

What I presented in my op is not the example from the docs but my code. I only copied and pasted signal declaration directly from the docs to show it's part of qt and not mine.


But moc has nothing to do with this...

In the most narrow sense moc is only a compiler but in a broader sense it's name of whole concept, system (name it as you like) which this compiler is only one part of. When using moc in the second sense QMetaObject::normalizedSignature() is vital part of moc.
On the other hand, if we agree moc is only a compiler than how should we call the whole system of meta information in qt?