On Wed Jan 23 02:35:53 2013, masak wrote: > I'm not one to use "it's broken" as a bug ticket description -- I > think it's bad style. But this is the exception that proves the rule: > somehow state not only isn't doing what it says on the tin, but it > breaks parsing, too. > > <masak> nr: sub f { say ++state $ ; }; f; f; f > <p6eval> rakudo a26956: OUTPUT«111» > <p6eval> ..niecza v24-18-gaf64300: OUTPUT«123» > * masak submits rakuobug > <masak> what's worse: > <masak> nr: sub f { say ++(state $ = 0); }; f; f; f > <p6eval> rakudo a26956: OUTPUT«===SORRY!===Error while compiling > block : Error while compiling op call: Error while compiling block : > Error while compiling block f: Error while compiling op p6typecheckrv: > Error while compiling op lexotic: Error while compiling op p6decontrv: > Error while compili… > <p6eval> ..niecza v24-18-gaf64300: OUTPUT«123» > > Niecza has it right both times.
<jnthn> masak: odd bug. wonder if it relates to my fixing the over- sharing bug. <jnthn> If so, it means we're missing some test coverage... * jnthn is surprised we'd be missing it for anon state vars <masak> jnthn: when did you fix? I'd like to bisect. <jnthn> Not sure, recently <jnthn> It was the bug when my @ and a later my @ would share the value * masak goes looking <masak> https://github.com/rakudo/rakudo/commit/bd9bc6ff017a78783a039282ae9e36f9 74af3d8a <masak> jnthn: confirmed #1: in bd9bc6f^, 'state' works. <masak> jnthn: confirmed #2: in bd9bc6f, 'state' is b0rken. * masak adds this to the RT ticket