Preventing "Run to" debugger command from raising update events, in order to prevent unnecessary (and broken) updates #642
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #607
In the debugger, "run to" from the debugger action model is doing steps on the debug session, which raise an update for each step.
However, to update the variable list in the inspector, the debugger uses the
previousASTScope
from the debugger action model, which isn't updated after each step when performing "run to". This could lead to duplicated temp variables when using "run to" to execute an inlined loop (see #607).One simple solution is to prevent the debugger from updating after each step performed by the command, making only one big update after all steps instead.
This is cohesive with what the command should do because if we perform "run to" instead of steps, this is because we don't care of the intermediary updates.
This also makes the "run to" command A LOT faster.
The fix is for P12 but another similar fix should be done for P11 to fix #607 on P11