Call graph regression: Some parts are mixed up

[benjarobin]

Describe the bug
For a C project, when doxygen is generating the call graph with dot (CALL_GRAPH and CALLER_GRAPH are set to YES), the resulting html documentation contains call graph and caller graph from the wrong function, even if the root node is the correct function name. Everything looks mixed up in the call tree...

After running git bisect start origin/master tags/Release_1_8_20 I found that the regression was introduces by the commit 0252f61, the commit e9ca9dc is fine.

So the version 1.9.1 is impacted.

Expected behavior
Correct call graph / caller graph generation.

To Reproduce
test-repro.zip

Screenshot OK
(using commit e9ca9dc)

Screenshot KO
(using commit 0252f61)

Version
See bisect analyze above. Can be reproduced with latest master

[albert-github]

From your bisect I assume that the problem is still present in the current master.

• Please try to generate an example so it possible for us to reproduce the problem.

[benjarobin]

@albert-github I was able to generate a very small example (kind of dirty...). And updated the first message with it.

[albert-github]

Thanks for the example, this would otherwise be hard / impossible to check.

[albert-github]

I've able to reduce the problem a little bit further to:

void ExecState7(void)
{

}

void MGR_Process(void)
{
   ExecState7();
}

struct MGR_CmdOrder_t MGR_GetCmdOrder(void)
{
    return m_cmdOrder;
}

and a Doxyfile:

EXTRACT_ALL            = YES
QUIET                  = YES
GENERATE_LATEX         = NO
HAVE_DOT               = YES
CALL_GRAPH             = YES
CALLER_GRAPH           = YES

Looks like it depends on the return type

• when I change the return type struct MGR_CmdOrder_t to int the result is OK
• when I change the return type of MGR_Process to struct MGR_CmdOrder_t there is no call / caller graph at all

Example: example.tar.gz

[benjarobin]

The code was previously "buggy", but the bug was hidden. Even in commit e9ca9dc, the addSourceRef() function is called with the wrong line number. In my example 2 functions are put in the same location (line number).

Basically every function/variable returning a "complex type" (an enum or a struct), is not located properly (not at the right line number).

Edit 1: The function DefinitionImpl::setBodySegment(int defLine, int bls,int ble) is called with defLine wrong value, but bls and ble are rights value

[albert-github]

Well noted. I had seen it as well but didn't pay attention to it.

Some further tests show that doxygen doesn't like a struct (or class or ...?) as a return type. In scanner.l it looks like doxyen thinks that a new struct starts instead of a return type. Apparently the lower level handling changed due to the mentioned commit (as scanner.l didn't change).

[benjarobin]

This is definitively a problem inside scanner.l, but I do not know the proper fix for it...
Nonetheless, applying this fix works for my use case. In <CompoundName>{SCOPENAME} section:

                                           yyextra->current->name = yytext ;
                                           if (yyextra->clangParser && (yyextra->insideCpp || yyextra->insideObjC))
                                           {
                                             yyextra->current->id = yyextra->clangParser->lookup(yyextra->yyLineNr,yytext);
                                           }
+                                          yyextra->yyBegColNr=yyextra->yyColNr;
+                                          yyextra->yyBegLineNr=yyextra->yyLineNr;
                                           lineCount(yyscanner);
                                           if (yyextra->current->spec & Entry::Protocol)
                                           {
                                             yyextra->current->name += "-p";
                                           }

[benjarobin]

@albert-github @doxygen Any idea how to fix properly this problem?

[albert-github]

This looks like to fix the problem for this case, though I'm a bit hesitant for side effects as not the complete type is processed

The mentioned code should be added around, currently, line 5604 where the compound name MGR_GetCmdOrder is handled. The word struct has been been handled at line 1489, rule:

<FindMembers>{B}*{TYPEDEFPREFIX}"struct{" |
<FindMembers>{B}*{TYPEDEFPREFIX}"struct"/{BN}+

in the rule at line 5598 the second part of the type (MGR_CmdOrder_t) is handled and the function name (MGR_CmdOrder) is handled at 4624 with the rule:

<ClassVar>{SCOPENAME}{BNopt}/"("

it looks like th efunction addType sees to it that the type is OK though.

When we create function:

int MGR_GetCmdOrder_int(void)
{
    return 42;
}

and this type is handled around line 2173 with the rule:

<FindMembers,FindMemberName>{SCOPENAME}

here the int and MGR_GetCmdOrder_int are handled.

[benjarobin]

Any new ? Without any fixes a recent Doxygen version is not usable.

[doxygen]

@benjarobin I've just pushed a potential fix. Please verify if it works for you.

[albert-github]

I did a quick test with the original test case (see #8476 (comment)), but it looks like I'm missing the caller graphs for the different ExecState functions (compare the output of the current master version, 1.9.2 (0e3174e), with the 1.8.20 release).

[doxygen]

@albert-github Indeed, the same logic bug that was there for callgraphs was also there for calledby graphs. Should be fixed now.

[albert-github]

Looks OK now.

I also looked at the:

REFERENCED_BY_RELATION = YES
REFERENCES_RELATION    = YES

looks OK too though a bit strange, for me, is the behavior for the enum values:

so in one place there is a "References" but on the other place there is no "Referenced by ". I'm not sure what would be best, also in relation to e.g. the m_stateMachine.

[benjarobin]

@doxygen Thank you! I built doxygen from master, then test it on my "big" project, and everything looks good :-)
Also thanks to @albert-github

[doxygen]

This issue was previously marked 'fixed but not released',
which means it should be fixed in doxygen version 1.9.2.
Please verify if this is indeed the case. Reopen the
issue if you think it is not fixed and please include any additional information
that you think can be relevant (preferably in the form of a self-contained example).