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«1␤1␤1␤»
> <p6eval> ..niecza v24-18-gaf64300: OUTPUT«1␤2␤3␤»
> * 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«1␤2␤3␤»
> 
> 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

Reply via email to