From @masak

<doy> r​: sub s () { given 9 { return 0 when $_ %% 3; 1 } }; say s
<p6eval> rakudo c8de2e​: OUTPUT«===SORRY!===␤Null regex not allowed [...]
<doy> r​: sub s () { given 9 { return 0 when $_ %% 3; 1 } }; say s;
<p6eval> rakudo c8de2e​: OUTPUT«0␤»
<masak> that first one is arguably a bug.
<masak> r​: sub s {}; say s
<p6eval> rakudo c8de2e​: OUTPUT«===SORRY!===␤Null regex not allowed [...]
* masak submits rakudobug
<masak> std​: sub s {}; say s
<p6eval> std a8bc48f​: OUTPUT«===SORRY!===␤No delimiter found
[...]Parse failed␤FAILED 00​:00 42m␤»
<masak> std​: sub s {}; say s;
<p6eval> std a8bc48f​: OUTPUT«===SORRY!===␤Regex not terminated [...]
Parse failed␤FAILED 00​:00 43m␤»
<masak> oh, ok.
<masak> it's the 's;' case that is wrongly parsed.

From @jnthn

On Sun Dec 23 14​:29​:06 2012, masak wrote​:

<doy> r​: sub s () { given 9 { return 0 when $_ %% 3; 1 } }; say s
<p6eval> rakudo c8de2e​: OUTPUT«===SORRY!===␤Null regex not allowed
[...]
<doy> r​: sub s () { given 9 { return 0 when $_ %% 3; 1 } }; say s;
<p6eval> rakudo c8de2e​: OUTPUT«0␤»
<masak> that first one is arguably a bug.
<masak> r​: sub s {}; say s
<p6eval> rakudo c8de2e​: OUTPUT«===SORRY!===␤Null regex not allowed
[...]
* masak submits rakudobug
<masak> std​: sub s {}; say s
<p6eval> std a8bc48f​: OUTPUT«===SORRY!===␤No delimiter found
[...]Parse failed␤FAILED 00​:00 42m␤»
<masak> std​: sub s {}; say s;
<p6eval> std a8bc48f​: OUTPUT«===SORRY!===␤Regex not terminated [...]
Parse failed␤FAILED 00​:00 43m␤»
<masak> oh, ok.
<masak> it's the 's;' case that is wrongly parsed.

Looks better now​:

sub s () { given 9 { return 0 when $_ %% 3; 1 } }; say s;
===SORRY!===
Regex not terminated

Tagging testneeded.

/jnthn

The RT System itself - Status changed from 'new' to 'open'

From @coke

On Mon Mar 11 12​:40​:13 2013, jnthn@​jnthn.net wrote​:

On Sun Dec 23 14​:29​:06 2012, masak wrote​:

<doy> r​: sub s () { given 9 { return 0 when $_ %% 3; 1 } }; say s
<p6eval> rakudo c8de2e​: OUTPUT«===SORRY!===␤Null regex not allowed
[...]
<doy> r​: sub s () { given 9 { return 0 when $_ %% 3; 1 } }; say s;
<p6eval> rakudo c8de2e​: OUTPUT«0␤»
<masak> that first one is arguably a bug.
<masak> r​: sub s {}; say s
<p6eval> rakudo c8de2e​: OUTPUT«===SORRY!===␤Null regex not allowed
[...]
* masak submits rakudobug
<masak> std​: sub s {}; say s
<p6eval> std a8bc48f​: OUTPUT«===SORRY!===␤No delimiter found
[...]Parse failed␤FAILED 00​:00 42m␤»
<masak> std​: sub s {}; say s;
<p6eval> std a8bc48f​: OUTPUT«===SORRY!===␤Regex not terminated [...]
Parse failed␤FAILED 00​:00 43m␤»
<masak> oh, ok.
<masak> it's the 's;' case that is wrongly parsed.

Looks better now​:

sub s () { given 9 { return 0 when $_ %% 3; 1 } }; say s;
===SORRY!===
Regex not terminated

Tagging testneeded.

/jnthn

This has reverted to its original failing behavior​:

21​:05 < [Coke]> m​: sub s () { given 9 { return 0 when $_ %% 3; 1 } }; say s
21​:05 <+camelia> rakudo-moar 347c9a​: OUTPUT«===SORRY!=== Error while compiling
  /tmp/ag0yDBP3BL␤Null regex not allowed␤at
  /tmp/ag0yDBP3BL​:1␤------> 9 { return 0 when $_ %% 3; 1 } };
  say s⏏<EOL>␤ expecting any of​:␤ argument list␤
  pre…»

--
Will "Coke" Coleda

From @usev6

As I understand this bug report, the problem was this​:

<doy> r​: sub s () { given 9 { return 0 when $_ %% 3; 1 } }; say s;
<p6eval> rakudo c8de2e​: OUTPUT«0␤»

As the subject says the "s;" was parsed as a subroutine call by Rakudo. Back in 2012 the bug could have been shown a bit shorter​:

$ perl6 -e 'sub s { say 42 }; s;'
42

Now we get​:

$ perl6 -e 'sub s { say 42 }; s;'
===SORRY!===
Regex not terminated.
at -e​:1
------> sub s { say 42 }; s;⏏<EOL>

The "s;" is no longer parsed as a subroutine call, instead we get a parsing error. That's the correct behaviour -- and also how STD parses the code​:

$ viv -c -e 'sub s { say 42 }; s;'
===SORRY!===
Regex not terminated at (eval) line 1 (EOF)​:
------> sub s { say 42 }; s;⏏<EOL>
Parse failed

I'll add a test and close the ticket. Please correct me if I misunderstood the problem.

From @usev6

I added two tests (for parsing "s;" and "m;") to S02-names-vars/names.t with the following commit​: Raku/roast@9cafef7ce7

@usev6 - Status changed from 'open' to 'resolved'