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

#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
participants (1)
-
GHC