Bug: Line maps / tracebacks incorrect for this moonscript code

[eloff]

I managed to create a somewhat minimal repro, but the behavior is extremely odd and fragile to changes. The rewritten traceback line numbers for moon code are wrong sometimes. Here's the code. Delete one of the lines containing numbers and the line numbers are suddenly accurate. Add more and the line numbers change strangely.

class bar
    new: (opts={}) =>
        @qux or= opts.qux

        @umm!

    huh: =>
        {
            bar: [[
                1
                2
                3
                4
                5
                6
                7
                8
                9
            ]]
        }

    umm: =>
        @foo = opts.foo

bar!

I get the following, which should be 23, not 3. If I add one more line with the number 10 it changes to 5 (should be 24). Add numbers up to 25 and the line number changes to the call to bar (41). For 24 it's still 5.

moon: repro_spec.moon:3: (19) attempt to index global 'opts' (a nil value)
stack traceback:
repro_spec.moon:3: (19) in function '__init'
repro_spec.moon:25: (37) in function 'bar'
repro_spec.moon:25: (44) in main chunk

[leafo]

Just an aside, you can use moonc -X file.moon to dump the rewrite mapping for debugging stuff like this

You can see the problematic remapping:

325  10:[ 5 ] >> 23:[ @foo = opts.foo ]

[eloff]

Thanks leafo, I was unaware of that. Is this is a difficult problem to fix?

[eloff]

Hi leafo, do you have an idea what the problem might be?

[leafo]

Sorry, didn't get a chance to look into it yet.

[Yorwba]

The bug seems to be in compile.moon, line 46.

41  flatten_posmap: (line_no=0, out={}) =>
42    posmap = @posmap
43    for i, l in ipairs @
44      switch mtype l
45        when "string", DelayedLine
46          line_no += 1 --> not always correct
47          out[line_no] = posmap[i]
48        when Lines
49          _, line_no = l\flatten_posmap line_no, out
50        else
51          error "Unknown item in Lines: #{l}"
52
53    out, line_no

flatten_posmap treats every generated string of code as a single line, even if it consists of multiple lines, like the verbatim string. This means that self.foo = opts.foo is recorded to be on the tenth "line". The actual tenth line is then mapped to the source @foo = opts.foo as if it were the result of its compilation.
A more accurate implementation would have to to count the number of lines in l and add that number to line_no, although I'm not sure how that could be done with the quite minimal DelayedLine :D.