[GHC] #13264: GHC panic with (->) generalization branch while compiling lens
GHC
ghc-devs at haskell.org
Fri Feb 10 21:27:10 UTC 2017
#13264: GHC panic with (->) generalization branch while compiling lens
-------------------------------------+-------------------------------------
Reporter: bgamari | Owner:
Type: bug | Status: new
Priority: normal | Milestone: 8.2.1
Component: Compiler | Version: 8.1
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
| Unknown/Multiple
Type of failure: None/Unknown | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Rev(s):
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by goldfire):
I see what's going on here.
`tcRepSplitTyConApp_maybe` rightly needs to know the `RuntimeRep` of the
argument type `([] |> <*>_N ->_N Sym {alzj}) a_alzd`. This `RuntimeRep` is
buried in the from-type of the coercion hole `{alzj}`. We can see in the
trace that `{alzj}` has from-type `k_agxC`. Except this has already been
filled in with `*`. So the problem is that we haven't zonked yet -- and
that's it.
`can_eq_nc'` works over non-flat (that is, unzonked) types and also over
flat (zonked) types. See `Note [Canonicalising equalities]` immediately
above. Your decomposition will work on the zonked types. So returning
`Nothing`, as you propose, works, as it forces `can_eq_nc'` to zonk and
then try again, succeeding. Is `tcRepSplitTyConApp_maybe` used anywhere
else? If so, returning `Nothing` in this case may be wrong.... except that
returning `Nothing` in this case makes `tcRepSplitTyConApp_maybe` strictly
more well-defined, so I suppose nothing can actually go wrong with this
change.
A detailed `Note` about the choice for `tcRepSplitTyConApp_maybe` not to
panic is called for.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13264#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list