#14111: strange error when using data families with levity polymorphism and unboxed sums and data families -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 13737 | Blocking: Related Tickets: #14457 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I think we have a way forward here, actually. First off, the problem isn't the main type-checker knot. The problem is the littler knot in `tcDataDefn` which retrieves the `tycon` from the future in order to, well, build the tycon. This tycon is used in three places: 1. In the `res_ty` passed to `tcConDecls`. This `res_ty` is, in turn, used in two places: a. In the call to `buildDataCon`, where it is used to set up the `dcOrigResTy` field of a `DataCon`. b. To do the result-type matching in `rejigConRes`. 2. As the `TyCon` passed to `tcConDecls`. That is used only when building the `DataCon`, so that a `DataCon` knows what `TyCon` it has come from. 3. In `mkNewTyConRhs`, so that a newtype `CoAxiom` knows what `TyCon` it has come from. Usages 1a, 2, and 3 absolutely need the final, correct, fully zonked `TyCon`. However, usage 1b does ''not''. Conveniently, usage 1b is the one causing us trouble. The solution is to use `kcLookupTcTyCon` to get the `TcTyCon` of interest and build the `res_ty` with un-knot-tied types. Pass this (as a new parameter) to `tcConDecls`. And away you go! Remaining to do: 1. Send all the stuff in `TyCon`s through Core Lint. I'm pretty sure we have some bits and pieces that are not fully zonked sneaking into `TyCon`s. For example, the `final_bndrs` in `tcDataDefn` look not to have ever been zonked (by `zonkTcTypeToType` or a friend). 2. Fix the errors that arise in (1). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14111#comment:20 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler