Created attachment 104332 [details]
Diff to tests/incorrect-emit/main.cpp to reproduce the bug

In Okteta I get some wrong "warning: Emit keyword being used with non-signal X::y" on emitting calls of some signals in inline methods of subclasses of the class with the signal.

It seems that happens when the method->getLocStart() in AccessSpecifierManager::qtAccessSpecifierType(...) does not point to the declaration of the signal method, but instead the definition (in the moc file). This happens e.g. on compiling automoc-generated bundle files, when the moc.cpp file for the class with the signal is included before the moc cpp files of the subclasses, whose inline methods (thus in the header) emit the signals:

OktetaKastenGui_automoc.cpp has e.g. the lines
#include "OktetaKastenGui_automoc.dir/moc_abstractbytear_XBUWMXYENN5IHJ.cpp"
#include "OktetaKastenGui_automoc.dir/moc_bytearraybase3_YVTH2B5RNQKBMM.cpp"

where the first line is the moc file for the class with the signal, and has
void Kasten::AbstractByteArrayStreamEncoder::settingsChanged()
{
    QMetaObject::activate(this, &staticMetaObject, 0, Q_NULLPTR);
}
Then the second pulls in the header of the subclass
#include "some/long/relative/path/bytearraybase32streamencoder.h"

That header has the inline definition of a method which emits settingsChanged():
inline void ByteArrayBase32StreamEncoder::setSettings( const Base32StreamEncoderSettings& settings )
{
    mSettings = settings;
    emit settingsChanged();
}

Which then gets the warning:
Emit keyword being used with non-signal Kasten::AbstractByteArrayStreamEncoder::settingsChanged [-Wclazy-incorrect-emit]

The reason for this misbehaviour can be seen by the output of
methodLoc.printToString(m_ci.getSourceManager())
in AccessSpecifierManager::qtAccessSpecifierType(...):
.../kasten/gui/OktetaKastenGui_automoc.dir/moc_abstractbytear_XBUWMXYENN5IHJ.cpp:124:1
so this now is not the signal method declaration, but the definition. Which screws the assumption in the method.

No clue about clang, also only typing this during sleep-interruption ;) thus just this report.

I could reduce the problem to the code attached as patch, as a new test case for tests/incorrect-emit. Not sure how much 377134 is related to this bug or if it only screws the bug simulation a little.