From:  Nick Fitzgerald <nfitzgerald@mozilla.com>
Date:  03 Feb 2015 05:14:34 Hong Kong Time
Newsgroup:  news.mozilla.org/mozilla.dev.js-sourcemap
Subject:  

Re: Source Maps, Debuggers, and Generated Code

NNTP-Posting-Host:  63.245.216.66

Hi Ron,

Replies inline below.

On Mon, Feb 2, 2015 at 11:57 AM, Ron Buckton 
wrote:

> Many transpilers today (TypeScript, Traceur, 6to5, etc.) often need to
> emit generated code, that sometimes does not have a one-to-one mapping with
> the original source. One of the most notorious examples is the down-level
> transpile for ES6 generators, which often introduces multiple statements
> that correspond to a single statement or expression in the original source.
> TypeScript either elides mapping information for helper functions such as
> the __extends helper in some cases and in others maps the multiple steps to
> a single source span, such as how it handles a rest parameter. Traceur adds
> the generated code to the "sourcesContent" array in the source map.
>


​I think there are two cases here:

1. When the compiler needs to embed a runtime with various helper functions
in the generated JS code. In this case, I think it makes sense to add an
entry to the sources list and map the appropriate code to this runtime
source.

2. When a single statement in the source language results in many
statements in the JS code. In this case, I believe that all the generated
statements in the JS code should map back to the same location in the
source language. When implementing source level single stepping, debuggers
should continue JS object code level single stepping until the source map
reports a new source location for the current JS code. This is conceptually
the same as when single stepping C-source level statements in gdb/lldb/etc
that map to multiple asm instructions: you don't want to pause after
executing each asm instruction, but once all the asm instructions for that
C statement have been executed.



>
> In addition, various debuggers with source-map support handle generated
> content differently. In the Chrome Dev Tools and in Visual Studio, any step
> in the debugger that is not mapped to a source span results in stepping
> through the generated javascript file until a mapping is encountered, while
> in the IE F12 tools the debugger makes every effort to keep the source
> content visible and highlights the last source span for each step in the
> generated output.
>
>
​For the record, Firefox will continue through null mappings as well.​



> Is there a standard approach to how this content should be mapped, or how
> stepping should be handled? I'm currently investigating whether it makes
> sense to propose an extension to the source map specification to classify a
> range in the generated output as "debugger hidden", so that a debugger will
> always step through any statements within this range. Alternatively, I'm
> interested in whether it would make sense for debuggers to treat generated
> lines with no mappings as "debugger hidden", as well as step through
> multiple operations if they all map to the same source location.
>

​I don't think this needs an extension: I believe continuing through null
mappings is the correct behavior.