-
Notifications
You must be signed in to change notification settings - Fork 3k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
HHVM Debugger: Maintain stable variableReference IDs for the same obj…
…ects per-request Summary: Variables returned to the client in a VariablesResponse that are of complex types (objects, arrays, vec's, maps, etc) are assigned a variableReference identifier as required by the debug adapter protocol, so that the client can request the object's children in a subsequent command. Currently, the debugger is returning a new, unique ID for each initial variablesRequest after the target thread steps. This requires less bookkeeping on the back-end, and also protects against certain races like a setVariable command that is processed asynchronously after a target request thread resumes or steps (in which case it may be impossible or unsafe to set the value of the object). While the debug adapter protocol doesn't specify any restrictions on the variableReferene being reused vs unique, in practice VS Code appears to be using this to remember which nodes in the Variables scope tree are expanded or collapsed. The current behavior results in nodes collapsing after each step, which is frustrating to a user trying to watch the values of a child member while stepping through a code block. This was surfaced as issue: slackhq/vscode-hack#32 **This does not repro on Nuclide, which uses a path to the variable instead of the variable's internal ID to maintain expanded/collapsed state between steps.** This diff modifies the back-end to re-use variablesReferences for the same object within the same request, even if the request has stepped. This only applies to complex objects. Simple values (ints, strings, etc) don't have children, and therefore can't be expanded in the UI, so this doesn't matter. The identitiy of the object is determined by the object's actual in-memory address within HHVM, which assures uniqueness. A new client preferences option was added to the launch+attach command, disableUniqueVarRef, that disables this new behavior if specified. Reviewed By: velocityboy Differential Revision: D10274418 fbshipit-source-id: 0e5d5d0fd2fe2d44c791e85aaa0c9ea33522bbb7
- Loading branch information
1 parent
5c26d27
commit 83e2be2
Showing
6 changed files
with
116 additions
and
37 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.