Multiple dispatch branch merged

[Allison Randal]

Will Coleda wrote:
> 
> In Parrot_integer_multi_cmp_DEFAULT, invoked with two TclInts, the
> original code:
> 
> const INTVAL selfint = SELF.get_integer();
> 
> seems to always set selfint to be 0, so the cmp is always -1, so islt
> is always true. Changing that line to:
> 
> const INTVAL selfint = VTABLE_get_integer(INTERP, SELF);
> 
> to mirror the following valueint line causes the problem to go away,
> and tcl's test suite continues past this test with no problem.
> 
> While the updated version is passed through to the .c with no changes,
> the original version is converted to:
> 
> pmc->real_self->vtable->get_integer(interp, pmc->real_self);
> 
> This change has no impact on t/pmc/integer.t, though I didn't run the
> full test suite against it.
> 
> Thoughts?

Well, that's just plain wrong. 'SELF.get_integer()' should do exactly 
the same thing as 'VTABLE_get_integer(INTERP, SELF)'.

I don't know when it was edited to do otherwise, but I've fixed it now. 
(I actually fixed it by deleting a few lines of code, because it was 
immediately followed by a few lines that did the right thing, which were 
never called because the 'SELF.other_method()' syntactic sugar was 
already transformed to the wrong thing. Which makes me suspect that the 
problem was an artifact of an incomplete change or bad merge on the PMC 
branch a while back. That's when we ripped out most of the real_self 
hackery.)


It looks like t/cmd_expr.t is getting a float-ish value where it expects 
an int-ish value (which could be a multi dispatch to the wrong variant). 
The failure in t/cmd_lsort.t appears to be unrelated to MMD (is that 
something you reported elsewhere? it seems familiar). Otherwise, all Tcl 
tests pass.

Thanks for the report,
Allison