Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

'state' with anonymous scalars works more like 'my' in Rakudo #3033

Closed
p6rt opened this issue Jan 23, 2013 · 8 comments
Closed

'state' with anonymous scalars works more like 'my' in Rakudo #3033

p6rt opened this issue Jan 23, 2013 · 8 comments

Comments

@p6rt
Copy link

p6rt commented Jan 23, 2013

Migrated from rt.perl.org#116521 (status was 'resolved')

Searchable as RT116521$

@p6rt
Copy link
Author

p6rt commented Jan 23, 2013

From @masak

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.

@p6rt
Copy link
Author

p6rt commented Jan 23, 2013

From @masak

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>
rakudo/rakudo@bd9bc6f
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

@p6rt
Copy link
Author

p6rt commented Jan 23, 2013

@masak - Status changed from 'new' to 'open'

@p6rt
Copy link
Author

p6rt commented Mar 8, 2013

From @jnthn

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

Correct now​:

sub f { say ++state $ ; }; f; f; f
1
2
3

<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␤»

And also correct​:

sub f { say ++state $ ; }; f; f; f
1
2
3

Tagging testneeded.

/jnthn

@p6rt
Copy link
Author

p6rt commented May 20, 2013

From @labster

Added file S02-names/bare-sigil.t to roast, which tests for this
behavior. Everything passes as I expect.

Resolving ticket.

@p6rt
Copy link
Author

p6rt commented May 20, 2013

From @labster

On Mon May 20 00​:28​:53 2013, labster wrote​:

Added file S02-names/bare-sigil.t to roast, which tests for this
behavior. Everything passes as I expect.

Resolving ticket.

Or, well, not resolving... why does RT give you options you can't use?
Can someone else close this?

@p6rt
Copy link
Author

p6rt commented Jan 15, 2014

From @coke

On Mon May 20 00​:30​:04 2013, labster wrote​:

On Mon May 20 00​:28​:53 2013, labster wrote​:

Added file S02-names/bare-sigil.t to roast, which tests for this
behavior. Everything passes as I expect.

Resolving ticket.

Or, well, not resolving... why does RT give you options you can't use?
Can someone else close this?

Yes!

--
Will "Coke" Coleda

@p6rt p6rt closed this as completed Jan 15, 2014
@p6rt
Copy link
Author

p6rt commented Jan 15, 2014

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant