#39: MMD calls the wrong sub
----------------------+-----------------------------------------------------
Reporter: rgrjr | Type: bug
Status: closed | Priority: normal
Milestone: | Component: core
Version: | Severity: medium
Resolution: invalid | Keywords:
Lang: | Patch:
Platform: |
----------------------+-----------------------------------------------------
Changes (by pmichaud):
* status: new => closed
* resolution: => invalid
Comment:
Replying to [comment:4 rgrjr]:
> I am still seeing the equivalent failure in r49616, but it turns out
> this is *not* an MMD failure; it fails due to bypassing MMD altogether.
> The real problem is that r33806 causes ".const 'Sub' ..." to behave
> differently: When given the name of a multisub in r33805, it loads the
> register with the multisub, but in r33806 it loads the first component
> sub, which (if that is not the appropriate method) makes it look like an
> incorrect dispatch. I can't imagine this change was intended.
Short answer: The change is intended and is working as designed -- the
test file is missing :subid markers that would enable it to work.
Longer answer: r33806 introduces a ":subid" flag for .sub declarations,
enabling each sub in a compilation unit to be uniquely identified by
something other than its "name", which is often not unique (as in the case
of :multi subs). The ".const 'Sub'" declaration now refers to :subid
instead of subroutine names. Prior to this change, it was often not
feasible to uniquely locate a given Sub PMC -- e.g. to handle lexical
scoping or attach other properties to a Sub.
If a .sub declaration doesn't provide a :subid flag, then the name of the
sub is used as its :subid. However, a given :subid is also required to be
unique within a compilation unit in order to work; the behavior of
multiple identical :subid's is undefined. (In the example given above, it
appears to have used the first component of the MultiSub.)
The solution is to make sure that each component of a :multi-declared Sub
also provides a unique :subid. If this is done, then each component can
be uniquely identified, and the MultiSub PMC will have the :subid
corresponding to the name. Then ".const 'Sub'" can be used to locate any
component of the MultiSub, leave the name to uniquely identify the
MultiSub itself:
{{{
pmich...@orange:~/parrot/trunk$ cat x.pir
.sub foo :multi(_, Integer) :subid('foo_Int')
.param pmc first
.param pmc second
print "(_, Int) method: "
print first
print ', '
print second
print "\n"
.end
.sub foo :multi(_, Float) :subid('foo_Float')
.param pmc first
.param pmc second
print "(_, Float) method: "
print first
print ', '
print second
print "\n"
.end
.sub main :main
say "Direct calls use the multi."
$P0 = new ['Float']
$P0 = 9.5
foo(1, $P0)
$P1 = new ['Integer']
$P1 = 3
foo(1, $P1)
say ".const 'Sub' should also use the multi."
.const 'Sub' foo_const = 'foo'
print "got "
print foo_const
print " type "
$S0 = typeof foo_const
say $S0
foo_const(1, $P0)
say "And so should get_global."
.local pmc foo_sub
foo_sub = get_global 'foo'
print "got "
print foo_sub
print " type "
$S0 = typeof foo_sub
say $S0
foo_sub(1, $P0)
.end
pmich...@orange:~/parrot/trunk$ ./parrot x.pir
Direct calls use the multi.
(_, Float) method: 1, 9.5
(_, Int) method: 1, 3
.const 'Sub' should also use the multi.
got foo type MultiSub
(_, Float) method: 1, 9.5
And so should get_global.
got foo type MultiSub
(_, Float) method: 1, 9.5
pmich...@orange:~/parrot/trunk$
}}}
Note that using the name of the MultiSub PMC as the :subid does run into
problems if there are multiple independent MultiSubs of the same name
within a compilation unit (as the :subid is again no longer unique) -- in
that case one has to look up the MultiSubs via their namespaces. However,
this is not different from the situation that existed prior to the
introduction of :subid, so it likely isn't a significant issue.
One change we could consider is to have .sub's declared :multi but lacking
a :subid flag automatically get a unique :subid (or otherwise don't
fallback to using the name of the sub as :subid). That would have avoided
the confusion that led to this ticket.
Based on the above, I'm marking this ticket as "invalid". If we want to
modify the handling of :subid for sub declarations marked :multi, let's
open a new ticket.
Thanks!
Pm
--
Ticket URL: <https://trac.parrot.org/parrot/ticket/39#comment:5>
Parrot <https://trac.parrot.org/parrot/>
Parrot Development
_______________________________________________
parrot-tickets mailing list
[email protected]
http://lists.parrot.org/mailman/listinfo/parrot-tickets
