From @masak

<moritz> nom​: say 'aa' ~~ /(.)$1/
<p6eval> nom ebd4d8​: OUTPUT«=> <a>␤ 0 => <a>␤␤»
<moritz> this... shouldn't match
<moritz> nom​: my $a; say so 'aaa' ~~ /$a/
<p6eval> nom ebd4d8​: OUTPUT«Use of uninitialized value in string
context␤Use of uninitialized value in string context␤Bool​::True␤»
<moritz> RONG
* masak submits rakudobug

I guess the correct behavior of an undefined interpolated value is
simply to always fail that part of the match.

From @jnthn

On Sat Oct 01 02​:51​:01 2011, masak wrote​:

<moritz> nom​: say 'aa' ~~ /(.)$1/
<p6eval> nom ebd4d8​: OUTPUT«=> <a>␤ 0 => <a>␤␤»
<moritz> this... shouldn't match
<moritz> nom​: my $a; say so 'aaa' ~~ /$a/
<p6eval> nom ebd4d8​: OUTPUT«Use of uninitialized value in string
context␤Use of uninitialized value in string context␤Bool​::True␤»
<moritz> RONG
* masak submits rakudobug

I guess the correct behavior of an undefined interpolated value is
simply to always fail that part of the match.

Now​:

say so 'aa' ~~ /(.)$1/
Bool​::False
my $a; say so 'aaa' ~~ /$a/
Bool​::False

Note that we can catch the first one at compile time in the future, but
failing to match satisfies this ticket.

Tests needed.

/jnthn

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

From @FROGGS

<FROGGS> r​: say 'aa' ~~ /(.)$1/
<p6eval> ..rakudo 4fb07b​: OUTPUT«#<failed match>␤»
<FROGGS> r​: say 'aa' ~~ /(.)$0/
<p6eval> rakudo 4fb07b, niecza v24-19-g5f89e5f​: OUTPUT«｢aa｣␤ 0 => ｢a｣␤␤»

Test​: https://github.com/perl6/roast/blob/master/S05-mass/rx.t#L2950

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