Ticket #1306 (new bug)

Opened 5 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.

Note: See TracTickets for help on using tickets.