December 2017 - ghc-tickets

[GHC] #13547: ghc: panic! StgCmmEnv: variable not found
by GHC 22 May '18

22 May '18

#13547: ghc: panic! StgCmmEnv: variable not found -------------------------------------+------------------------------------- Reporter: cipher1024 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (CodeGen) | Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: 10158 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When building with `stack build --resolver lts-7.20` and `stack build --resolver lts-8.8`, i.e. with ghc-8.0.1 and ghc-8.0.2 and {{{ [37 of 60] Compiling Document.Phase.Proofs ( src/Document/Phase/Proofs.hs, .stack- work/dist/x86_64-osx/Cabal-1.24.0.0/build/Document/Phase/Proofs.o ) <no location info>: error: ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-apple-darwin): StgCmmEnv: variable not found $dTypeable_aZSM local binds for: $sunionWith_$sunionWithKey $sfromList1 $sfromList3 $sfromList $s$fOrdEither $s$fMonadReaderrReaderT $s$fIsTupleconstrIdentity $s$fIsTupleconstr(,,,,) $s$fIsTupleconstr(,,,) $s$fIsTupleconstr(,,) $s$fIsTupleconstr(,,)2 $s$fIsTupleconstr(,)1 $s$fIsTupleconstr(,) $s$fIsTupleconstr(,)2 $s$fHasMachineP2p $fNFDataEventRefA $fMonoidEventRefA $fGenericEventRefA $wmake_phase4 make_phase1 $wpoly_go10 make_phase2 make_phase3 make_phase5 $fNFDataEventRefA4 $fNFDataEventRefA2 $stypeRep#78 $swithCommand8 $stypeRep#54 $swithCommand5 $stypeRep#11 $swithCommand2 $stypeRep#74 $stypeRep#81 $stypeRep#15 $stypeRep#20 $stypeRep#79 $stypeRep#80 $stypeRep#70 $stypeRep#75 $stypeRep#58 $stypeRep#66 $stypeRep#71 $stypeRep#62 $stypeRep#8 $stypeRep#67 $stypeRep#63 $stypeRep#59 $stypeRep#50 $stypeRep#55 $stypeRep#38 $stypeRep#46 $stypeRep#51 $stypeRep#42 $stypeRep#47 $stypeRep#43 $stypeRep#34 $stypeRep#39 $stypeRep#31 $stypeRep#35 $stypeRep#28 $stypeRep#24 $stypeRep#25 $stypeRep#21 $stypeRep#3 $stypeRep#16 $stypeRep#7 $stypeRep#12 $stypeRep#2 $smakeCell8 $smakeCell7 $smakeCell40 $smakeCell39 $smakeCell36 $smakeCell35 $smakeCell32 $smakeCell31 $smakeCell4 $smakeCell28 $smakeCell27 $smakeCell24 $smakeCell23 $smakeCell3 $smakeCell20 $smakeCell19 $smakeCell16 $smakeCell15 $smakeCell12 $smakeCell11 $wpoly_go5 $wgo5 $sfromList_go5 $wpoly_go2 $sfromList2 $s$fOrd(,) $sfromList_fromList'1 $wpoly_go1 $s$fEqEither $s$fOrdEither_$s$fOrdEither_$cp1Ord $s$fEq(,) $s$fOrd(,)_$s$fOrd(,)_$cp1Ord $s$fMonadRWST $s$fMonadReaderrReaderT1 $s$fMonadReaderT $s$fApplicativeReaderT $s$fMonadReaderT_$s$fMonadReaderT_$cfail $s$fMonadReaderT_$s$fMonadReaderT_$c>> $s$fMonadReaderT_$s$fMonadReaderT_$c>>= $s$fMonadReaderT_$s$fMonadReaderT_$cp1Monad $s$fMonadRWST_$s$fMonadRWST_$cfail $s$fMonadRWST_$s$fMonadRWST_$c>> $s$fMonadRWST_$s$fMonadRWST_$c>>= $s$fMonadRWST_$s$fMonadRWST_$cp1Monad $s$fIsTupleconstr(,,,,)_$s$fLatexArg[] $s$fIsTupleconstr(,,,,)1 $s$fIsTupleconstr(,,,)_$s$fLatexArg[] $s$fIsTupleconstr(,,,)_irred2 $s$fIsTupleconstr(,,)_$s$fLatexArg[] $s$fIsTupleconstr(,,)_$dLatexArgFromString $s$fIsTupleconstr(,,)_$s$fLatexArgFromStringConc $s$fIsTupleconstr(,,)_irred1 $s$fIsTupleconstr(,,)_$s$fLatexArgNonEmpty $s$fIsTupleconstr(,,)1 $s$fIsTupleconstr(,)3 $s$fHasMachineP1p $s$fHasMachineP2p1 $s$fHasMachineP2p2 $s$fHasMachineP2p3 $s$fHasMachineP2p4 $s$fHasMachineP2p5 $s$fHasMachineP2p6 $s$fHasMachineP1p_$s$fHasMachineP1p_$cp5HasMachineP1 $s$fHasMachineP1p_$s$fHasMachineP1p_$cp4HasMachineP1 $s$fHasMachineP1p_$s$fHasMachineP1p_$cp3HasMachineP1 $s$fHasMachineP1p_$s$fHasMachineP1p_$cp2HasMachineP1 $s$fHasMachineP1p_$s$fHasMachineP1p_$cp1HasMachineP1 $s$fEq(,)_$dEq1 $s$fEq(,)_$dEq $s$fApplicativeReaderT_$s$fFunctorReaderT_$c<$ $s$fApplicativeReaderT_$s$fFunctorReaderT_$cfmap $s$fApplicativeReaderT_$s$fFunctorReaderT $s$fApplicativeRWST $s$fApplicativeReaderT_$dApplicative $s$fApplicativeReaderT_$s$fApplicativeReaderT_$c<*> $s$fApplicativeReaderT_$s$fMonadReaderT_$creturn $s$fApplicativeReaderT_$s$fApplicativeReaderT_$cp1Applicative $s$fApplicativeRWST_$dFunctor $s$fApplicativeRWST_$s$fApplicativeRWST_$c<*> $s$fApplicativeRWST_$s$fApplicativeRWST_$cpure $s$fApplicativeRWST_$s$fApplicativeRWST_$cp1Applicative $fNFDataEventRefA1 $fNFDataEventRefA3 $w$dNFData2 $w$dNFData1 $w$dNFData $fNFDataEventRefA_$crnf $wgo $fMonoidEventRefA_$cmconcat $fMonoidEventRefA_$cmappend $fMonoidEventRefA_$cmempty $fGenericEventRefA_$cto $fGenericEventRefA_$cfrom make_phase4 ruleProxies_rSKY refinement_parser_rSL2 $w$smiddle $w$sgreater $sfilterGt1 $sfilterLt1 $sinsert_$sgo10 $sinsert_$sgo5 $sleadsTo1 $wpoly_go3 $wpoly_go4 $slookup5 $slookup7 $smakeCell2 $smakeCell6 $smakeCell10 $smakeCell14 $smakeCell18 $smakeCell22 $smakeCell26 $smakeCell30 $smakeCell34 $smakeCell38 $wpoly_go6 $wpoly_go7 $wpoly_go8 $sshowStringP1 $strim1 $strim3 $sunions1 $sunless_eta $swithCommand1 $swithCommand4 $swithCommand7 lvl_r2714 lvl1_r2715 go_r2716 $wgo1_r2717 lvl2_r2718 lvl3_r2719 lvl4_r271a lvl5_r271b lvl6_r271c lvl7_r271d lvl8_r271e lvl9_r271f lvl10_r271g lvl11_r271h lvl12_r271i lvl13_r271j lvl14_r271k lvl15_r271l lvl16_r271m lvl17_r271n lvl18_r271o lvl19_r271p lvl20_r271q lvl21_r271r lvl22_r271s lvl23_r271t lvl24_r271u lvl25_r271v lvl26_r271w lvl27_r271x lvl28_r271y lvl29_r271z lvl30_r271A lvl31_r271B lvl32_r271C lvl33_r271D lvl34_r271E lvl35_r271F lvl36_r271G lvl37_r271H lvl38_r271I lvl39_r271J lvl40_r271K lvl49_r2723 lvl50_r2724 lvl51_r2725 lvl52_r2726 lvl53_r2727 lvl54_r2728 lvl55_r2729 lvl56_r272a lvl57_r272b lvl58_r272c lvl59_r272d lvl60_r272e lvl61_r272f lvl62_r272g lvl63_r272h lvl64_r272i lvl65_r272j lvl66_r272k lvl67_r272l lvl68_r272m lvl69_r272n lvl70_r272o lvl71_r272p lvl72_r272q $s$fApplicativeRWST_$c<*>_r272u $s$fApplicativeRWST_$cpure_r272v lvl74_r272w lvl75_r272x lvl76_r272y $s$fMonadRWST_$c>>_r272z $s$fMonadRWST_$cfail_r272A $s$fMonadRWST_$c>>=_r272B lvl77_r272C lvl78_r272D lvl79_r272E lvl80_r272F lvl81_r272G lvl82_r272H $slesser1_r272S lvl88_r272T lvl89_r272U $wcreate_r272V lvl90_r272W m2_r272X $s$fMonadReaderT_$c>>_r272Y $s$fMonadReaderT_$c>>=_r272Z go10_r2730 $wpoly_create_r2731 lvl91_r2732 lvl92_r2733 lvl93_r2734 lvl94_r2735 lvl95_r2736 lvl96_r2737 lvl97_r2738 lvl98_r2739 lvl99_r273a lvl100_r273b lvl101_r273c lvl102_r273d lvl103_r273e lvl104_r273f lvl105_r273g lvl106_r273h lvl107_r273i lvl108_r273j lvl109_r273k lvl110_r273l lvl111_r273m lvl112_r273n lvl113_r273o lvl114_r273p lvl115_r273q lvl116_r273r lvl117_r273s lvl118_r273t lvl119_r273u lvl120_r273v lvl121_r273w lvl122_r273x lvl123_r273y lvl124_r273z $wpoly_create1_r273A lvl125_r273B lvl126_r273C lvl127_r273D lvl128_r273E lvl129_r273F lvl130_r273G lvl131_r273H lvl132_r273I lvl133_r273J lvl134_r273K lvl135_r273L $wlvl_r273M lvl136_r273N $wlvl1_r273O lvl137_r273P $wlvl2_r273Q lvl138_r273R $wlvl3_r273S lvl139_r273T $wlvl4_r273U lvl140_r273V $wlvl5_r273W lvl141_r273X $wlvl6_r273Y lvl142_r273Z lvl143_r2740 lvl144_r2741 lvl145_r2742 lvl146_r2743 lvl147_r2744 lvl148_r2745 lvl149_r2746 lvl150_r2747 lvl151_r2748 lvl152_r2749 lvl153_r274a lvl154_r274b $s$fFunctorReaderT_$cfmap_r274c $s$fFunctorReaderT_$c<$_r274d lvl155_r274e lvl156_r274f $s$fApplicativeReaderT_$c<*>_r274g $s$fMonadReaderT_$creturn_r274h $s$fMonadReaderT_$cfail_r274i lvl157_r274j lvl158_r274k lvl159_r274l lvl160_r274m $d~_r274n lvl161_r274p lvl162_r274q lvl163_r274s lvl164_r274t lvl165_r274v lvl166_r274w lvl167_r274y lvl168_r274z lvl169_r274B lvl170_r274C lvl171_r274E lvl172_r274F lvl173_r274H lvl174_r274I lvl175_r274K lvl176_r274L lvl177_r274N lvl178_r274O lvl179_r274Q lvl180_r274R lvl181_r274T lvl182_r274U lvl183_r274V lvl184_r274W lvl185_r274X lvl186_r274Y lvl187_r274Z lvl188_r2750 lvl189_r2751 lvl190_r2752 lvl191_r2753 lvl192_r2754 lvl193_r2755 lvl194_r2756 lvl195_r2757 lvl196_r2758 lvl197_r2759 lvl198_r275a lvl199_r275b lvl200_r275c lvl201_r275d lvl202_r275e lvl203_r275f lvl204_r275g lvl205_r275h lvl206_r275i lvl207_r275j lvl208_r275k lvl209_r275l lvl210_r275m lvl211_r275n lvl212_r275o lvl213_r275p lvl214_r275q lvl215_r275r lvl216_r275s lvl217_r275t lvl218_r275u lvl219_r275v lvl220_r275w ww1_r275x ww2_r275y lvl221_r275z ww3_r275A lvl222_r275B pre_r275C x_s27MP eta_s27MQ eta1_s27MR ds_s27MS ds1_s27MT ds2_s27MU ds3_s27MV goal_s27MW prxy'_s27MX sat_s27MY Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13547> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 38

