# New Ticket Created by Patrick R. Michaud
# Please include the string: [perl #47956]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=47956 >
This is a long one to explain, but it's another example showing
some difficulties with the current implementation of :outer
for lexical scopes.
The direct error is that compreg 'PIR' is unable to compile
source code where :init/:load subs are outer lexical scopes.
I suspect the fundamental problem lies with Parrot's design or
implementation of :outer/lexical scoping, but don't know enough
to say.
Consider the following PIR program:
$ cat x.pir
.sub 'MAIN'
say 'MAIN'
.return ()
.end
.namespace ['XYZ']
.sub 'BEGIN' :init :load
say 'XYZ::BEGIN'
.return ()
.end
.sub 'foo' :outer('BEGIN')
say 'XYZ::foo'
.return ()
.end
$
'BEGIN' is automatically invoked at init/load time, 'foo' is
a nested lexical scope within 'BEGIN'. (Yes, 'foo' is never
called in this example, but I think that should be irrelevant
to this bug.)
If we run this program directly from parrot, we get the
expected output.
$ ./parrot x.pir
XYZ::BEGIN
MAIN
$
However, if we read the PIR source into a string register and
then attempt to compile the string, it produces a compiler error:
$ cat y.pir
.sub 'compiler' :main
say 'compiler start'
say 'reading x.pir into $S0'
.local pmc ifh
ifh = open 'x.pir', '<'
unless ifh goto error_ifh
$S0 = ifh.'slurp'('')
close ifh
say 'compiling (but not running) $S0'
$P0 = compreg 'PIR'
$P1 = $P0($S0)
say 'done compiling'
goto end
error_ifh:
say 'unable to read x.pir'
end:
say 'compiler end'
.return ()
.end
$ ./parrot y.pir
compiler start
reading x.pir into $S0
compiling (but not running) $S0
XYZ::BEGIN
[oops; continuation 0x81dd678 of type 21 is trying to jump from runloop 2
to runloop 1]
src/inter_call.c:240: failed assertion 'PObj_is_PMC_TEST(sig_pmc)'
Backtrace - Obtained 32 stack frames (max trace depth is 32).
Parrot_print_backtrace
[...remainder of backtrace snipped...]
Note that the error comes from compiling the PIR source --
we never actually invoke the Code object that results
(except for the indirect invocation of the :load/:init sub).
Pm
