From @masak

<gfldex> r​: https://gist.github.com/2518066
<p6eval> rakudo a25e7d​: OUTPUT«Null PMC access in find_method('slots') [...]
<jnthn> Eek. That looks bad.
* gfldex tries to find the line that triggers Null PMC
<gfldex> i don't think i can golf it much
* masak tries, then
<moritz> the weird thing is, it explodes while invoking method pressed
<gfldex> yes and it calls the wrong handle_call
<moritz> but nothing seems to override its invoke/postcircumfix​:<( )>
<jnthn> That &wrap call means you are wrapping with the proto.
<jnthn> And that trait_mod along with the multi, proto etc. has to be
compiled "just in time" since the trait_mod runs at BEGIN time.
<moritz> oh, erm, does .wrap on a method work at all?
<jnthn> Yes, .wrap is defined on Routine.
<gfldex> my guess is that the dispatcher is calling the wrong
handle_call with a capture that is empty but not
<jnthn> But a $m should be in scope and not null in either case.
<gfldex> well, $m seamt to be null
<jnthn> Yeah, it shouldn't be.
<gfldex> i added say $m.elems; and it explodes
<jnthn> I suspect it's some kind of lexical chaining issue.
<jnthn> OK, it's the multi that is somehow to blame
<masak> yeah, that feels like a lexpad outer chain corruption.
<jnthn> https://gist.github.com/2518209 gets much further
<jnthn> masak​: Yeah, something along those lines.
* masak submits rakudobug
<jnthn> Now we know what it is, it's probably very golfable.
<moritz> adding a proto also gets much further
<jnthn> moritz​: oh...
<jnthn> moritz++
<jnthn> https://gist.github.com/2518235
<jnthn> gfldex​: ^^
<gfldex> that makes sense
<gfldex> but the compiler should be a bit more concerned without the proto :)
<gfldex> but it still doesnt work how i would like it to
<masak> r​: role R { has $.x }; multi trait_mod​:<is>($m, :$a!) { $m
does R; multi y(|$) { say $m }; $m.wrap(&y) }; (class { method z is a
{} }).z;
<p6eval> rakudo a25e7d​: OUTPUT«Null PMC access in find_method('gist') [...]
<masak> golf'd. :)
<jnthn> r​: multi trait_mod​:<is>($m, :$a!) { proto y(|$) { * }; multi
y(|$) { say $m }; $m.wrap(&y) }; (class { method z is a {} }).z;
<p6eval> rakudo a25e7d​: OUTPUT«z␤»
<jnthn> So it's everything to do with the auto-generated proto.
<masak> r​: multi trait_mod​:<is>($m, :$a!) { multi y(|$) { say $m };
$m.wrap(&y) }; sub foo is a {}; foo
<p6eval> rakudo a25e7d​: OUTPUT«Null PMC access in find_method('gist') [...]
<masak> yes. it's the auto-gen proto's the culprit.
* masak concentrates this down into a simple bug report
<jnthn> Derived dispatchers too if the patch I'm trying at the moment works.
<jnthn> Yeah, I think I have a patch locally.

From @masak

<dalek> rakudo/nom​: 6c9661f | jnthn++ | src/Perl6/Actions.pm​:
<dalek> rakudo/nom​: Fix a lexical handling bug in installation of auto-
generated protos and derived dispatchers. gfldex++ for reporting,
moritz++ for realizing it was about protos.
<dalek> rakudo/nom​: review​:
rakudo/rakudo@6c9661f5d0
<jnthn> masak​: ^^ means the ticket can be tagged testneeded.
<gfldex> that was one fast bugfix :)
<masak> jnthn​: I'm on it.

Tagging testneeded.

From [Unknown Contact. See original ticket]

<dalek> rakudo/nom​: 6c9661f | jnthn++ | src/Perl6/Actions.pm​:
<dalek> rakudo/nom​: Fix a lexical handling bug in installation of auto-
generated protos and derived dispatchers. gfldex++ for reporting,
moritz++ for realizing it was about protos.
<dalek> rakudo/nom​: review​:
rakudo/rakudo@6c9661f5d0
<jnthn> masak​: ^^ means the ticket can be tagged testneeded.
<gfldex> that was one fast bugfix :)
<masak> jnthn​: I'm on it.

Tagging testneeded.

@masak - Status changed from 'new' to 'open'

From @kyleha

This is tested in S14-traits/routines.t

@kyleha - Status changed from 'open' to 'resolved'