[MLton-devel] Problem with -exn-history true

[Stephen Weeks]

> On the other hand, the type-checker doesn't even look at unreachable
> blocks.  I wouldn't argue that that means that we're free to violate
> scoping or SSA conditions in unreachable blocks.  

I guess I would have to.  :-)

> In any event, other "bad things" can be going on in unreachable blocks.

Yeah.  It would be nice to just rule out unreachable blocks in the
type checker.

> > As I recall, the shrinker does for exactly the reason
> > you mention -- the DFS has to make a decision too early and I couldn't
> > figure out another cheap way to enforce it.
> 
> Are there other scenarios besides HandlerPop that will result in the
> shrinker holding onto unreachable blocks?

It's not obvious from a perusal of the shrinker, but I don't think so.
Once we get rid of HandlerPop, we should investigate this issue.

It occurs to me that there is another approach that we could try now.
We could change check scopes so that it doesn't insist that the label
on a Handler{Push,Pop} be defined, but that it still checks the
handler on nontail calls.  Then the shrinker wouldn't need to worry
about forcing to keep the label around when it sees a HandlerPop.  We
could then make a minor change to any pass that looks at
HandlerPush/Pop (like the backend) and prefix them with a pass that
eliminates all such useless HandlerPush/Pops.  This approach might be
more in keeping with thinking of HandlerPush/Pop as a hint.

If we do that, then we could tackle the question now of whether or not
there are any other cases where the shrinker holds on to unreachable
blocks.


-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel