Add support for “global contour”

[kriskowal]

The global contour is a scope that overshadows globalThis when evaluating “global code”. The global contour is the scope that persists variable declarations between calls to evaluate global code. Framed as a feature of compartments, we could add a “global” option to compartment.evaluate that signifies this evaluation mode and persists the global contour between calls.

compartment.evaluate("const example = 42;");
compartment.evaluate("example"); // 42
compartment.evaluate("const example = 101;"); // throws SyntaxError: Identifier 'example' has already been declared

Ideally, we could reconcile the global lexicals and global contour. However, evaluating global code should not be able to introduce variables that would overshadow globals in modules from the same compartment.

The global contour is a mutable property bag that must enforce rules for the order and behavior variable declarations.

The name “global contour” is reviled by all, but thankfully need not appear in code. Alternative suggestions are very welcome.

[Jamesernator]

So interestingly the ShadowRealm doesn't support the "global contour" based on the spec for PerformShadowRealmEval.

i.e. As specced currently this throws an error (and v8's experimental implementation confirms this):

shadowRealm.evaluate(`let x = 42`);
// throws a ReferenceError *inside* the ShadowRealm (exposed as TypeError outside)
shadowRealm.evaluate(`x`);

With the new changes to the proposal, we could plausibly add this as functionality to Evaluator. Currently Evaluator simply provides an eval function, and eval doesn't use the global contour. Perhaps we should just provide a evaluator.evaluateScript which uses script semantics rather than eval semantics.