On Mon, 02 Oct 2017 19:08:27 -0700, alex.jakime...@gmail.com wrote: > Also worth taking a look at > https://rt.perl.org/Ticket/Display.html?id=126569 > > On 2017-09-29 14:06:58, b...@abrij.org wrote: > > On Sun, 28 May 2017 00:08:18 -0700, sml...@gmail.com wrote: > > > This bug is still present in > > > > > > This is Rakudo version 2017.05-134-g0c5fe56cc built on MoarVM > > > version > > > 2017.05-25-g62bc54e9 > > > implementing Perl 6.c. > > > > > > OK, keeping in mind that I have entirely, absolutely no idea what I > > am > > doing... > > > > I figured out that the block inside the string inside the parens is > > being annotated > > to a statement ID one greater than that of the whole statement_mod, > > which means > > it doesn't get "migrated". I also figured out that it seems to be the > > case that > > no blocks from inside the predicate of the for/given appear in the > > list considered > > for migration. I don't know if the annotation is correct or not, and > > I don't know > > if there is some contorted syntax that could put a block in the list > > of considered > > items for migration which would be erroneously migrated, but simply > > changing > > make_topic_block_ref to also grab all in_stmt_mod blocks with a > > statement ID higher > > than the one it is handed seems to pass all spectests and "fix" this > > problem. > > > > Resulting in the following one-character patch (drumroll please): > > > > diff --git a/src/Perl6/Actions.nqp b/src/Perl6/Actions.nqp > > index 36fa59b2b..6576f61b7 100644 > > --- a/src/Perl6/Actions.nqp > > +++ b/src/Perl6/Actions.nqp > > @@ -8953,7 +8953,7 @@ class Perl6::Actions is HLL::Actions does > > STDActions { > > $*W.pop_lexpad(); > > if nqp::defined($migrate_stmt_id) { > > migrate_blocks($*W.cur_lexpad(), $block, -> $b { > > - !$b.ann('in_stmt_mod') && ($b.ann('statement_id') // > > -1) == $migrate_stmt_id > > + !$b.ann('in_stmt_mod') && ($b.ann('statement_id') // > > -1) >= $migrate_stmt_id > > }); > > } > > ($*W.cur_lexpad())[0].push($block); > > > > Now, all that said, I cannot begin to properly emphasize the massive > > extent of the heck of which I do not know here. > > > > So, this is either the right fix, or a very wrong fix which might > > just > > break things in a way > > roast test writers are just not twisted and deviant enough to think > > of, or a fix that doesn't > > catch derivative cases, or... > > > > Other cases tested with this patch: > > > > $ perl6 -e 'say ("{$_}") given <aa bb>' > > aa bb > > $ perl6 -e 'say ("{$_}") if True given <aa bb>' > > aa bb > > $ perl6 -e 'say ("{$_}") if ({True}) given <aa bb>' > > aa bb > > $ perl6 -e 'say ("{$_}") if ("{True}") given <aa bb>' > > aa bb > > $ perl6 -e 'say ("{$_}") if "{True}" given <aa bb>' > > aa bb > > $ perl6 -e 'say ("{$_}") if "{so $_}" given <aa bb>' > > aa bb > > $ perl6 -e 'say ("{$_}") if ("{$_ ~~ /bb/ ?? q|1| !! q|| }") for <aa > > bb> ' > > bb > > $ perl6 -e 'say ("{$_}") for ("{$_}" for <aa bb>)' > > aa > > bb > > $ perl6 -e 'my $a = 13; say ("{$_}") for {my $a = 42; ("{$a}" for <aa > > bb> )}()' > > 42 > > 42
I'm still running with that patch installed and yes, it does seem to help the example in 126569 to work.
