Ticket #1306 (new bug)
Opened 12 years ago
Various failures on bogus string used as argname (1.7)
Reported by: | Austin_Hastings | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | none | Version: | 1.7.0 |
Severity: | medium | Keywords: | |
Cc: | Language: | ||
Patch status: | Platform: |
Description
I've got the following test setup (using Kakapo libs):
method test_initializer() { my $obj := Kakapo::Test::Aclass.new(:a('albatross'), :b('byzantine'), :c('chrysanthemum')); self.assert_that('test object.a', $obj.a, is("albatross")); self.assert_that('test object.b', $obj.b, is("byzantine")); } module Kakapo::Test::Aclass; use( 'P6object'); extends( 'Kakapo::Object'); has( 'b a');
The upshot of this is that accessor methods called Kakapo::Test::Aclass::a() and ...b() are mechanically generated and compiled (using plain old NQP+PIR in 1.7).
The Kakapo::Object base class contains, among other things, this code:
method new(*@pos, *%named) { say("New!"); Dumper::DUMP_(self, @pos, %named); my $class := Opcode::getattribute(self.HOW, 'parrotclass'); my $new_object := Opcode::new($class); # NB: I'm not flattening the params, because that forces # everybody to do call_method or in-line pir to pass # along flat args. $new_object.init_(@pos, %named); return $new_object; }
As far as I can tell, the standard P6object functionality is working. The class is set up by Kakapo as a child of Kakapo::Object, and the Kakapo::Object::new() method is being called. Here is the output:
New class: Aclass parent: Kakapo::Object Done New! "$VAR" => ResizablePMCArray (size:3) [ undef, ResizablePMCArray (size:0) [ ], Hash { "(0x0011)" => "albatross", "Global" => "byzantine", "new" => "chrysanthemum" } ] No accessor defined for attribute 'Global'. current instr.: 'parrot;Opcode;die' pc 28248 (library/kakapo_test.pir:11177) called from Sub 'parrot;Kakapo;Object;_block307' pc 8792 (library/kakapo_test.pir:3423) called from Sub 'parrot;Kakapo;Object;_block285' pc 8745 (library/kakapo_test.pir:3403) called from Sub 'parrot;Kakapo;Object;init_' pc 8620 (library/kakapo_test.pir:3347) called from Sub 'parrot;Kakapo;Object;new' pc 9090 (library/kakapo_test.pir:3531) called from Sub 'parrot;Kakapo;Test;Class;Attributes;test_initializer' pc 462 (t/Classes/Attributes.pir:128)
Until today, the failure was not "No accessor defined" but rather an assert failure on an invalid string.
This is the generated PIR for the new call:
.lex "self", self get_hll_global $P50, ["Kakapo";"Test"], "Aclass" $P51 = $P50."new"("albatross" :named("a"), "byzantine" :named("b"), "chrysanthemum" :named("c")) .lex "$obj", $P51
I don't have a good steps-to-reproduce, because the Kakapo library is somewhat large, and a bit of a nest of snakes as far as isolating behaviors.
What's more, the aberrant behavior appears to be related somehow to calling with named parameters. Since 1.8 is the pcc refactor release, I think I can predict the response of the dev team. But I wanted to document this now, just in case.