Lack of cohesion metrics

[dbukki]

Introduction of Lack of Cohesion (LoC) metrics in the metrics plugin.

• New metrics calculation function: CppMetricsParser::lackOfCohesion
• New metrics types: LACK_OF_COHESION and LACK_OF_COHESION_HS
• Helper function for detecting if the given file path of an AST node is internal to the parsed project: CppMetricsParser::isInInputPath
• New helper database views in model/cppcohesionmetrics.h
• Verbose debug utilities for the real-time monitoring of the parsed types.
• Refactor: Removed a duplicate code block from ClangASTVisitor::getFileLoc.

Fixes #681.

[intjftw]

Something I noticed running the plugin in debug mode: it seems that one AST node is calculated multiple times:

2023-12-11 11:41:59 [DEBUG] 498/527 tinyxml2::MemPoolT::Item               0       0
2023-12-11 11:41:59 [DEBUG] 499/527 tinyxml2::MemPoolT::Block              0       0
2023-12-11 11:41:59 [DEBUG] 500/527 tinyxml2::MemPoolT                 0.625  0.6818
2023-12-11 11:41:59 [DEBUG] 501/527 tinyxml2::MemPoolT                0.7083  0.7727
2023-12-11 11:41:59 [DEBUG] 502/527 tinyxml2::MemPoolT                0.7083  0.7727
2023-12-11 11:41:59 [DEBUG] 503/527 tinyxml2::MemPoolT                0.7083  0.7727
2023-12-11 11:41:59 [DEBUG] 504/527 tinyxml2::MemPoolT                0.7083  0.7727

@dbukki is this an error or just something with the debug log?

[dbukki]

Something I noticed running the plugin in debug mode: it seems that one AST node is calculated multiple times: ... @dbukki is this an error or just something with the debug log?

I am currently investigating this strange phenomenon too. If the same type only ever appeared in the output with the same metrics, I would be tempted to say that this is just a printing error. But for some reason, the same type can sometimes appear with different metrics, as is the case with tinyxml2::MemPoolT in your example.

My initial guess is that these are actually different instantiations of the same templated type, and some of them are specializations that have a different number of fields and methods. If this is indeed the case, then the fault is to be found in our already existing type extraction logic in the parser: perhaps the fully qualified type name does not yet contain the template arguments?

It could also be that types defined in a header and included by multiple compilation units each have their own copy of this type in the database.

And then it's also possible that both of the above factors play a role in this output. I have yet to figure out a full diagnosis.