1904965 - Expose scope location information as part of the Frame Environment for use devtools

Status: NEW

(Core :: JavaScript Engine, enhancement, P3)

Description

[Hubert Boma Manilla (:bomsy)]

It would be helpful to get some scope location information (startLocation and endLocation) if possible as part of the lexical environment. This is exposed for chrome like this https://chromedevtools.github.io/devtools-protocol/tot/Debugger/#type-Scope

Some benefits

• We currently do parsing of the source on the frontend to augment location information, avoiding that will help with performance.
• This would also help to easily match scopes provided by the sourcemaps with those from the runtime.

Comment 1

[Hubert Boma Manilla (:bomsy)]

Attachment: WIP: Bug 1904965 - Experiment to add scope location information to the environment actor

This is a rough (hacky) patch to see if this was possible.
It's also limited as we can only get information for function scopes

Comment 2

[Hubert Boma Manilla (:bomsy)]

Attachment: WIP: Bug 1904965 - Experiment to add scope location information to the environment actor

This is a rough (hacky) patch to see if this was possible.
It's also limited as we can only get information for function scopes

Comment 3

[Bryan Thrall [:bthrall]]

:bomsy, :arai, and I met on September 24 to discuss the goals of this bug.

The primary goal is to get rid of the parser worker because it is slow. Dev Tools needs to map scope information between bytecode and transpiled code. Some original scopes disappear when the code is bundled. There is also a spec proposal around this feature.

Dev Tools also wants to support other developer tools who could be using the location information (such as VS Code when it attaches to Firefox).

SpiderMonkey discards most of the needed info after parsing right now, and keeping it would increase memory footprint.

It seems feasible to provide location info via Reflect.parse. It is kept up to date with new features, since we use it for automated testing. It should resolve the performance issue, and it is easier to add missing information than tracking new information in the SpiderMonkey frontend.

If Reflect.parse doesn't work out, another option is to move parser worker to C++.

The current plan is to try using Reflect.parse.