It is a fast-track to recursive locks and deadlocks. Like https://bugs.kde.org/show_bug.cgi?id=410751, it should not try to be recursive and could in the first time be using simple heuristics, such as : - is there a std::lock_guard object in the scope where the signal is emitted or a parent one - in a second time, try to handle more complicated cases such as explicit mutex.lock(), std::unique_lock or QMutexLocker. This likely needs a proper control flow graph analysis to be correct, does clang has something for that ?