# New Ticket Created by Patrick R. Michaud
# Please include the string: [perl #43269]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=43269 >
The 'setline' opcode doesn't do what I expect it to do, which
is to associate runtime errors with lines in HLL source.
For example, suppose I have a program "foo.p6" where
lines 123 and 124 contain the statements
$a = 9876;
nsf($a + 1);
A HLL compiler could then generate this as something like:
.sub anon
setfile "foo.p6"
setline 123
$P0 = new .Integer
assign $P0, 9876
set_global '$a', $P0
setline 124
$P0 = get_global '$a'
$P1 = clone $P0
add $P1, 1
'nsf'($P1)
.end
If the function 'nsf' doesn't exist, I expect get a runtime
exception of some sort that says that the error occurred on
line 124 of foo.p6. Currently parrot reports back that
the error occurs in line 128, as in:
Null PMC access in invoke()
current instr.: 'anon' pc 27 (foo.p6:128)
It appears to me that setfile and setline are currently being
conflated with the PIR directive C< #line "file.ext" nnn >.
I think we need both capabilities -- one to relate PIR
compilation errors relative to a known location in PIR source
(#line), and another to report runtime errors as a line number
in HLL source (setfile+setline).
RT #40806 has some related discussion for this. I'm also
committing the above code as a test (currently failing).
----
Another possibility may be to simply deprecate setfile/setline
altogether, and require other tools (e.g., PAST-pm) generate code
that sets global values somewhere for keeping track of the
HLL source locations.
Pm
