Include record of inlined functions

[shicks]

Many optimizers inline functions, but this can cause confusion when looking at stack traces: function A might be called by B which is called by C, but if B is inlined, the developer might only see C calling A directly, which doesn't make sense from looking at the source.

Dart's source map extensions have a potential solution for this by recording the inlined functions in a way that allows the stack trace to be filled back in with the inlined functions. We should consider including this in any new version of source maps.

This probably fits into the scopes/naming workstream?

@sigmundch probably has more to say about this (or can point me to an earlier-filed issue if this is a dupe).

[jkrems]

Related issue (more generically): #33

[sigmundch]

Thanks for filing the issue @shicks - happy to share more about our experience here if anyone has questions.

[rakudrama]

The Dart sourcemap extension is a good starting point but our experience has shown that it has a small shortcoming.
When inlining, there is a need to map the location of an error differently to the location of a successful in-progress call.
For example, they can have different levels of inlining.

Consider this program:

function call1(a) { return call2(a); }
function call2(a) { return a.method1(null); }
class Thing {
  method1(b) { return this.method2(b); },
  method2(b) { return b.foo(); },
}
function main() {
  call1(new Thing());
  call1(null);
}

Inlining of call2 and method1 could reduce call1 to:

function call1(a) { return a.method2(null); }
//                          ^

It is reasonable to inline method1 because even though the receiver might be null, the program will fail with a TypeError on the same irritant.

When a is null, the error location is in call1 and the actual stack is call1; main.
This should be mapped to call2; call1; main.
When a is not null, the error location is in method2 and actual stack is method2; call1; main.
This should be mapped to method2; method1; call2; call1; main.

The single indicated location in the inlining version of call1 corresponds to the sequence call2; call1 for an error location and method1; call2; call1 for a non-error stack frame.

Hopefully a new sourcemap format will address this problem and provide a way to map the error location independently to a deeper frame.

I stress independently because in the case of Dart, the stack frame sequence that corresponds to an error location is not necessarily a prefix of the sequence for errors called from that location.
For more on the specific Dart scenario, see dart-lang/sdk#52580