From @samcv

Expected result​:
m​: my $b = 'a b c'; $b ~~ s​:ss/a /space/; say $b
OUTPUT«spaceb c␤»

What happens with <$a>
m​: my $a = 'a '; my $b = 'a b c'; $b ~~ s​:ss/<$a>/space/; say $b
OUTPUT«space b c␤»

Or with only one space​:
m​: my $a = ' '; my $b = 'a b c'; $b ~~ s​:ss/<$a>/space/; say $b
OUTPUT«===SORRY!=== Error while compiling /home/camelia/EVAL_0␤Null regex not
allowed␤at /home/camelia/EVAL_0​:1␤------> anon regex { ⏏}␤»

From @AlexDaniel

On 2016-11-07 17​:42​:33, samantham@​posteo.net wrote​:

Expected result​:
m​: my $b = 'a b c'; $b ~~ s​:ss/a /space/; say $b
OUTPUT«spaceb c␤»

What happens with <$a>
m​: my $a = 'a '; my $b = 'a b c'; $b ~~ s​:ss/<$a>/space/; say $b
OUTPUT«space b c␤»

Or with only one space​:
m​: my $a = ' '; my $b = 'a b c'; $b ~~ s​:ss/<$a>/space/; say $b
OUTPUT«===SORRY!=== Error while compiling /home/camelia/EVAL_0␤Null
regex not
allowed␤at /home/camelia/EVAL_0​:1␤------> anon regex { ⏏}␤»

In case of <$a> it is probably more LTA than the bug. For example, the error message points to EVAL file which does not exist really.

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

From @samcv

https://design.perl6.org/S05.html Reading this again, it seems that leading
whitespace is ignored. It says​:
"The new :s (​:sigspace) modifier causes certain whitespace sequences to be
considered "significant"; they are replaced by a whitespace matching rule,
<.ws>. Only whitespace sequences immediately following a matching construct
(atom, quantified atom, or assertion) are eligible. Hence, initial whitespace
is ignored at the front of any regex, to make it easy to write rules that can
participate in longest-token-matching alternations. "

I also checked sigspace.t in roast, and there are tests only specifying what
happens for leading whitespace when you use inline :s, but none of them test
for non inline, such as m​:s/ abc/ and none test for what happens on trailing
whitespace ( m​:s/abc / ). So not matching m​:s/ / is not a bug, but not
matching "a " ~~ m​:s/a / may be.

From @samcv

Actually it has nothing to with <$a>, and this triggers it as well​:
m​: ' ' ~~ m​:s/ /;
OUTPUT«===SORRY!=== Error while compiling <tmp>␤Null regex not allowed␤at
<tmp>​:1␤------> ' ' ~~ m​:s/ ⏏/;␤»

If this is indeed a bug, this should probably be renamed.

From @samcv

https://design.perl6.org/S05.html Reading this again, it seems that leading
whitespace is ignored. It says​:
"The new :s (​:sigspace) modifier causes certain whitespace sequences to be
considered "significant"; they are replaced by a whitespace matching rule,
<.ws>. Only whitespace sequences immediately following a matching construct
(atom, quantified atom, or assertion) are eligible. Hence, initial whitespace
is ignored at the front of any regex, to make it easy to write rules that can
participate in longest-token-matching alternations. "

I also checked sigspace.t in roast, and there are tests only specifying what
happens for leading whitespace when you use inline :s, but none of them test
for non inline, such as m​:s/ abc/ and none test for what happens on trailing
whitespace ( m​:s/abc / ). So not matching m​:s/ / is not a bug, but not
matching "a " ~~ m​:s/a / may be.

From @samcv

See IRC log here​: https://irclog.perlgeek.de/perl6/2016-12-31#i_13829291

TimToady says trailing spaces are supposed to be matched, so tests should be added to roast to that effect and the synopsis clarified.

From @samcv

Tests added with this commit​: Raku/roast@bb45101

Specs clarified with Raku/old-design-docs@78c4211

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