[jsdbg2] CrossCompartmentKey support for Debugger is over-complicated
Categories
(Core :: JavaScript Engine, task, P1)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox68 | --- | fixed |
People
(Reporter: jimb, Assigned: jimb)
References
Details
(Whiteboard: [debugger-mvp])
Attachments
(1 file)
Adding new references from Debugger-related objects to debuggee objects is more complicated than it should be for a number of reasons, but one is that CrossCompartmentKey's structure is needlessly complex. Now that CrossCompartmentKey::wrapper is a mozilla::Variant, the different sorts of <Debugger, referent> keys can simply be different branches of that Variant, and there should be no need for the DebuggerAndObject 'kind' field.
|
Assignee | |
Comment 1•5 years ago
|
||
This replaces the various Debugger-related member classes in
js::CrossCompartmentKey with a series of small structs that can be used directly
as alternatives in CrossCompartmentKey::WrappedType. Thus, instead of having a
two-level tag --- the Variant tag, and then for DebuggerAndObject case, a
DebuggerObjectKind value --- the Variant tag can do all the work by itself.
This also tightens up the types a bit: choosing the wrong DebuggerObjectKind
would be a silent error, but using the wrong constructor might get you a type
error (although unfortunately some of the types are not as specific as you might
hope: NativeObject instead of WasmInstanceObject, for example).
A new comment explains the rationale for giving Debugger API objects entries in
the wrapper map.
|
|
Assignee | |
Updated•5 years ago
|
|
||
Updated•5 years ago
|
|
|
||
Updated•5 years ago
|
|
||
Updated•5 years ago
|
Pushed by jblandy@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/b97c44f9234f Refactor and document Debugger support in js::CrossCompartmentKey. r=sfink
|
||
Comment 3•5 years ago
|
||
| bugherder | ||
Description
•