On Tue Jul 27 19:44:19 2010, coke wrote:
> On Wed Sep 30 06:50:05 2009, masak wrote:
> > <masak> rakudo: sub foo($a = $default, :$default = 42) {}; say
> "alive"
> > <p6eval> rakudo c8181a: OUTPUT«alive»
> > <masak> std: sub foo($a = $default, :$default = 42) {}
> > <p6eval> std 28514: OUTPUT«ok 00:02 104m»
> > <masak> rakudo: sub foo($a = $default, :$default = 42) { say $a };
> foo
> > <p6eval> rakudo c8181a: OUTPUT«Null PMC access in isa()in sub foo
> [...]
> > * masak submits rakudobug
> > <masak> today is a day of good harvest :)
> > <moritz_> uhm, why doesn't STD.pm complain about $default not being
> defined?
> > <masak> STD bug?
> > <moritz_> STD bug.
> > * masak hightlights TimToady
> > <masak> rakudo: sub foo($a = $default, :$default = 42) { say 'alive'
> }; foo
> > <p6eval> rakudo c8181a: OUTPUT«Null PMC access in isa()in sub foo
>
> Rakudo now gives this instead of an NPE:
>
> 22:43 < [Coke]> rakudo: sub foo($a = $default, :$default = 42) { say
> $a }; foo
> 22:43 <+p6eval> rakudo 7f5c22: OUTPUT«Any()»
>
> Does this cover rakudo? do we need to mark this as an STD bug? (If so,
> same queue?)
The problem referred to by the ticket subject (the Null PMC access) has been
resolved, and so
should the ticket, I think.
It's still an issue that no parse error is flagged for the above program. But
it's not this issue. We
might even have a ticket for the non-NullPMC-related part of the problem in
Rakudo already.
The STD bug has since been fixed, so there's no reason to keep the ticket open
for that.