[GHC] #14370: non-deferred typed hole despite -fdefer-typed-holes
by GHC 21 May '18

21 May '18

#14370: non-deferred typed hole despite -fdefer-typed-holes -------------------------------------+------------------------------------- Reporter: int-e | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following ghci session. {{{ GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Prelude> :set -fdefer-typed-holes -Wno-typed-holes Prelude> :set -fdefer-out-of-scope-variables -Wno-deferred-out-of-scope- variables Prelude> let x = [_]; y = [r] Prelude> (length x, length y) (1,1) Prelude> length [_] <interactive>:4:9: error: • Found hole: _ :: a0 Where: ‘a0’ is an ambiguous type variable • In the expression: _ In the first argument of ‘length’, namely ‘[_]’ In the expression: length [_] • Relevant bindings include it :: Int (bound at <interactive>:4:1) Prelude> length [r] 1 }}} Why does the `length [_]` expression produce a type error immediately instead of being deferred? (I've asked the same question in #14367 but this looks like a real bug.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14370> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14325: Erroneous program emits no errors
by GHC 21 May '18

21 May '18

#14325: Erroneous program emits no errors -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider this (which arose in #14323): {{{ class (a~b) => C a b foo :: C a b => a -> b foo x = x hm3 :: C (f b) b => b -> f b hm3 x = foo x }}} With GHC 8.2 it compiles without error, but it definitely has a type error; try `-ddump-simpl`: {{{ hm3 :: forall (f :: * -> *) b. C (f b) b => b -> f b [GblId, Arity=2, Str=<L,U><L,U>x] hm3 = \ (@ (f_a126 :: * -> *)) (@ b_a127) ($dC_a129 :: C (f_a126 b_a127) b_a127) _ [Occ=Dead] -> case GHC.Types.HEq_sc @ * @ * @ (f_a126 b_a127) @ b_a127 ($dC_a129 `cast` ((T14323.N:C[0] ; Data.Type.Equality.N:~[0] <*>_N) <f_a126 b_a127>_N <b_a127>_N :: (C (f_a126 b_a127) b_a127 :: Constraint) ~R# ((f_a126 b_a127 :: *) ~~ (b_a127 :: *) :: Constraint))) of cobox_a12p { __DEFAULT -> case Control.Exception.Base.typeError @ 'GHC.Types.LiftedRep @ (C b_a127 (f_a126 b_a127)) "T14323.hs:28:9: error:\n\ \ \\226\\128\\162 Could not deduce (C b (f b)) arising from a use of \\226\\128\\152foo\\226\\128\\153\n\ \ from the context: C (f b) b\n\ \ bound by the type signature for:\n\ \ hm3 :: forall (f :: * -> *) b. C (f b) b => b -> f b\n\ \ at T14323.hs:27:1-28\n\ \ \\226\\128\\162 In the expression: foo x\n\ \ In an equation for \\226\\128\\152hm3\\226\\128\\153: hm3 x = foo x\n\ \(deferred type error)"# of wild_00 { } } }}} Reason: bug in the error suppression logic in `TcErrors` -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14325> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10241: BlockedIndefinitelyOnMVar thrown to the thread which is not blocked indefinitely
by GHC 21 May '18

