On Wed Nov 18 06:24:03 2015, pesc...@gmail.com wrote:
> On Sun Oct 18 04:50:28 2015, n...@detonation.org wrote:
> > 13:49 <+yoleaux> 17 Oct 2015 17:45Z <jnthn> nine: IIRC, it was .clone
> > not being deep enough, but I don't remember exactly either :(
> > 13:49 <+yoleaux> 17 Oct 2015 17:45Z <jnthn> nine: Maybe not creating
> > fresh Scalar containers or so
>
> Current behavior:
>
> 14:17 < psch> r: role R { has @.s is rw }; multi
> trait_mod:<is>(Routine $r, :$x!) { $r does R; sub h(|){ for $r.s {
> &^m() } }; $r.wrap(&h) }; sub b is x {}; push &b.s, { say "OH HAI" };
> b # slightly adapted from RT #112666
> 14:17 <+camelia> rakudo-{moar,jvm} 61e505: OUTPUT«OH HAI»
> 14:18 < psch> changes are: signature for &h can't have |$, and the
> trait signature needs the Routine type for $r
> 14:18 < psch> but that's the one that didn't output anything in the
> ticket, except for those two changes
> 14:19 * psch adds that to the ticket
>
> Note that this is code snippet that doesn't explicitly vivify $r.s in
> the trait declaration, yet the output matches the one that does:
>
> 14:22 <psch> r: role R { has @.s is rw }; multi trait_mod:<is>(Routine
> $r, :$x!) { $r does R; $r.s; sub h(|){ for $r.s { &^m() } };
> $r.wrap(&h) }; sub b is x {}; push &b.s, { say "OH HAI" }; b
> 14:22 <camelia> rakudo-{moar,jvm} 61e505: OUTPUT«OH HAI»
This suggested the bug was fixed. I tried the code on its own. Worked. Put it
in a test file. Failed. Wait, what?
Turns out the significant difference was the whole lot being in a nested block.
The original bug never went away, but an optimization hid it. And the bug
itself came from an optimization involving lazy allocation of attribute
storage, which we just can't rely on getting away with when doing mixins to
meta-objects. So, fixed that. Test in S14-traits/routines.t.
