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

Assigning to a hash with the same hash in the rhs of the assignment causes the hash to become empty in Rakudo #2123

Closed
p6rt opened this issue Aug 31, 2010 · 5 comments

Comments

@p6rt
Copy link

p6rt commented Aug 31, 2010

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

Searchable as RT77586$

@p6rt
Copy link
Author

p6rt commented Aug 31, 2010

From @masak

<masak> rakudo​: my %h = 1 => "foo", 2 => "bar", 3 => "foo"; %h = grep
{ .value ne "bar" }, %h.pairs; say %h.perl
<p6eval> rakudo f8e959​: OUTPUT«{}␤»
<masak> anyone but me thinks that the result should contain two pairs?
<patrickas> rakudo​: my %h = 1 => "foo", 2 => "bar", 3 => "foo"; my %n
= grep { .value ne "bar" }, %h.pairs; say %n.perl
<p6eval> rakudo f8e959​: OUTPUT«{"1" => "foo", "3" => "foo"}␤»
* masak submits rakudobug
<masak> patrickas++ # workaround
<masak> rakudo​: my %h = 1 => "foo"; %h = %h; say %h.perl
<p6eval> rakudo f8e959​: OUTPUT«{}␤»
<masak> rakudo​: my %h = 1 => "foo"; my %n = %h; say %n.perl
<p6eval> rakudo f8e959​: OUTPUT«{"1" => "foo"}␤»
<patrickas> duh!
<masak> doubleplusungood.
<patrickas> rakudo​: my %h = 1 => "foo"; %h = %h.clone; say %h.perl;
<p6eval> rakudo f8e959​: OUTPUT«{"1" => "foo"}␤»
<patrickas> might be slightly nicer than creating a named temporary
variable as a workaround
<masak> indeed.

@p6rt
Copy link
Author

p6rt commented Jul 1, 2011

From @pmichaud

Now fixed in nom branch @​ 6cd9c42. We need to identify a spectest for
this ticket, and then it can be closed.

Pm

@p6rt
Copy link
Author

p6rt commented Jul 1, 2011

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

@p6rt
Copy link
Author

p6rt commented Mar 29, 2013

From @coke

On Fri Jul 01 09​:12​:46 2011, pmichaud wrote​:

Now fixed in nom branch @​ 6cd9c42. We need to identify a spectest for
this ticket, and then it can be closed.

Pm

Looks like a test for this was added to S03-operators/assign.t back in 2011.

Resolving ticket.

--
Will "Coke" Coleda

@p6rt
Copy link
Author

p6rt commented Mar 29, 2013

@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