21 May '18

#10241: BlockedIndefinitelyOnMVar thrown to the thread which is not blocked indefinitely -------------------------------------+------------------------------------- Reporter: asukamirai | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.8.3 System | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect result Architecture: x86_64 | at runtime (amd64) | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- BlockedIndefinatelyOnMVar exception is thrown to the main thread in below source code although the thread is not blocked indefinitely. {{{#!hs module Main where import qualified Control.Concurrent.MVar as MV import qualified Control.Concurrent as CC import qualified Control.Exception as E main :: IO () main = do -- call this thread "threadA" mvar1 <- MV.newEmptyMVar :: IO (MV.MVar ()) mvar2 <- MV.newEmptyMVar :: IO (MV.MVar ()) _ <- CC.forkIO $ do -- call this thread "threadB" MV.takeMVar mvar1 `E.catch` errorHandler1 putStrLn "after error catch" CC.threadDelay 1000000 MV.putMVar mvar2 () putStrLn "after putMVar" MV.readMVar mvar2 `E.catch` errorHandler2 putStrLn "after readMVar" CC.threadDelay 5000000 where errorHandler1 :: E.BlockedIndefinitelyOnMVar -> IO () errorHandler1 e = putStrLn $ "errorHandler1 : " ++ show e errorHandler2 :: E.BlockedIndefinitelyOnMVar -> IO () errorHandler2 e = putStrLn $ "errorHandler2 : " ++ show e }}} Save above as "mvar.hs" and run by ghc as below. {{{ > runhaskell mvar.hs errorHandler1 : thread blocked indefinitely in an MVar operation errorHandler2 : thread blocked indefinitely in an MVar operation after error catch after readMVar after putMVar }}} BlockedIndefinitelyOnMVar thrown for mvar1 is correct. It will be caught by errorHandler1 and "threadB" can continue to put the value to mvar2. It means that "threadA" can wait for the value of mvar2 and it is not blocked indefinately. However, BlockedIndefinitelyOnMVar is thrown for mvar2 on "threadA" before "threadB" puts value to the mvar2. I think it is incorrect. ---- I tested another case that adding "CC.threadDelay 10000000" before "readMVar" as below. {{{#!hs module Main where import qualified Control.Concurrent.MVar as MV import qualified Control.Concurrent as CC import qualified Control.Exception as E main :: IO () main = do -- call this thread "threadA" mvar1 <- MV.newEmptyMVar :: IO (MV.MVar ()) mvar2 <- MV.newEmptyMVar :: IO (MV.MVar ()) _ <- CC.forkIO $ do -- call this thread "threadB" MV.takeMVar mvar1 `E.catch` errorHandler1 putStrLn "after error catch" CC.threadDelay 1000000 MV.putMVar mvar2 () putStrLn "after putMVar" CC.threadDelay 10000000 -- <-- this line is added MV.readMVar mvar2 `E.catch` errorHandler2 putStrLn "after readMVar" CC.threadDelay 5000000 where errorHandler1 :: E.BlockedIndefinitelyOnMVar -> IO () errorHandler1 e = putStrLn $ "errorHandler1 : " ++ show e errorHandler2 :: E.BlockedIndefinitelyOnMVar -> IO () errorHandler2 e = putStrLn $ "errorHandler2 : " ++ show e }}} And it will run correctly (BlockedIndefinitelyOnMVar is not thrown for mvar2). {{{ > runhaskell mvar.hs errorHandler1 : thread blocked indefinitely in an MVar operation after error catch after putMVar after readMVar }}} ---- I found this behavior is same on STM / BlockedIndefinitelyOnSTM. {{{#!hs module Main where import qualified Control.Concurrent.STM as STM import qualified Control.Concurrent as CC import qualified Control.Exception as E main :: IO () main = do tmv1 <- STM.newEmptyTMVarIO :: IO (STM.TMVar ()) tmv2 <- STM.newEmptyTMVarIO :: IO (STM.TMVar ()) _ <- CC.forkIO $ do STM.atomically (STM.takeTMVar tmv1) `E.catch` errorHandler1 putStrLn "after error catch" CC.threadDelay 1000000 STM.atomically $ STM.putTMVar tmv2 () putStrLn "after putTMVar" STM.atomically (STM.readTMVar tmv2) `E.catch` errorHandler2 putStrLn "after readTMVar" CC.threadDelay 5000000 where errorHandler1 :: E.BlockedIndefinitelyOnSTM -> IO () errorHandler1 e = putStrLn $ "errorHandler1 : " ++ show e errorHandler2 :: E.BlockedIndefinitelyOnSTM -> IO () errorHandler2 e = putStrLn $ "errorHandler2 : " ++ show e }}} {{{ > runhaskell stm.hs errorHandler1 : thread blocked indefinitely in an STM transaction errorHandler2 : thread blocked indefinitely in an STM transaction after error catch after readTMVar after putTMVar }}} ---- I tested this in below versions/OSs and got same result (exception thrown for mvar2/tmv2). ghc7.8.3 on Windows7 ghc7.8.3 on lubuntu14.04 on VirtualBox on Windows7 ghc7.8.4 on lubuntu14.04 on VirtualBox on Windows7 ghc7.10.1 on lubuntu14.04 on VirtualBox on Windows7 Similar report https://ghc.haskell.org/trac/ghc/ticket/8804 found but not the same. (In this case, the reference to the MVar is not weak) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10241> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #13793: Simple program trips checkNurserySanity()
by GHC 20 May '18

