Fix two obscure bugs in rule matching
authorSimon Peyton Jones <simonpj@microsoft.com>
Wed, 21 Mar 2018 17:25:23 +0000 (17:25 +0000)
committerSimon Peyton Jones <simonpj@microsoft.com>
Wed, 21 Mar 2018 17:34:52 +0000 (17:34 +0000)
commit3446cee05e08d78033e141fa46d4de6929542cbb
tree3bb57ae3ef5454617285cc1bf7fe5bac894b5c55
parent411a97e2c0083529b4259d0cad8f453bae110dee
Fix two obscure bugs in rule matching

This patch fixes Trac #14777, a compiler crash.

There were actually two bugs.

1. In Rules.matchN, I was (consciously) not rename the template binders
   of the rule. Sadly, in rare cases an accidental coincidence of
   uniques could mean that a term variable was mapped to a type
   variable, utterly bogusly.  See "Historical note" in
   Note [Cloning the template binders] in Rules.

   This was hard to find, but easy to fix.

2. The fix to (1) showed up a bug in Unify.hs.  The test in
   Unify.tvBindFlag was previously using the domain of the RnEnv2
   to detect locally-bound variables (e.g. when unifying under
   a forall).  That's fine when teh RnEnv2 starts empty, as it
   does in most entry points.  But the tcMatchTyKisX entry point,
   used from the rule matcher, passes in a non-empty RnEnv2 (by
   design).  Now the domain of the RnEnv doesn't idenfity those
   locally-bound variables any more :-(.

   Solution: extend UmEnv with a new field um_skols, to capture
   the skolems directly.  Simple, easy, works.
compiler/specialise/Rules.hs
compiler/types/Unify.hs