PIR line numbers in backtraces are substantially wrong.

[Austin_Hastings]

This may duplicate or supersede  RT 40204 and (by extension)  RT 38594.

Earlier tickets (above) claim that there is an off-by-one error in diagnostics. This bug is now an off-by-a-huge-amount error.

In my example files, I get an error with a backtrace. The trace looks like:

positional inside named args at position 2
current instr.: 'close;close;TypeInfo;main' pc 129 (try.pir:87)
called from Sub 'close;close;TypeInfo;main' pc 567 (try.pir:0)
called from Sub 'close;close;TypeInfo;init' pc 606 (try.pir:303)
called from Sub 'close;close;TypeInfo;main' pc -1 ((unknown file):-1)

In fact, there is no correlation between the line numbers printed and the Sub names given. The 'init' sub runs from try.pir:353-358, and the 'main' sub runs from try.pir:288-347.

(To run the attached files, which take a lot of code to accomplish nothing, put them in the same directory and run parrot try.pir.)

Note that there is a suggestion in RT# 40204 that line number information is being emitted wrong into the pbc files.

[Austin_Hastings]

Source code demonstrating incorrect line numbers error.

[Austin_Hastings]

Library needed by try.pir

[coke]

Austin - when I run this sample now, I get:

Loading close library
A method named 'new' already exists in class 'close;TypeInfo'. It may have been supplied by a role.
current instr.: 'close;close;TypeInfo;_init_class_TypeInfo' pc 217 (try.pir:1)

So, I'm going to reject this ticket - There have been some improvements in the line number handling in the past few months, but if you can still generate these large discrepencies, please open a new ticket.

Thanks.