Ruby/Python: Clear call contexts after jump steps in type tracking #8317
Conversation
hvitved
added
Python
Ruby
no-change-note-required
| @@ -49,6 +50,9 @@ private module Cached { | |||
| step = LoadStep(content) and result = MkTypeTracker(hasCall, "") | |||
| or | |||
| exists(string p | step = StoreStep(p) and content = "" and result = MkTypeTracker(hasCall, p)) | |||
| or | |||
| step = JumpStep() and | |||
| result = MkTypeTracker(false, content) | |||
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
@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.
There was a problem hiding this comment.
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?
|
Looks like the experiment has to be re-run. I am curious to see the results since the code change looks good :-) |
I have rerun DCA. Does it look good to you? |
|
DCA run looks good to me 👍 |
Also added a new
to the interface to allow for proper level steps.