Declarative and procedural conjunctions in regex don't remember the keys of positional captures

[p6rt]

Migrated from rt.perl.org#124149 (status was 'open')

Searchable as RT124149$

[p6rt]

From @peschwa

19​:43 \< psch> m​: say ("a" ~~ /(.) | ./); say ("a" ~~ /(.) & ./) 19​:43 \<+camelia> rakudo-moar 5778e8​: OUTPUT«｢a｣␤ 0 => ｢a｣␤｢a｣␤ => ｢a｣␤» 19​:43 \< psch> the mysterious case of the disappearing 0 19​:43 \< FROGGS> O.o 19​:44 \< Mouq> m​: say ("a" ~~ /. & (.)/) [...] 19​:44 \<+camelia> rakudo-moar 5778e8​: OUTPUT«｢a｣␤ => ｢a｣␤» 19​:44 \< psch> nothing up my sleeve! 19​:44 \< FROGGS> m​: say ("a" ~~ /(.) | ./); $/ := Nil; say ("a" ~~ /(.) & ./) 19​:44 \<+camelia> rakudo-moar 5778e8​: OUTPUT«｢a｣␤ 0 => ｢a｣␤Cannot assign to an immutable value␤ in method ACCEPTS at src/gen/m-CORE.setting​:16293␤ in block \ at /tmp/8whqFAKjvR​:1␤␤» [...] 19​:44 \< FROGGS> m​: say ("a" ~~ /(.) | ./); $/ = Nil; say ("a" ~~ /(.) & ./) 19​:44 \<+camelia> rakudo-moar 5778e8​: OUTPUT«｢a｣␤ 0 => ｢a｣␤｢a｣␤ => ｢a｣␤» [...] 19​:45 \< psch> that kind of threw a wrench in my attempt to make .caps more reliable [...] 19​:45 \< jnthn> psch​: At a guess, the code generated for the & stuff could be mis-managing the cstack 19​:45 \< jnthn> I forget how on earth & is compiled, but it does involve some trickery with the marks. [...] 19​:46 \< psch> jnthn​: okay. the regex match code isn't for me, though. i'll RT it

19​:54 \ m​: say "a" ~~ /(.) && ./ 19​:54 \ rakudo-moar 5778e8​: OUTPUT«｢a｣␤ => ｢a｣␤»

[p6rt]

From @smls

The behavior is different now on Rakudo 2016.04-210-gc59e4dc.

The procedural version (&&) seems to handle captures correctly now​:

  ➜ say "a" ~~ / . && (.)/; # ｢a｣␤ 0 => ｢a｣   ➜ say "a" ~~ /(.) && . /; # ｢a｣␤ 0 => ｢a｣   ➜ say "a" ~~ /(.) && (.)/; # ｢a｣␤ 0 => ｢a｣␤ 1 => ｢a｣

However, the declarative version (&) does not seem to remember its captures at all​:

  ➜ say "a" ~~ / . & (.)/; # ｢a｣   ➜ say "a" ~~ /(.) & . /; # ｢a｣   ➜ say "a" ~~ /(.) & (.)/; # ｢a｣

[p6rt]

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