Stack traces for contextual/layout errors

Description

Currently, errors that happen during evaluation show a stack trace, but errors that happen in user code during rendering (using functions such as cite or locate) do not.

Improving this would require storing a stack trace for each content node that can fail to render.

Whenever an error occurs during evaluation, the error message should show a stack trace showing the calls that led to this error. To minimize screen space usage, each entry should consist of a single line: at <function name> (<file>:<line>:<col>).

Currently, Vm doesn’t keep track of the information needed to generate a stack trace. We could make it do so using one of the following methods:

• rename Vm to Frame and make Vm a stack of Frames, plus a Vec<StackTraceEntry> that is pushed and popped on function calls and returns
• add a RefCell<Vec<StackTraceEntry>> field to Vm
• add an Arc<StackTrace> field to Vm, where StackTrace stores a StackTraceEntry for the current frame and an Option<Arc<StackTrace>> for the rest of the trace. This makes the trace a linked list with shared nodes, which requires some pointer chasing to traverse but incurs less cost than the other approaches to store these traces in Content nodes (see below).

Use Case

Make it easier to debug these types of errors.

Related issues: #1702

Possible drawbacks:

• adds extra complexity
• incurs extra overhead

Start by locating Vm, Content nodes, and the rendering paths for functions such as cite or locate. Compare the proposed stack-trace storage approaches and related issue #1702; done means errors from user code during rendering display a useful call stack while accounting for the stated complexity and overhead concerns.