Skip to content

Refactor the interpreter to use Completion Record types #1540

@jedel1043

Description

@jedel1043

Right now when we're interpreting the AST we utilize JsResult as a wrapper for any error that originates on execution. This has its advantages; we can propagate type errors and throw errors with ? and return any value generated from a native function with ease. However, #672 showed us that having no distinction between a value returned from a native function and a value returned from AST interpretation is suboptimal.

The spec solves this problem with Completion Records, which are a way to separate values generated from native functions and values generated from the execution of Javascript code.
This technique also allows us to eliminate InterpreterState from the Context, essentially removing state that we needed to maintain by hand, like in:

context
.executor()
.set_current_state(InterpreterState::Return);
result

or

context
.executor()
.set_current_state(InterpreterState::Executing);

To implement CompletionRecords we would need to make a big refactor to the AST. Here's a non-exhaustive list in an arbitrary order of the required tasks:

  • Implement a CompletionRecord struct type with its associated methods from the spec
  • Make the associated function run from the Executable trait return a JsResult<CompletionRecord>.
  • Extensively check the spec to obtain the CompletionRecord of every AST node evaluation.
  • Eliminate InterpreterState from the Context type. (We can reuse the type as the [[Type]] field of a CompletionRecord)
  • Solve any bugs originated from the refactor.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions