parser/semantic: Support eval string parsing

[aapoalas]

Eval strings are parsed similarly to scripts but have a few edge cases that (arguably) require explicit support on the semantic analysis side. These originate from the specification's PerformEval and EvalDeclarationInstantiation abstract operations.

These are

1. Support inFunction setting of PerformEval (see Step 6, 10.b.ii., and 11.e.)
2. Support inMethod setting of PerformEval (see Step 7, 10.b.iii., and 11.f.)
3. Support inDerivedConstructor setting of PerformEval (see Step 8, 10.b.iv., and 11.g.)
4. Support inClassFieldInitializer setting of PerformEval (see Step 9, 10.b.vi., and 11.h.)
5. Support privateIdentifiers setting of EvalDeclarationInstantiation (see Steps 4 through 7)
6. Support strict parsing of scripts (see PerformEval strictCaller parameter)

Settings 1-5 are needed for full ECMAScript eval parsing support and cannot reasonably be implemented by an embedder, as supporting them would mean implementing a custom semantic analysis step from scratch. (It would be possible to perform normal semantic analysis on eval and check that any errors are permissible according to the 5 extra settings, and if they are then ignore the semantic analysis errors. This assumes that the semantic analysis will not short-circuit, though.)

Setting 6 is needed for parsing of eval scripts in strict contexts while ensuring that module declarations (imports, exports) are not allowed in. This is easy to check manually by an embedder as well, as it only requires filtering over the body statements directly.

[overlookmotel]

A less formal description of the same options that @aapoalas gave on Discord:

• inFunction: this allows using new.target in the text.,
• inMethod: this implies inFunction and allows using super.prop in the text.,
• inDerivedConstructor: this implies inMethod and allows using super() in the text.,
• inClassFieldInitializer: this implies inMethod and disallows using arguments in the text.,
• privateNames: some way to prepare a list of #private names that are allowed to appear in the text.,
• isStrict: this existed previously, IIRC, and is just a way of parsing text as strict without it being ScriptType::Module.

[overlookmotel]

I suggest we expose these options in a way that's close to Babel's parser options. This will be more familiar for users - we'll also want to expose these options in oxc-parser NPM package.

In Babel's scheme, each option controls whether a specific syntax is legal, rather than what context the code is in.

e.g.:

• strictMode
• allowNewTargetOutsideFunction
• allowReturnOutsideFunction
• allowSuperOutsideMethod (I think this is equivalent to inMethod not inDerivedConstructor)

But I believe we can make those options cover all the same functionality as the original list. e.g. inFunction in original list corresponds to allowNewTargetOutsideFunction and allowReturnOutsideFunction.

Note: allowReturnOutsideFunction would be false when parsing code evaluated by eval, but is useful for other purposes - e.g. return is legal at top level in CommonJS files (and we already have that option anyway).

I think implementing all of these should not be too difficult except for privateIdentifiers, which is more tricky.