[parrot-tickets] [Parrot] #1306: Various failures on bogus string used as argname (1.7)

[Parrot]

#1306: Various failures on bogus string used as argname (1.7)
-----------------------------+----------------------------------------------
 Reporter:  Austin_Hastings  |        Type:  bug   
   Status:  new              |    Priority:  normal
Milestone:                   |   Component:  none  
  Version:  1.7.0            |    Severity:  medium
 Keywords:                   |        Lang:        
    Patch:                   |    Platform:        
-----------------------------+----------------------------------------------
 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.

-- 
Ticket URL: <https://trac.parrot.org/parrot/ticket/1306>
Parrot <https://trac.parrot.org/parrot/>
Parrot Development