Bug 410753

Summary: [check proposal] not holding mutex locks when emitting signals
Product: [Developer tools] clazy Reporter: Jean-Michaël Celerier <jeanmichael.celerier>
Component: generalAssignee: Unassigned bugs <unassigned-bugs-null>
Status: REPORTED ---    
Severity: wishlist CC: smartins
Priority: NOR    
Version First Reported In: unspecified   
Target Milestone: ---   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Jean-Michaël Celerier 2019-08-09 08:41:10 UTC 
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 ?