better document the "names" field in Source Maps

[Brian Slesinsky]

(Sending this to the list since I can't comment directly on the document.)

Re:
https://docs.google.com/a/google.com/document/d/1U1RGAehQwRypUTovF1KRlpiOFze0b-_2gc6fAH0KY0k/edit#

A comment on this line:
Line 7: A list of symbol names used by the “mappings” entry.

I think the spec should explain a bit more about how this is typically
used. Despite doing a fair amount of work with sourcemaps, I was unclear on
this until recently.

As far as I know no debugger uses the "names" field, but the intention is
to deobfuscate stack traces. That is, when a JavaScript exception occurs or
a debugger stops at a breakpoint, we can treat the stack trace as a list of
positions in JavaScript files. For each position, the "name" is the
deobfuscated function name that should appear in the stack trace. (Or more
generally, it is whatever string would most usefully appear in the function
name position when displaying a stack frame in the debugger.)

- Brian

[Joey Schorr]

The intention was to both deobfuscate stack traces and provide a way for
de-minimization of source code if the mapping was semi-direct. The old
Closure Inspector (https://code.google.com/p/closure-inspector/) would
actually use the names to remap the source code view inline, but this
obviously only applied to the Closure case where the input language was
also (basically) JavaScript.

> _______________________________________________
> dev-js-sourcemap mailing list
> dev-js-s...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-js-sourcemap
>

[John Lenz]

Yeah, it isn't clear and was left in primarily because it have any cost
associated with it. But yes, the intent was to provide to link to the
original names used for a variable, with the Closure Compiler's various
form of variable and property name forking and joining (when fully
optimized) there is no way to use a simply map of names, so you need to
provide it at the place of reference.

But no one has really taken advantage of this for a while as Joey points
out .

[Brian Slesinsky]

Okay, then what should a language-independent debugger do with the names
field, since it doesn't know anything about the source language? Do we want
the name to appear in stack traces as a function name? If so, that
constrains what compilers should put there, at least for those JavaScript
ranges that cover executable code where a breakpoint could be set.

A related issue is how a debugger decides whether a breakpoint can be set
at a particular source line. I believe in Chrome, any source line that maps
to a JavaScript range is assumed to be a valid place to put a breakpoint.
If the compiler doesn't want debuggers to allow a source-level breakpoint
there, the only influence the compiler has is to not map that range.

GWT currently doesn't do a great job of this (breakpoints can be set in
weird places and can be jump around). We could clean things up for Chrome
but other browsers should work similarly. So it seems like the spec could
be a good place to say how to communicate effectively with debuggers.

- Brian