20 May '18

#13793: Simple program trips checkNurserySanity() -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.3 System | Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Error: {{{ Repro: internal error: ASSERTION FAILED: file rts/sm/Sanity.c, line 713 (GHC version 8.3.20170606 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Repro steps: * Add `GhcRTSWays += thr_debug` to `mk/build.mk` to build threaded debug runtime {{{ inplace/bin/ghc-stage2 -fforce-recomp -debug -rtsopts -threaded -main-is Repro Repro.hs ./Repro +RTS -A16m -DS }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13793> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #13857: compactAdd doesn't work with SmallArray#
by GHC 20 May '18

20 May '18

#13857: compactAdd doesn't work with SmallArray# -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Runtime | Version: 8.2.1-rc2 System | Keywords: compact | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I get this when I try to compact a small array: {{{ internal error: stg_compactAddWorkerzh: TODO: SMALL_MUT_ARR_PTRS (GHC version 8.2.0.20170404 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} If I look in `rts/Compact.cmm`, I can see that this hasn't been implemented. I haven't seen this in another issue, so I just wanted to make sure it was not overlooked before the 8.2 release. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13857> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #9640: Invalid object in processHeapClosureForDead(): 2130762223
by GHC 19 May '18

19 May '18

#9640: Invalid object in processHeapClosureForDead(): 2130762223 -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I just tried using {{{-hb}}} profiling for Yi and hit {{{ yi: internal error: Invalid object in processHeapClosureForDead(): 2130762223 (GHC version 7.8.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted }}} Unfortunately I don't have an easy way to replicate. In my case it's to check out HEAD version of Yi, build with profiling and run {{{ [nix-shell:~/programming/yi/yi]$ TERM=xterm yi_datadir=. dist/build/yi/yi -fpango --as=emacs -y /tmp /tmp/long +RTS -p -hb }}} where {{{/tmp/long}}} here is just a file with 1MB of the letter {{{A}}} repeated on a single line. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9640> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11515: PartialTypeSignatures suggests a redundant constraint with constraint families
by GHC 18 May '18

18 May '18

#11515: PartialTypeSignatures suggests a redundant constraint with constraint families -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When I say {{{ {-# LANGUAGE ConstraintKinds, TypeFamilies #-} module Bug where type family ShowSyn a where ShowSyn a = Show a foo :: (ShowSyn a, _) => a -> String foo x = show x }}} I get {{{ Bug.hs:7:20: error: Found constraint wildcard ‘_’ standing for ‘Show a’ To use the inferred type, enable PartialTypeSignatures In the type signature: foo :: (ShowSyn a, _) => a -> String }}} But if I fill in my wildcard with `Show a`, I'll rightly get a redundant constraint. Just a vanilla type synonym works there, but the type family causes trouble. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11515> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12563: Bad error message around lack of impredicativity
by GHC 18 May '18

18 May '18

#12563: Bad error message around lack of impredicativity -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- (Broken out from #12557.) Consider {{{ foo :: ((forall a. f a) -> f r) -> f r foo g = undefined x = \g -> foo g }}} Compiling this code produces {{{ Scratch.hs:24:15: error: • Couldn't match expected type ‘(forall (a :: k). f a) -> f r’ with actual type ‘t’ ‘t’ is a rigid type variable bound by the inferred type of x :: t -> f r at Scratch.hs:24:1-15 • In the first argument of ‘foo’, namely ‘g’ In the expression: foo g In the expression: \ g -> foo g • Relevant bindings include g :: t (bound at Scratch.hs:24:6) x :: t -> f r (bound at Scratch.hs:24:1) }}} The code should be rejected. But, really, the problem is that the type of a lambda-bound variable can't be a polytype (unless the type is obvious at the binding site). We should improve this error message. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12563> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11513: Work out when GADT parameters should be specified
by GHC 18 May '18

