Yep, it's not standard C++ what you see in old-style signal/slot connects, thus Clang chokes on that.

Note:
- Highlighting works fine for new-style connects
- Does not work for old-style connects

This needs custom-handling in KDevelop, which we didn't implement yet.

Arguably, people move to new-style connects, so this is less of an issue by now...

I suppose you mean C++11 - only one standard supported currently in KDevelop.
In project configuration C/C++parser -> Predefined profile inside combo there is 7 standards. Do you plan to handle all of them?
In this moment I can't select different one than "C++11".

My example came from Qt4 project, so this is standard from Qt4. The same is saying Qt4 documentation in cases of use. Example from documentation:
 QLabel *label = new QLabel;
 QScrollBar *scrollBar = new QScrollBar;
 QObject::connect(scrollBar, SIGNAL(valueChanged(int)),
                  label,  SLOT(setNum(int)));

People who are coding in Qt5 can/must move to new style of connect/disconnect macros.
I have Qt4 project and the most likely in the future I want to move with it to Qt5, but not now and for sure not in this year. Still, I think, there are many developing projects using Qt4.
If you saying "this is less of an issue by now", so I have to wait (with hope) till will be fixed someday in the future :/. Now I have KDevelop 4.7.x
Yes. I know the reason. You (KDevelop team) have not much manpower.

Yep, we are aware of this situation and I completely agree with you - we _have_ to keep support for Qt 4 and the "old" signal/slot connect syntax.

It should actually be possible, I think, with a bit of macro hackery.

Git commit 0474b1a0063c32abc9d89143bc2343db4d21b7f7 by Milian Wolff.
Committed on 24/01/2016 at 18:28.
Pushed by mwolff into branch '5.0'.

Mark Qt signals and slots as such in the DUChain.

This is a first step towards bringing back the old KDevelop 4 level
of support for Qt. There is a lot of work left to be done though.

This patch so far only marks class function declarations that are
Qt slots or signals as such. The main idea here is taken from the
Qt Creator clang code model, so credit where credit is due: Good
job!

When a TU is parsed that contains a system include path that ends with
/QtCore we prepend the include paths to our "wrappedQtHeaders" folder.
This so far only contains "QtCore/qobjectdefs.h" which includes the
real "qobjectdefs.h" via `#include_next`. Then we redefine the MOC
macros for signals and slots to inject __attribute__((annotate())
tokens with qt_slot/qt_signal contents where appropriate. This can
then be looked up when traversing the AST via CXCursor_AnnotateAttr
cursors.

M  +6    -0    languages/clang/duchain/CMakeLists.txt
M  +24   -0    languages/clang/duchain/builder.cpp
M  +24   -2    languages/clang/duchain/parsesession.cpp
A  +57   -0    languages/clang/duchain/wrappedQtHeaders/QtCore/qobjectdefs.h     [License: GPL (v3)]
M  +62   -0    languages/clang/tests/test_duchain.cpp
M  +1    -0    languages/clang/tests/test_duchain.h

http://commits.kde.org/kdevelop/0474b1a0063c32abc9d89143bc2343db4d21b7f7

Git commit 065d303e87723f6fea9e4cd230a0e5c94042450e by Milian Wolff.
Committed on 24/01/2016 at 18:44.
Pushed by mwolff into branch '5.0'.

Do not offer to implement Qt signals.

M  +1    -1    languages/clang/codecompletion/completionhelper.cpp
M  +3    -23   languages/clang/duchain/builder.cpp
M  +22   -0    languages/clang/util/clangutils.cpp
M  +10   -0    languages/clang/util/clangutils.h

http://commits.kde.org/kdevelop/065d303e87723f6fea9e4cd230a0e5c94042450e

To report uses inside SIGNAL()/SLOT() macros, we have multiple options:

- rewrite uses of qFlagLocation based on the string literal argument it gets passed:
    CallExpr (103) | type: "const char *" (101) | display: "qFlagLocation" | loc: test.cpp@[(17,5),(17,23)] | isUse
      UnexposedExpr (100) | type: "const char *(*)(const char *)" (101) | display: "qFlagLocation" | loc: test.cpp@[(17,5),(17,23)] 
        DeclRefExpr (101) | type: "const char *(const char *)" (111) | display: "qFlagLocation" | loc: test.cpp@[(17,5),(17,23)] | isUse
      UnexposedExpr (100) | type: "const char *" (101) | loc: test.cpp@[(17,5),(17,23)] 
        StringLiteral (109) | type: "const char [24]" (112) | canonical type: "char const[24]" (112) | display: ""2mySignal()\000test.cpp:17"" | loc: test.cpp@[(17,5),(17,23)] 

- rewrite uses of the macros themselves, assuming we get access to its argument

- we could also overwrite the macros as needed using our new qobjectdefs.h shim.

The oldcpp plugin has some logic for finding the corresponding signal/slot from a normalized signature afaik, which we can revive for that purpose.

Once that is done we can look at the nice-to-have things:

For Q_PROPERTY we can leverage the static assert trick that Olivier found and documented here: https://woboq.com/blog/moc-with-clang.html
This would then be followed by a parsing of the string literal and extracting the getter, setter and notify signal and reporting uses for them.

For Q_PRIVATE_SLOT we could use a custom macro with a special marker attribute.

Seems this currently work. I tested this with syntax of singal / connect provided in Qt5.