[perl #118067] [BUG] Null PMC access when calling .new on a subclass with a proto overriding the regular .new in Rakudo

[Carl Mäsak]

# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #118067]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=118067 >


<dagurval> r: class A is DateTime { proto method new($) {*} }; A.new
<camelia> rakudo 8d2ec9: OUTPUT«Not enough positional parameters
passed; got 1 but expected 2␤ in method new [...]»
<dagurval> r: class A is DateTime { proto method new($) {*} }; A.new(now)
<camelia> rakudo 8d2ec9: OUTPUT«Null PMC access in get_pmc_keyed()␤
in method new [...]»
<dagurval> that looks like implementation leak though
<gfldex> Null PMC is parroty way to say segfault
<masak> it's basically always wrong, unless you're doing weird MOP stuff.
* masak submits rakudobug
<arnsholt> I'd go so far as saying a Null PMC error is always a bug,
unless you happen to know it's not =)
<masak> r: class A is Any { proto method new($) {*} }; A.new(now)
<camelia> rakudo 8d2ec9: OUTPUT«Null PMC access in get_pmc_keyed()␤
in method new [...]»
<masak> ok, not related to DateTime. phew.
<dagurval> :)

[Christian Bartolomaeus via RT]

Just an update: There is no longer a Null PMC access error, but Rakudo complains about no matching signature:

$ perl6-m -e 'class A is Any { proto method new($) {*} }; A.new(now)'
Cannot call 'new'; none of these signatures match:
in block <unit> at -e:1

$ perl6-p -e 'class A is Any { proto method new($) {*} }; A.new(now)'
Cannot call 'new'; none of these signatures match:
in any at gen/parrot/BOOTSTRAP.nqp:1223
in method new at -e:1
in block <unit> at -e:1

$ perl6-j -e 'class A is Any { proto method new($) {*} }; A.new(now)'
Cannot call 'new'; none of these signatures match:
in any at gen/jvm/BOOTSTRAP.nqp:1216
in block <unit> at -e:1

[Carl Mäsak via RT]

First off, resolving ticket because the Null PMC access is gone, and that's what was reported.

Secondly, I think the above behavior is right. The error message comes from correctly finding and dispatching on the declared proto, and then correctly complaining that no declared multi (of which, as it happens, there are none) matches.