Compartment names and debugging error compartment-of-origin

[kriskowal]

With compartments, the compartment that originated an error is useful information for debugging.

We could surface information about an originating compartment in stack errors, along with the source location.

As written in SES shim today, the location that appears in each stack frame comes from the optional second argument of the StaticModuleRecord(source, location?) constructor.

Threading the location this way tightly couples a static module record’s instance to a location, which may be fine. The SMR can still be separately initialized in multiple compartments, without sharing any state.

Coupling the SMR to a specific compartment would limit cache-ability and reuse.

I propose we add a name to compartment instances. This would be received from the Compartment constructor options bag and be realized as a getter on instances.

The name would be for improving the debugging experience and we could surface it in some number of ways. The most obvious would annotate error stack frames.

Error: broke
  in function break (compartment ${name}) (${location}:${line}:${col})

Alternately, the compartment name could be incorporated in the anchor of the location. This might be the only avenue that we can virtualize in SES-shim. The SES-shim could add the compartment name to the location by deferring parsing of source until it has been bound to a compartment, at some performance cost.

There are some other possible ways to thread the compartment name. SES-shim is currently experimenting with a way to add annotations to errors without changing the identity of the error or revealing the annotations to any caller that catches the error. Catching and throwing an annotated error, with the original error as a cause, could be done but would be far too invasive.