Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Scopes: support default parameter initializers #78

Closed
hbenl opened this issue Mar 11, 2024 · 5 comments
Closed

Scopes: support default parameter initializers #78

hbenl opened this issue Mar 11, 2024 · 5 comments

Comments

@hbenl
Copy link
Collaborator

hbenl commented Mar 11, 2024

From MDN:

The default parameter initializers live in their own scope, which is a parent of the scope created for the function body.

To support this we need to add some information for function scopes:

  • which of the scope's variables are parameters
  • the location range for the special scope for default parameter initializers (i.e. the location range of the function's parameter declarations)
@hbenl
Copy link
Collaborator Author

hbenl commented Mar 11, 2024

I think this could be supported with the current proposal by encoding two sibling scopes for each function: one containing only the parameters and with the location range of the parameter declarations and one containing parameters and local variables with the location range of the function's body.
Note that this is only necessary if the function declaration contains default parameter initializers and some of the initializers reference other parameters. Otherwise the initializers are effectively evaluated in the parent scope and no special scope for the initializers needs to be added to the sourcemap.

@szuend
Copy link
Collaborator

szuend commented Mar 12, 2024

I'm not sure about sibling scopes, but we could handle it similar to how JS engines do this. (See this comment):

  • The function scope starts at the opening paren of the function declaration. It contains the parameters.
  • If default initializers are used, emit a child block scope that starts at the opening brace, but contains the full function body.

@hbenl
Copy link
Collaborator Author

hbenl commented Mar 12, 2024

I'm not sure about sibling scopes, but we could handle it similar to how JS engines do this.

Right, and actually the documentation at MDN also suggests this (because it says the extra scope should be the parent of the function body's scope) and this is also more efficient (because we don't need to repeat the function parameters).

If default initializers are used, emit a child block scope that starts at the opening brace, but contains the full function body.

Actually I found that the extra scope is only created when it's absolutely necessary: when default initializers are used and one of the initializers references a variable that is redeclared in the function's body.
This is important because we need to match the scopes we get from the debugger to the GeneratedRanges described in the sourcemap in order to compute the original scopes.

@hbenl
Copy link
Collaborator Author

hbenl commented Mar 13, 2024

I found that the extra scope is only created when it's absolutely necessary: when default initializers are used and one of the initializers references a variable that is redeclared in the function's body.

I was wrong about this - it seems the extra scope is created when default initializers are used and there is a variable declaration in the body. Generally JS engines seem to omit scopes without bindings.

@hbenl
Copy link
Collaborator Author

hbenl commented Mar 13, 2024

I've added examples showing how this can be done using the current proposal.

@hbenl hbenl closed this as completed Mar 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants