-
Notifications
You must be signed in to change notification settings - Fork 196
Description
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
Activity
leafo commentedon Jan 10, 2014
Just an aside, you can use
moonc -X file.moon
to dump the rewrite mapping for debugging stuff like thisYou can see the problematic remapping:
eloff commentedon Jan 12, 2014
Thanks leafo, I was unaware of that. Is this is a difficult problem to fix?
eloff commentedon Jan 21, 2014
Hi leafo, do you have an idea what the problem might be?
leafo commentedon Jan 21, 2014
Sorry, didn't get a chance to look into it yet.
Yorwba commentedon Feb 1, 2014
The bug seems to be in compile.moon, line 46.
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 thatself.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 toline_no
, although I'm not sure how that could be done with the quite minimalDelayedLine
:D.