18 May '18

#11513: Work out when GADT parameters should be specified -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple TypeApplications | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Right now, there's not a clear specification of when GADT data constructor parameters should be specified, and what order they appear in. For example: {{{ data G a where MkG :: b -> a -> G a }}} To my eye, we should get `MkG :: forall b a. b -> a -> G a`. But GHC now gives `MkG :: a {b}. b -> a -> G a`. At least two things are going on here: 1. GHC puts all universals before existentials. 2. There is an outright bug in `mkDataCon` that makes existentials act as inferred variables, but only for the representation type, not the wrapper type. You can witness (2) by noting that the `b` magically becomes specified if you put a strictness annotation (thereby necessitating the construction of a wrapper) anywhere. I'm not sure what to do about (1), from a design standpoint. Here are some thoughts. A. Having universals always come before existentials is convenient in pattern matching. When we have type application in patterns, you'll want to match only on existentials, never universals. So keeping the existentials together makes some sense. The universals will be omitted from the match entirely. B. FC absolutely requires that the universals come first. So if we allow the user to reorder the variables, that will necessitate creating a wrapper. Are there performance implications? That would be sad. C. We could tread a middle path, where if the user writes a `forall`, they get the order requested. Otherwise, they get universals first (whose order is taken from the ordering in the `data` declaration head) followed by existentials (whose order is taken from left-to-right first occurrence in the constructor type signature). But this is different than for functions, where we always use left-to-right ordering, even when lacking a `forall`. I tend to think that we should always just do what the user asks, but I'm worried about performance implications of this decision. It will make wrappers necessary for existential constructors that otherwise don't need them. Note that this whole debate is about only GADT constructors, not Haskell98 ones. Haskell98 constructors will always have universals before existentials, because that's quite obvious from the way they're declared. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11513> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10