Ruby/Python: Clear call contexts after jump steps in type tracking

[hvitved]

Also added a new

predicate levelStep(Node pred, Node succ) { none() }

to the interface to allow for proper level steps.

[aibaars]

Looking at the JavaScript implementation of TypeTracker.append I see that none of the steps ever clear the hasCall property and vice-versa for hasReturn in TypeBackTracker.prepend. @asgerf , what do you think?

[asgerf]

None of our type-tracking steps are jump-steps. No fundamental reason not to have them, we just haven't added them.

Note we handle captured variables differently; they are not modelled as jump steps (which is too imprecise for JS code). Also, when writing a type-tracking predicate, you may choose to manually reset the calling context using t.start() (I'm working on a doc describing the importance of this in more detail). Perhaps this is why it never seemed important for JS.

[aibaars]

@asgerf Thanks for the explanation. Just wanted to be sure that there wasn't a fundamental reason why resetting the hasCall/hasReturn flags would be bad.

[hvitved]

Also, when writing a type-tracking predicate, you may choose to manually reset the calling context using t.start()

Doesn't that also clear whether or not data is stored in a property?

[aibaars]

Looks good to me.

[tausbn]

Looks reasonable. The breadth of the DCA run for Python could be a bit bigger, though. We usually opt for nightly/nightly for the queries and sources.

[yoff]

Looks like the experiment has to be re-run. I am curious to see the results since the code change looks good :-)

[hvitved]

The breadth of the DCA run for Python could be a bit bigger, though. We usually opt for nightly/nightly for the queries and sources.

I have rerun DCA. Does it look good to you?

[yoff]

DCA run looks good to me 👍