Decouple Context from ByteCompiler

[HalidOdat]

This PR removes the &mut Context field from the ByteCompiler making it possible to put the bytecompiler in its own crate (there is still work to move JsString and other parts to their own crate so they can be used it both crates, but this is a step in the right direction).

This also fixes the some failing eval test262 tests.
EDIT: Oops, Tested with an older version of test262 result, so no bonus passing tests 😅

TODO:

• Clean-up and documentation of spec deviation

[github-actions]

Test262 conformance changes

Test result	main count	PR count	difference
Total	50,731	50,731	0
Passed	42,973	42,973	0
Ignored	1,395	1,395	0
Failed	6,363	6,363	0
Panics	18	18	0
Conformance	84.71%	84.71%	0.00%

[nekevss]

A couple things I missed.

Sort of general question: did you happen to benchmark this? Was sort of curious what impact the new global opcodes have.

Also, would it make sense for the global opcodes to occur in the instantiation functions like in the spec vs. opcodes?

[nekevss]

Thought: Potentially move these out of bytecompiler to script

Now that these are separated, is there any need for these functions to still live in this module (especially if the bytecompiler is eventually moved to it's own crate).

[HalidOdat]

Yup, we can put them in separate locations, the only reason I left them there was because the context and non-context variants are close to each other.

[HalidOdat]

Sort of general question: did you happen to benchmark this? Was sort of curious what impact the new global opcodes have.

The opcodes execute only once in the execution of a script, when I checked for rust benchmarks as well as quickjs benchmarks I didn't notice any regressions.

Also, would it make sense for the global opcodes to occur in the instantiation functions like in the spec vs. opcodes?

The problem with this is that some functions need to already be compiled and instantiated to be put into the global object, that's why it's delayed when we execute the bytecode so we can separate them. It might be possible by having some post _context functions calls as well as pre calls (as we do now).

The main benefit to having opcodes for them (besides the complexity reduction) is reproducibility of CodeBlock execution, this will be needed when we implement CodeBlock serialization to disk and back, we wont need to store the AST (there is still work to be done for this, ideally all of the _context function should be converted to bytecode, but this is a separate issue, not related to splitting the bytecompiler into its own crate).

[raskad]

Nice work. :)

[nekevss]

Given the above, I'm fine with merging this. Nice work on this! 😄