Execution order of the static analyzers - #5049
Conversation
45dd085 to
ccef6ac
Compare
| enabled_analyzers = [] | ||
| failed_analyzers = set() | ||
|
|
||
| for analyzer_name in analyzers: |
There was a problem hiding this comment.
If I see correctly, the analyzers variable comes from the --enable command line arguments and not from the supported_analyzers. This way the user determines the execution order with this flag.
Nevertheless, I wouldn't think, this is the right place of implementing this feature. The purpose of this check_supported_analyzers() is really performing some check and not ordering the analyzers. I think, an explicit sorting should go to perform_analysis() function in analyzer.py based on supported_analyzers so it is explicitly visible that sorting analyzers is an intentional feature. Also, we could write a comment above supported_analyzers that says something like "please, don't change the order of this list, because analysis execution is intended to happen in this order".
There was a problem hiding this comment.
Good point! Moved the ordering logic into perform_analysis() where it's explicit. The analyzers are now sorted based on the key order of supported_analyzers.
ccef6ac to
85342f0
Compare
2 participants
The order in which analyzers (clangsa, clang-tidy, etc.) were scheduled for execution was non-deterministic because check_supported_analyzers() used a set to collect enabled analyzers. This meant that on some runs clang-tidy tasks would be dispatched before clangsa tasks.
This change replaces the set with a list, preserving the iteration order from the supported_analyzers dict. This guarantees clangsa actions are always dispatched to the worker pool first, followed by clang-tidy, cppcheck, etc.
For users with long-running clangsa analyses (e.g. 90+ minutes per file), this ensures those heavy tasks start immediately on available cores, reducing total wall-clock time.
Fixes #4362