[tclquadcode] errortest2-caller - now compilable, but test fails.

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

I'm vaguely remembering a recent conversation in which dkf mentioned
that errortest2-caller was commented out of demo.tcl because it caused
the compiler to throw a tantrum with a complaint about NOTHING
reaching a 'phi' operation.

I couldn't find it in either the mailing list archive or the tickets,
so it was probably in the Tcl'ers Chat or some such. I really don't
like to have problem reports only in an informal medium like that. I'm
not organized enough to keep track of them.

Once I remembered, I opened a ticket (e1f697c808) to track the problem.

It turns out that the issue is 'errortest2' once again. This procedure
always throws an error - it never returns any other way. That
behaviour was causing its return type to be a bald FAIL.

Continuing from my comments on the ticket:

The code that extracts the result is unreachable, because the 'jumpMaybe'
will always jump. But the compiler at present doesn't know this (there's
a fairly simple patch to cleanupNarrow that would optimize away the
'success'
branch in this case, if we want to take that route). That causes the result
of 'extractMaybe' to be Nothing.

The Nothing happens to end up in a phi. The node splitting has a check
that none of a phi's arguments is Nothing, because at one time, Nothing
indicated that the phi had an undefined value for one of its args. The
check appears to serve no useful purpose now.

After simply patching out the check, the code aborted in the code generator,
because there are numerous places where a bald FAIL or a Nothing value are
not acceptable. Adding the change to 'cleanupNarrow' made the code
compilable, but it started to fail at runtime with a nonsense value for
the return code.

I decided to work around the problem instead, and modified the type system
so that a procedure that always throws an exception has a type of FAIL
STRING
instead of FAIL. (I'd have preferred FAIL EMPTY, but that isn't implemented,
either.)

With that change, the code is compilable, but the test fails. The problem is
now that the '-errorline' is wrong in the options dictionary when the error
is caught. I have absolutely no idea without source-diving in the code
issuer
where the -errorline might be coming from.

I committed the workaround to a branch, 'kbk-bug-e1f697c808'.

If dkf is willing to tackle this one, I'll postpone delving into whatever
logic in the code issuer generates '-errorline'. I suspect that getting it
right will depend on getting information from the compiler front end that
isn't being passed. I'll gladly try to work on that, if I can get guidance
on what the code issuer needs.

Kevin