Conversation
… which only resulted in an assertion fail when CodeCompass was compiled in debug mode.
…ing the tests, ODB assertions are performed. See Ericsson#439.
mcserep
added
Kind: Bug ⚠️
Plugin: C++
| model::CppFunction callee = _db->query_value<model::CppFunction>( | ||
| RCppFunction callees = _db->query<model::CppFunction>( | ||
| QCppFunction::name == "multiFunction"); | ||
| EXPECT_GT(callees.size(), 0); |
There was a problem hiding this comment.
Here the multiFunction is declared 2 times and defined 1 time, so all together 3 records in CppFunction will be found.
| model::CppEnum integer = _db->query_value<model::CppEnum>( | ||
| QCppEnum::name == "Integer"); | ||
| model::CppTypedef integer = _db->query_value<model::CppTypedef>( | ||
| QCppTypedef::name == "Integer"); |
There was a problem hiding this comment.
Here Integer was not an enum, but a typedef in the parsed source code.
| _transaction([&, this] { | ||
| model::CppEnum enumeration = _db->query_value<model::CppEnum>( | ||
| _transaction([&, this] | ||
| { | ||
| RCppEnum enumerations = _db->query<model::CppEnum>( | ||
| QCppEnum::name == "Enumeration"); | ||
| EXPECT_GT(enumerations.size(), 0); |
There was a problem hiding this comment.
There are multiple records for Enumeration in the CppEnum table.
| model::CppFunction fieldFunction = _db->query_value<model::CppFunction>( | ||
| TEST_F(CppParserTest, Fields) | ||
| { | ||
| _transaction([&, this] { | ||
| model::CppVariable fieldFunction = _db->query_value<model::CppVariable>( | ||
| QCppFunction::name == "fieldFunction"); | ||
| astNodes = _db->query<model::CppAstNode>( | ||
| RCppAstNode astNodes = _db->query<model::CppAstNode>( |
There was a problem hiding this comment.
This is the case where I was uncertain about my fix. This fieldFunction is a defined like this:
struct Derived : public MyClass
{
MyClass fieldVariable;
MyClass (*fieldFunction)(const MyClass&);
// etc...
};So it is a class member field, as a function pointer. It gets parsed into the CppVariable table, not the CppFunction, but that is correct that way, right @bruntib ? It is a variable, not a function semantically.
There was a problem hiding this comment.
I checked the above code, the function pointer is considered a fieldDecl.
…mpty check can be done.
2 participants
Closes #439.
This PR fixes the strange issue that the unit tests failed when CodeCompass was compiled in Debug mode.
It turned out that these tests were really failing (for a long time actually), but when compiled Release mode, some ODB functions just fail silently and assertions are only done in Debug mode.
In most cases, the root of these issues was the
query_value()function, which returns the selected record from the database as a value. The number of resulted records must be precisely one, otherwise assertion failure is done in debug mode. In release mode no error is raised at all: when multiple results are available, the first one is returned and in case of zero results, a default constructed object is returned (or even memory garbage, I haven't checked it).As the ODB Manual states:
These misbehaviours went unnoticed in release mode, because when multiple results were available, simply the first was returned; and when no results were available, all
EQ_*assertions were inside a loop, which was executed 0 times.In this PR I have addressed these issues and fixed them. In all cases I am confident that the unit tests were incorrect and CodeCompass worked correctly. There is only a single case where I am uncertain (related to function pointers), but I will mark that case for discussion explicitly soon.
I have also modified that the CI shall build CodeCompass in Debug mode for testing in the future, to avoid any such issue like this in the future. (Docker images and tarballs are still built in Release mode of course.)