id	summary	reporter	owner	description	type	status	priority	milestone	component	version	severity	resolution	keywords	cc	lang	patch	platform
1306	Various failures on bogus string used as argname (1.7)	Austin_Hastings		"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."	bug	new	normal		none	1.7.0	medium