From @moritz

09​:56 < [0xF]> question #​2​: sub foo(Int $x is copy) { $x = 5; } f(1);
  # Cannot assign to a non-container
09​:56 < tadzik> r​: sub foo(Int $x is copy) { $x = 5; }; foo(1);
09​:56 <+camelia> rakudo 4109be​: OUTPUT«Cannot modify an immutable value␤
  in block at /tmp/eHvKDUJqEz​:1␤␤»

This is a bug. 'is copy' should make sure there's always a container.

Cheers,
Moritz

From @lizmat

[14​:28​:22] <lizmat> r​: sub a ( $a is copy ) { $a=5 }; a(1)
[14​:28​:24] <+camelia> rakudo 0e206e​: OUTPUT«Cannot modify an immutable value␤ in block at /tmp/Dmc8P4X3n2​:1␤␤»

While checking into this at the PLPW, it appears that this is an optimization problem. If rakudo is run with --optimize=0, this does not occur.

Initial investigation points at src/vm/parrot/guts/bind.c, line 1104, where some optimization magic apparently is making the wrong decision.

This seems to be up jnthn's alley :-)

From @jnthn

On Sun May 26 05​:33​:34 2013, elizabeth wrote​:

[14​:28​:22] <lizmat> r​: sub a ( $a is copy ) { $a=5 }; a(1)
[14​:28​:24] <+camelia> rakudo 0e206e​: OUTPUT«Cannot modify an
immutable value␤ in block at /tmp/Dmc8P4X3n2​:1␤␤»

While checking into this at the PLPW, it appears that this is an
optimization problem. If rakudo is run with --optimize=0, this does
not occur.

Initial investigation points at src/vm/parrot/guts/bind.c, line 1104,
where some optimization magic apparently is making the wrong decision.

This seems to be up jnthn's alley :-)

Fixed in Rakudo a6ac643, tested in roast 3b76c73.

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

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