I don't think this should be a jump step, it should be local.

Please correct me if I'm wrong, but as I understand it, a "jump" step is one that resets the calling context (allowing flow out of a different caller than where it came in). Any reason to allow that here?

I just (ab)used the jumpStep predicate because that has a LevelStep summary in smallstepNoCall. Perhaps it would be better to introduce a new predicate (localStep ?) in the shared TypeTracking library.

I agree that is should be part of simpleLocalFlowStep above instead.

Actually, it should perhaps be part of localFlowStepTypeTracker instead, since then it will work recursively (i.e., a method that returns one of its arguments via a call to another method that also does). This means such summarized steps will also be included in LocalSourceNode::flowsTo, which I guess we want?

Note that if we do this, we need to add a new disjunct to isLocalSourceNode which includes all nodes that correspond to a ExprNodes::CallCfgNode.

@hvitved I added the new step to simpleLocalFlowStep. Somehow this changes the expected output back to the previous version. Not sure if that is desirable or not. I am not sure if/how this can be added to localFlowStepTypeTracker instead. I ran into some non-monotonic recursion errors.

OK, I have given this some more thought, and I now understand why @aibaars used jumpStep, namely because it uses LevelStep. So unless we change the interface to the shared type tracking library, I think that is the best we can do for now. I will revert my changes and go back to using jumpStep.

With #8317 we should change it to using levelStep instead.

@hvitved Shall we close this pull request, or rebase it onto your work in #8317 ?

Let's rebase once that PR is merged.

@aibaars : That PR has now been merged, so let's rebase this PR and use the newly introduced levelStep.

I agree that is should be part of simpleLocalFlowStep above instead.

Actually, it should perhaps be part of localFlowStepTypeTracker instead, since then it will work recursively (i.e., a method that returns one of its arguments via a call to another method that also does). This means such summarized steps will also be included in LocalSourceNode::flowsTo, which I guess we want?

Note that if we do this, we need to add a new disjunct to isLocalSourceNode which includes all nodes that correspond to a ExprNodes::CallCfgNode.