nontail Bug continuations

[Stephen Weeks]

> > Ahh.  Thinking a little more, I wonder if we should treat
> > continuations exactly as we treat handlers, and have a case for
> > expressing that we don't care what the continuation is.
...
> But, maybe this isn't that hard.  We could change implementHandlers
> to implementCalls, and have it introduce those bogus bug and return
> continuations in the right place;

Sounds good to me.

> I think that the right invariant would be
> 
> handler = Handler.Handle h ==> cont = Cont.Cont l

Sounds right.

> If handler = Handler.None or Handler.CallerHandler, then we can make
> either a tail or a non-tail call.

Not sure what you mean here.

Here are the 9 cases that I see.

Cont	Handler		note
------	-------		----------------------------------------------------
None	None		tail call to nonreturning, nonraising function
None	Caller		tail call to nonreturning function that may raise
None	Some h		backend generates nontail stub
Caller	None		illegal, because the callee must restore the exnStack
Caller	Caller		tail call with no handler
Caller	Some h		backend generates nontail stub
Some l	None		nontail call to nonraising function
Some l	Caller		nontail call with no handler
Some l	Some h		nontail call with handler

Anyways, I'm putting this in (Monday), because I am still fighting
problems with the combination of remove-unused and shrink eliminating
handlers and continuations, the resulting tail calls then violate the
conditions needed for handler inference.  Hopefully, having this finer
information will let me weaken the conditions enough to let them pass.

As an aside, I was also thinking we should consider adding in "may
raise" and "may return" as part of SSA function types so that the cont
and handlers can be type checked.  Another alternative is to infer
"may raise" and "may return" as part of type checking, but I don't
like that because it involves a little bit of subtyping (where "can't
raise" <= "may raise").  A third possibility is to leave it out of the
interpass type checking, and just do a final check at the end, but
that makes debugging harder.