v8/test/inspector/debugger/evaluate-on-call-frame-private-class-member-super-expected.txt
Joyee Cheung 4d0d31f41b [class] support out-of-scope private member access in debug-evaluate
Previously in the DevTools console, users could inspect a preview of all private class members on an instance, but if they wanted to evaluate or inspect a  specific private class member out of a long list, they had to be debugging and in a scope that has access to those private names.

This patch adds support for extraordinary access of out-of-scope private member access in debug-evaluate, specifically for Debugger.evaluateOnCallframe() (for console calls invoked during debugging) and Runtime.evaluate() (for console calls invoked when the user is not debugging). This kind of access is not otherwise allowed in normal execution, but in the DevTools console it makes sense to relax the rules a bit for a better developer experience.

To support this kind of extraordinary access, if the parsing_while_debugging or is_repl_mode flag is set, when we encounter a private name reference that's in a top-level scope or an eval scope under a top-level scope, instead of throwing immediately, we bind the reference to a dynamic lookup variable, and emit bytecode that calls to %GetPrivateName() or %SetPrivateName() in the runtime to perform lookup of the private name as well as the load/store operations accordingly.

If there are more than on private name on the receiver matching the description (for example, an object with two `#field` private names from different classes), we throw an error for the ambiguity (we can consider supporting selection among the conflicting private names later, for the initial support we just throw for simplicity).

If there are no matching private names, or if the found private class member does not support the desired operation (e.g. attempting to write to a read-only private accessor), we throw an error as well.

If there is exactly one matching private name, and the found private class member support the desired operation, we dispatch to the proper behavior in the runtime calls.

Doc: https://docs.google.com/document/d/1Va89BKHjCDs9RccDWhuZBb6LyRMAd6BXM3-p25oHd8I/edit

Bug: chromium:1381806
Change-Id: I7d1db709470246050d2e4c2a85b2292e63c01fe9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4020267
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85421}
2023-01-20 22:26:44 +00:00

0 lines
Plaintext