Created attachment 104331 [details] Diff to tests/incorrect-emit/main.cpp to reproduce the bug In Okteta I get some wrong "warning: Missing emit keyword on signal call" on calls of some methods defined separately as inline methods right after the class declaration in the header. I could reduce the problem to the code attached as patch, as a new test case for tests/incorrect-emit. Seems that somehow the code location comparison in AccessSpecifierManager::qtAccessSpecifierType(...) does not work as intended, but I am too tired to research this more tonight, so just dumping the current state and hoping for the expert to quickly find the mistake :)
Git commit 9315e636246a9bd365b3d22f66fbebefa5757e0e by Sergio Martins. Committed on 04/03/2017 at 01:36. Pushed by smartins into branch '1.1'. incorrect-emit: Add failing unit-test for bug 377134 A +20 -0 tests/incorrect-emit/bug377134.cpp [License: UNKNOWN] * A +0 -0 tests/incorrect-emit/bug377134.cpp.expected M +4 -0 tests/incorrect-emit/config.json The files marked with a * at the end have a non valid license. Please read: http://techbase.kde.org/Policies/Licensing_Policy and use the headers which are listed at that page. https://commits.kde.org/clazy/9315e636246a9bd365b3d22f66fbebefa5757e0e
Git commit 53c68bc6888f18409f8e803fb5b9c59f9b1d96c9 by Sergio Martins. Committed on 04/03/2017 at 12:32. Pushed by smartins into branch '1.1'. incorrect-emit: Fix two false positives When we're comparing a method's source location to check if it's affected by Q_SIGNAL we must use the first declaration of that method, and not other declarations which can also be a a definition, and live outside of the class Related: bug 377140 M +4 -0 src/AccessSpecifierManager.cpp M +2 -4 tests/incorrect-emit/config.json https://commits.kde.org/clazy/53c68bc6888f18409f8e803fb5b9c59f9b1d96c9
please test! should work now
Thanks for the quick fix, Sergio! Can confirm that this fixes both this bug and 377140 for what I have seen them with Okteta builds. ((Darn, and I could have taken some pride here, as I was pretty close to fix this myself then, as I was searching for a method like getCanonicalDecl, but gave up as the llvm lingo did not match my c++ one and then also was already mentally in bed :) ))