[GHC] #8022: Outdated documentation for the -fwarn-lazy-unlifted-bindings warning

[GHC]

#8022: Outdated documentation for the -fwarn-lazy-unlifted-bindings warning
-------------------------------------+------------------------------------
        Reporter:  asr               |            Owner:  thoughtpolice
            Type:  bug               |           Status:  new
        Priority:  highest           |        Milestone:  7.8.1
       Component:  Documentation     |          Version:  7.6.3
      Resolution:                    |         Keywords:
Operating System:  Unknown/Multiple  |     Architecture:  Unknown/Multiple
 Type of failure:  None/Unknown      |       Difficulty:  Unknown
       Test Case:                    |       Blocked By:
        Blocking:                    |  Related Tickets:
-------------------------------------+------------------------------------

Comment (by thoughtpolice):

 OK, a few things:

 First, I believe there is a bug in the implementation of the warning in
 HEAD, such that it fails on some cases anyway. Like so:

 {{{
 f1 :: Int# -> ByteArray# -> Int#
 f1 i ba =
   let !v = indexIntArray# ba i
   in v
 }}}

 this bug incorrectly trips a warning in `integer-gmp` which does something
 very similar. I believe the fix here is, in
 `TcBinds.lhs/checkStrictBinds`:

 {{{
     ; warnTc (warnUnlifted && not bang_pat && lifted_pat)
           ....
 }}}

 should be:

 {{{
     ; when lifted_pat $
         warnTc (warnUnlifted && not bang_pat)
             ....
 }}}

 This is because in the above case, `lifted_pat` for `v` is false, as it's
 obviously not a lifted pattern, it's just a variable binder. However, that
 means that `(warnUnlifted && not bang_pat && lifted_pat)` overall is
 false, which causes `checkTc` to get angry. Instead we only want to ensure
 a bang pattern is there ''if'' `lifted_pat` is true.

 So, with that fixed, it fails in the stage2 build. Alex-3.0.5 seems fine
 and looks like it correctly generates lexers we can deal. But
 happy-1.18.10 does not:

 {{{
 make -r --no-print-directory -f ghc.mk phase=final all
   HC [stage 1] compiler/stage2/build/Parser.o

 templates/GenericTemplate.hs:212:14:
     Pattern bindings containing unlifted types should use an outermost
 bang pattern:
       (sts1@((HappyCons (st1@(action)) (_))))
         = happyDrop k (HappyCons (st) (sts))
     In an equation for ‛happyMonadReduce’:
         happyMonadReduce k nt fn j tk st sts stk
           = happyThen1
               (fn stk tk)
               (\ r -> happyGoto nt j tk st1 sts1 (r `HappyStk` drop_stk))
           where
               (sts1@((HappyCons (st1@(action)) (_))))
                 = happyDrop k (HappyCons (st) (sts))
               drop_stk = happyDropStk k stk

 templates/GenericTemplate.hs:219:14:
     Pattern bindings containing unlifted types should use an outermost
 bang pattern:
       (sts1@((HappyCons (st1@(action)) (_))))
         = happyDrop k (HappyCons (st) (sts))
     In an equation for ‛happyMonad2Reduce’:
         happyMonad2Reduce k nt fn j tk st sts stk
           = happyThen1
               (fn stk tk)
               (\ r -> happyNewToken new_state sts1 (r `HappyStk`
 drop_stk))
           where
               (sts1@((HappyCons (st1@(action)) (_))))
                 = happyDrop k (HappyCons (st) (sts))
               drop_stk = happyDropStk k stk
               (off) = indexShortOffAddr happyGotoOffsets st1
               (off_i) = (off +# nt)
               ....
 }}}

 where `GenericTemplate.hs` is included in all generated parsers. The error
 is correct in this case I believe, and the binding should be strictified;
 the defn is:

 {{{
 #define FAST_INT Happy_GHC_Exts.Int#
 ...
 data Happy_IntList = HappyCons FAST_INT Happy_IntList
 ...
 }}}

 So we would need to make another point-release of `happy` that is
 compatible with GHC 7.8.1.

 SimonM, could you please weigh in here? Do you think we should still keep
 this warning since you closed #4304? I can contribute a patch to `happy`
 to fix this (it's relatively trivial,) but unfortunately it seems the ship
 has sailed on the platform versions of Happy working. OTOH, once you have
 the platform it is fairly easy to install a new version of Happy.

 Regardless of the decision to punt this or not for 7.8, I think the above
 misbehavior should still be fixed.

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