# New Ticket Created by Pepe Schwarz
# Please include the string: [perl #126490]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt.perl.org/Ticket/Display.html?id=126490 >
R-J currently fails in about five files in roast with "control exception
without handler", golfable as follows:
16:08 <psch> r: A: for 1 { for 1 { last A } };
16:08 <camelia> rakudo-jvm 3cc195: OUTPUT«===SORRY!===control exception
without handler»
16:08 <camelia> ..rakudo-moar 3cc195: ( no output )
Digging around a bit showed that in this specific case the exception is of type
4104, e.g. last_labeled, which clearly is correct.
The case of last-ing out of the current loop (with or without label) works, as
follows:
16:12 <psch> j: A: for 1 { last A }; for 1 { last }
16:12 <camelia> rakudo-jvm 3cc195: ( no output )
Installing a CONTROL block in the labeled loop in the first case works somewhat
as expected, the exception is caught, but doesn't identify itself as CX::Last:
16:15 <psch> j: A: for 1 { for 1 { last A }; CONTROL { when CX::Last { say
"last" }; default { .perl.say } } }
16:15 <camelia> rakudo-jvm 3cc195: OUTPUT«X::AdHoc.new(payload => "Died")»
The same code on R-M segfaults:
16:15 <psch> m: A: for 1 { for 1 { last A }; CONTROL { when CX::Last { say
"last" }; default { .perl.say } } }
16:15 <camelia> rakudo-moar 3cc195: OUTPUT«(signal SEGV)»
I have looked at the R-J and NQP-J CX handling, and have the suspicion that
responsibility partly lies with org.perl6.nqp.runtime.ExceptionHandling:90,
where it's decided not to use a handler if it's from the current frame. The
corresponding code in Moar is beyond my C-understanding, but I further suspect
that either the condition for discarding a possibly valid handler is different,
or that codegen on moar inserts handlers differently.
Also of note might be that neither NQP implements labeled loops themselves,
even though it's from NQP::Grammar and NQP::Actions that we get handling of
last/next/redo in the first place.
