[tclquadcode] Details, details, details.

[Kevin K. <kev...@gm...>]

I tried to make a little more progress on {*} today and got sidetracked.

It began when I wanted to see whether 'expandDrop' was actually being
translated adequately. My existing cases didn't actually generate
'expandDrop', so I added expandtest::test5 to make sure we had one.

In the course of trying to debug that, I wound up doing a major
refactoring of 'bytecode-to-quads' and the associated procedures, to
get them out of the global namespace and into ::quadcode::transformer.
That, in turn, took some debugging of its own.

Once I had that working on trunk, I merged it into the 'expand'
branch, and tried to run the tester, without the 'expandtest'
procedures, and it promptly crashed!

That came down into a strange change that seemed to be piggybacked
onto the commit that added 'verifyList'. Coming along for the ride was
a change to the 'return' instruction in tcl.list.length and
tcl.dict.size, and that caused the return value not to match the
declared return type of those two procedures.

OK, so I committed that, and then tried to compile the
'expandtest::test5' procedure again - and found that the 'expandDrop'
instructions were in 'unreachable' code. The code is 'unreachable'
because 'invoke' doesn't yet handle return codes other than OK and
ERROR.

So that bit is going to go untested for a while. I think we're now
smart enough about exception ranges and about the results of
procedures that it wouldn't be impossible to add the stuff - now that
the bytecode compiler adjusts stack depth properly! Essentially, we
would need to track

   (1) whether a compiled procedure can return an unusual result
(BREAK, CONTINUE, RETURN, or a funny exception number).

   (2) whether an 'invoke' has a loop exception range inside the
innermost catch.

If we're invoking a procedure that could return BREAK or CONTINUE,
we'd need to emit checks for those to go to the appropriate branch in
the loop exception range. If it could return RETURN or an odd code, we
would need to emit code to handle that.

I think it's all doable, but it's obviously considerably less urgent -
[return -code] is generally pretty obscure.

I'll open a ticket for loop exceptions coming out of INVOKE, but right
now I'm being called away.