[GHC] #13233: typePrimRep panic while compiling GHC with profiling

[GHC]

#13233: typePrimRep panic while compiling GHC with profiling
-------------------------------------+-------------------------------------
        Reporter:  bgamari           |                Owner:  goldfire
            Type:  bug               |               Status:  merge
        Priority:  highest           |            Milestone:  8.2.1
       Component:  Compiler          |              Version:  8.0.1
      Resolution:                    |             Keywords:
                                     |  LevityPolymorphism
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  Compile-time      |            Test Case:
  crash or panic                     |  codeGen/should_fail/T13233
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):  Phab:D3490
       Wiki Page:                    |
-------------------------------------+-------------------------------------
Changes (by goldfire):

 * status:  new => merge
 * testcase:   => codeGen/should_fail/T13233


Comment:

 The patch Ben just committed fixes this bug, but in a stopgap manner. We
 can do better.

 Please merge this patch, but then reopen the ticket after merging.

 (Below are mostly notes to self.)

 There are two separate problems:
     1. How to ascertain whether or not a primop is saturated during
 desugaring (or, possibly, earlier). Simon and I once thought that we could
 do this in the desugarer by decomposing nested `HsApp`s, using a little
 stack data type to denote all the different ways a function could be
 applied (`HsApp`, `HsWrap` with the right wrapper, sections, tuple-
 sections, `HsTypeApp`, maybe more) uncovering what the function was
 underneath, and then checking how many parameters are supplied. But now, I
 think it's much better to do this in the type-checker, especially because
 the type-checker already decomposes nested `HsApp`s. (See `TcExpr.tcApp`.)
 When it discovers what the function is, it can check whether the function
 is a `hasNoBinding` primop. If so, it can eta-expand as necessary (but
 only if necessary) and use a new piece of `HsSyn` to denote a saturated
 primop. (It will be a new invariant that no unsaturated primop passes the
 type-checker.) This seems better than redoing the stack type in the
 desugarer. The original problem in #13233 was around levity polymorphism.
 If we make this change in the type checker, then the existing levity
 polymorphism checks should just work. We'll have to be careful to make the
 `HsSyn` structure printable in the way a user expects, so that the levity-
 polymorphism error message doesn't talk about an argument the user didn't
 write.
     2. How to make sure that saturated primops stay that way in Core. This
 would be a new check in Lint as well as new checks on any code that does
 eta-contraction. It has been suggested that levity-polymorphic primops
 desugar to a family of levity-monomorphic primops. This surely would work,
 but there doesn't seem to be benefit over a plan simply to keep primops
 eta-expanded always. Then, there's no worry about eta-contracting levity-
 polymorphic arguments.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13233#comment:40>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler