Ticket #2022 (closed bug: fixed)
Something borked with HLL mappings.
|Reported by:||coke||Owned by:||whiteknight|
partcl (old) is finally building again, but has dozens of test failures. Most of these seem to stem from invalid mappings, where parrot types are showing up instead of partcl types, and therefore the behavior is incorrect.
A very small example of tcl that exhibits this problem:
lrepeat 0.2 2
runtime/builtin/lrepeat.pir has a snippet:
.local int count count = shift argv
Which should be throwing an exception because 0.2 cannot be parsed as an int. However, it's getting the parrot behavior (truncated to 0), and then dying because it needs to be at least 1.
I don't see where it's losing the mapping information - a simple example loading tcl_group and runtime/tcllib.pir seems to give the correct information when boxing.
However, if I trace the code, I see the following:
# Calling sub 'tcl;_anon' # current instr.: '_main' pc 286 (src/tclsh.pir:158) *** switching to 0000 box P1, "0.2" P1=PMCNULL 0003 box P2, "2" P2=PMCNULL 0006 find_name P3, "&lrepeat" P3=PMCNULL 0009 if_null P3, 14 P3=Sub=PMC(0x10192ea58 pc:15719) 000c set_args PC3 (2), P1, P2 PC3=FixedIntegerArray=PMC(0x101ac1828) P1=String=PMC(0x101b4d6c8 Str:"0.2") P2=String=PMC(0x101b4d6f0 Str:"2") 0010 invokecc P3 P3=Sub=PMC(0x10192ea58 pc:15719)
if I check the types of those boxes, they are going to Integer, not TclInt.
The mappings for the 'tcl' HLL are covered by the definitions in the PMC files. the '_tcl' namespace maps them in PIR in runtime/tcllib.pir
Any help greatly appreciated - this is a big blocker for partcl.