GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:14:43Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/15005GHC fails with “StgCmmEnv: variable not found” when trying to compile order-m...2019-07-07T18:14:43ZWolfgang JeltschGHC fails with “StgCmmEnv: variable not found” when trying to compile order-maintenance-0.2.1.0When trying to build `order-maintenance-0.2.1.0`, GHC 8.4.2-rc1 panics. Its output is as follows:
```
[ 1 of 21] Compiling Data.Order.Algorithm.Raw ( src/library/Data/Order/Algorithm/Raw.hs, /home/wolfgang/Entwicklung/Haskell/order-main...When trying to build `order-maintenance-0.2.1.0`, GHC 8.4.2-rc1 panics. Its output is as follows:
```
[ 1 of 21] Compiling Data.Order.Algorithm.Raw ( src/library/Data/Order/Algorithm/Raw.hs, /home/wolfgang/Entwicklung/Haskell/order-maintenance-0.2.1.0/dist-newstyle/build/x86_64-linux/ghc-8.4.1.20180329/order-maintenance-0.2.1.0/build/Data/Order/Algorithm/Raw.o )
[ 2 of 21] Compiling Data.Order.Algorithm.Raw.DietzSleatorAmortizedLog ( src/library/Data/Order/Algorithm/Raw/DietzSleatorAmortizedLog.hs, /home/wolfgang/Entwicklung/Haskell/order-maintenance-0.2.1.0/dist-newstyle/build/x86_64-linux/ghc-8.4.1.20180329/order-maintenance-0.2.1.0/build/Data/Order/Algorithm/Raw/DietzSleatorAmortizedLog.o )
ghc: panic! (the 'impossible' happened)
(GHC version 8.4.1.20180329 for x86_64-unknown-linux):
StgCmmEnv: variable not found
x_a46z
local binds for:
$tc'Label
$tcLabel
$tc'Cell
$tcCell
$trModule
$tc'Cell1
$tc'Cell2
$tc'Cell3
$trModule1
$trModule2
$trModule3
$trModule4
$tc'Label1
$tc'Label2
$tc'Label3
$tcCell1
$tcCell2
$tcLabel1
$tcLabel2
lvl_r4UD
lvl1_r4UE
lvl2_r4UF
lvl3_r4UG
lvl4_r4UH
lvl5_r4UI
lvl6_r4UJ
lvl7_r4UK
lvl8_r4UL
lvl9_r4UM
lvl10_r4UN
lvl11_r4UO
lvl12_r4UP
lvl13_r4UQ
lvl14_r4UR
lvl15_r4US
lvl16_r4UT
lvl17_r4UU
$krep_r4UV
$krep1_r4UW
$krep2_r4UX
lvl18_r4UY
$krep3_r4UZ
$krep4_r4V0
$krep5_r4V1
$krep6_r4V2
$krep7_r4V3
$krep8_r4V4
$krep9_r4V5
lvl19_r4V6
lvl20_r4V7
lvl21_r4V8
lvl22_r4V9
lvl23_r4Va
lvl24_r4Vb
lvl25_r4Vc
ww_s4W2
lwild_s4W3
lwild1_s4W4
noOfLabels_s4W5
noOfLabels1_s4W6
labelMask_s4W7
$wnewAfterCell_s4Wa
ww1_s4Wb
ipv1_s4Wf
wild_s4Wg
ds_s4Wh
ds2_s4Wi
ww2_s4Wk
ww3_s4Wl
ww4_s4Wn
ww5_s4Wo
wild1_s4Wq
smallGap_s4Wr
wild2_s4Ws
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable
pprPanic, called at compiler/codeGen/StgCmmEnv.hs:149:9 in ghc:StgCmmEnv
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
The same problem exists with GHC 8.4.1.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.2-rc1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC fails with “StgCmmEnv: variable not found” when trying to compile order-maintenance-0.2.1.0","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.4.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.2-rc1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When trying to build `order-maintenance-0.2.1.0`, GHC 8.4.2-rc1 panics. Its output is as follows:\r\n\r\n{{{\r\n[ 1 of 21] Compiling Data.Order.Algorithm.Raw ( src/library/Data/Order/Algorithm/Raw.hs, /home/wolfgang/Entwicklung/Haskell/order-maintenance-0.2.1.0/dist-newstyle/build/x86_64-linux/ghc-8.4.1.20180329/order-maintenance-0.2.1.0/build/Data/Order/Algorithm/Raw.o )\r\n[ 2 of 21] Compiling Data.Order.Algorithm.Raw.DietzSleatorAmortizedLog ( src/library/Data/Order/Algorithm/Raw/DietzSleatorAmortizedLog.hs, /home/wolfgang/Entwicklung/Haskell/order-maintenance-0.2.1.0/dist-newstyle/build/x86_64-linux/ghc-8.4.1.20180329/order-maintenance-0.2.1.0/build/Data/Order/Algorithm/Raw/DietzSleatorAmortizedLog.o )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.4.1.20180329 for x86_64-unknown-linux):\r\n\tStgCmmEnv: variable not found\r\n x_a46z\r\n local binds for:\r\n $tc'Label\r\n $tcLabel\r\n $tc'Cell\r\n $tcCell\r\n $trModule\r\n $tc'Cell1\r\n $tc'Cell2\r\n $tc'Cell3\r\n $trModule1\r\n $trModule2\r\n $trModule3\r\n $trModule4\r\n $tc'Label1\r\n $tc'Label2\r\n $tc'Label3\r\n $tcCell1\r\n $tcCell2\r\n $tcLabel1\r\n $tcLabel2\r\n lvl_r4UD\r\n lvl1_r4UE\r\n lvl2_r4UF\r\n lvl3_r4UG\r\n lvl4_r4UH\r\n lvl5_r4UI\r\n lvl6_r4UJ\r\n lvl7_r4UK\r\n lvl8_r4UL\r\n lvl9_r4UM\r\n lvl10_r4UN\r\n lvl11_r4UO\r\n lvl12_r4UP\r\n lvl13_r4UQ\r\n lvl14_r4UR\r\n lvl15_r4US\r\n lvl16_r4UT\r\n lvl17_r4UU\r\n $krep_r4UV\r\n $krep1_r4UW\r\n $krep2_r4UX\r\n lvl18_r4UY\r\n $krep3_r4UZ\r\n $krep4_r4V0\r\n $krep5_r4V1\r\n $krep6_r4V2\r\n $krep7_r4V3\r\n $krep8_r4V4\r\n $krep9_r4V5\r\n lvl19_r4V6\r\n lvl20_r4V7\r\n lvl21_r4V8\r\n lvl22_r4V9\r\n lvl23_r4Va\r\n lvl24_r4Vb\r\n lvl25_r4Vc\r\n ww_s4W2\r\n lwild_s4W3\r\n lwild1_s4W4\r\n noOfLabels_s4W5\r\n noOfLabels1_s4W6\r\n labelMask_s4W7\r\n $wnewAfterCell_s4Wa\r\n ww1_s4Wb\r\n ipv1_s4Wf\r\n wild_s4Wg\r\n ds_s4Wh\r\n ds2_s4Wi\r\n ww2_s4Wk\r\n ww3_s4Wl\r\n ww4_s4Wn\r\n ww5_s4Wo\r\n wild1_s4Wq\r\n smallGap_s4Wr\r\n wild2_s4Ws\r\n Call stack:\r\n CallStack (from HasCallStack):\r\n callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable\r\n pprPanic, called at compiler/codeGen/StgCmmEnv.hs:149:9 in ghc:StgCmmEnv\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nThe same problem exists with GHC 8.4.1.","type_of_failure":"OtherFailure","blocking":[]} -->8.4.2https://gitlab.haskell.org/ghc/ghc/-/issues/14982LLVM default -mcpu setting inhibits customization2019-07-07T18:14:48ZThomas Main DuBuissonLLVM default -mcpu setting inhibits customizationWith GHC 8.4.1 we are now passing a default `-mcpu` selection to llvm. This default is passed regardless of any explicit command line option such as `-optlc=-mcpu=native`. If/when the user explicitly specifies the architecture we now get...With GHC 8.4.1 we are now passing a default `-mcpu` selection to llvm. This default is passed regardless of any explicit command line option such as `-optlc=-mcpu=native`. If/when the user explicitly specifies the architecture we now get a failed build. The error message from LLVM is:
```
llc: for the -mcpu option: may only occur zero or one times!
`llc' failed in phase `LLVM Compiler'. (Exit code: 1)
```
This is when compiling with GHC 8.4.1 as such:
{{{
ghc-8.4.1 -fforce-recomp -fllvm -optlc=-mcpu=native -O2 tt.hs
}}
I suggest we either check for a user option of `mcpu` before adding the default or revert this behavior and allow llvm to take it's (optimistic and less portable) default.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------- |
| Version | 8.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (LLVM) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"LLVM default -mcpu setting inhibits customization","status":"New","operating_system":"","component":"Compiler (LLVM)","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"With GHC 8.4.1 we are now passing a default `-mcpu` selection to llvm. This default is passed regardless of any explicit command line option such as `-optlc=-mcpu=native`. If/when the user explicitly specifies the architecture we now get a failed build. The error message from LLVM is:\r\n\r\n{{{\r\nllc: for the -mcpu option: may only occur zero or one times!\r\n`llc' failed in phase `LLVM Compiler'. (Exit code: 1)\r\n}}}\r\n\r\nThis is when compiling with GHC 8.4.1 as such:\r\n\r\n{{{\r\nghc-8.4.1 -fforce-recomp -fllvm -optlc=-mcpu=native -O2 tt.hs\r\n}}\r\n\r\nI suggest we either check for a user option of `mcpu` before adding the default or revert this behavior and allow llvm to take it's (optimistic and less portable) default.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.4.2https://gitlab.haskell.org/ghc/ghc/-/issues/14972MacOS panic on TH2019-07-07T18:14:50ZAlec TheriaultMacOS panic on THI recently did a clean build of master (affdea82bb70e5a912b679a169c6e9a230e4c93e) and, while everything successfully finished, I'm getting panics every time I try to use this GHC for something that involves TH.
For example:
```hs
{-# l...I recently did a clean build of master (affdea82bb70e5a912b679a169c6e9a230e4c93e) and, while everything successfully finished, I'm getting panics every time I try to use this GHC for something that involves TH.
For example:
```hs
{-# language TemplateHaskell #-}
pure []
main = pure []
```
Crashes with
```
$ ./inplace/bin/ghc-stage2 th.hs
[1 of 1] Compiling Main ( th.hs, th.o )
ghc-stage2: loadArchive: Failed reading header from `/Users/atheriault/Documents/code/ghc/libraries/integer-gmp/dist-install/build/gmp'
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 8.5.20180325 for x86_64-apple-darwin):
loadArchive "/Users/atheriault/Documents/code/ghc/libraries/integer-gmp/dist-install/build/gmp": failed
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
Normally I'd assume I haven't correctly configured something, yet I had no problem building and running GHC on this machine a month or so ago...
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"MacOS panic on TH","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I recently did a clean build of master (affdea82bb70e5a912b679a169c6e9a230e4c93e) and, while everything successfully finished, I'm getting panics every time I try to use this GHC for something that involves TH.\r\n\r\nFor example:\r\n\r\n{{{#!hs\r\n{-# language TemplateHaskell #-}\r\n\r\npure []\r\nmain = pure []\r\n}}}\r\n\r\nCrashes with\r\n\r\n{{{\r\n$ ./inplace/bin/ghc-stage2 th.hs\r\n[1 of 1] Compiling Main ( th.hs, th.o )\r\nghc-stage2: loadArchive: Failed reading header from `/Users/atheriault/Documents/code/ghc/libraries/integer-gmp/dist-install/build/gmp'\r\nghc-stage2: panic! (the 'impossible' happened)\r\n (GHC version 8.5.20180325 for x86_64-apple-darwin):\r\n loadArchive \"/Users/atheriault/Documents/code/ghc/libraries/integer-gmp/dist-install/build/gmp\": failed\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nNormally I'd assume I haven't correctly configured something, yet I had no problem building and running GHC on this machine a month or so ago...","type_of_failure":"OtherFailure","blocking":[]} -->8.4.2https://gitlab.haskell.org/ghc/ghc/-/issues/14965GHC 8.4.1 bug: -O + separate compilation + three list fields + concatenation;...2019-07-07T18:14:52ZblynnGHC 8.4.1 bug: -O + separate compilation + three list fields + concatenation; core-lint failsA simple program that works in 8.2.1 fails in 8.4.1 when compiled with -O. (Sorry, haven't tested 8.2.2.) GHC with -dcore-lint reports an error.
See attached files. In one file I declared:
```hs
module Sep where
data Sep = Sep
{ bug...A simple program that works in 8.2.1 fails in 8.4.1 when compiled with -O. (Sorry, haven't tested 8.2.2.) GHC with -dcore-lint reports an error.
See attached files. In one file I declared:
```hs
module Sep where
data Sep = Sep
{ bugVanishesWithoutThis :: [()]
, middle :: [String]
, orThis :: [()]
}
catSep :: Sep -> Sep -> Sep
catSep (Sep a b c) (Sep x y z) = Sep (a ++ x) (b ++ y) (c ++ z)
cc :: Sep -> Bool
cc boost = elem "foo" $ middle boost
```
and in a second file, simple code fails when compiled with -O:
```hs
module Main (main) where
import Sep
main :: IO ()
main = print $ cc bb
bb :: Sep
bb = catSep b1 b2
b1 :: Sep
b1 = Sep [] ["foo"] []
b2 :: Sep
b2 = Sep [] ["bar"] []
```
This should print "True", and does so for GHC 8.2.1, and GHC 8.4.1 without -O, but prints "False" for GHC 8.4.1 with -O.
I was unable to reproduce the bug with a single file.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------- |
| Version | 8.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ben@dfinity.org |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC 8.4.1 bug: -O + separate compilation + three list fields + concatenation; core-lint fails","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ben@dfinity.org"],"type":"Bug","description":"A simple program that works in 8.2.1 fails in 8.4.1 when compiled with -O. (Sorry, haven't tested 8.2.2.) GHC with -dcore-lint reports an error.\r\n\r\nSee attached files. In one file I declared:\r\n\r\n{{{#!hs\r\nmodule Sep where\r\n\r\ndata Sep = Sep\r\n { bugVanishesWithoutThis :: [()]\r\n , middle :: [String]\r\n , orThis :: [()]\r\n }\r\n\r\ncatSep :: Sep -> Sep -> Sep\r\ncatSep (Sep a b c) (Sep x y z) = Sep (a ++ x) (b ++ y) (c ++ z)\r\n\r\ncc :: Sep -> Bool\r\ncc boost = elem \"foo\" $ middle boost\r\n}}}\r\n\r\nand in a second file, simple code fails when compiled with -O:\r\n\r\n{{{#!hs\r\nmodule Main (main) where\r\n\r\nimport Sep\r\n\r\nmain :: IO ()\r\nmain = print $ cc bb\r\n\r\nbb :: Sep\r\nbb = catSep b1 b2\r\n\r\nb1 :: Sep\r\nb1 = Sep [] [\"foo\"] []\r\n\r\nb2 :: Sep\r\nb2 = Sep [] [\"bar\"] []\r\n}}}\r\n\r\nThis should print \"True\", and does so for GHC 8.2.1, and GHC 8.4.1 without -O, but prints \"False\" for GHC 8.4.1 with -O.\r\n\r\nI was unable to reproduce the bug with a single file.","type_of_failure":"OtherFailure","blocking":[]} -->8.4.2https://gitlab.haskell.org/ghc/ghc/-/issues/14959Heap overflow in optimizer2019-07-07T18:14:53ZdarchonHeap overflow in optimizerCompiling the following with optimisations:
```
module Test where
import Data.Bits (setBit)
f = foldl setBit 0 [x | (x,_) <- zip [0..] [1]] :: Integer
```
fails with:
```
$ ghc -O0 -fforce-recomp Test.hs
[1 of 1] Compiling Test ...Compiling the following with optimisations:
```
module Test where
import Data.Bits (setBit)
f = foldl setBit 0 [x | (x,_) <- zip [0..] [1]] :: Integer
```
fails with:
```
$ ghc -O0 -fforce-recomp Test.hs
[1 of 1] Compiling Test ( Test.hs, Test.o )
$ ghc -O -fforce-recomp Test.hs
[1 of 1] Compiling Test ( Test.hs, Test.o )
ghc: panic! (the 'impossible' happened)
(GHC version 8.4.1 for x86_64-unknown-linux):
heap overflow
```
Fails on 8.0.2, 8.2.2, and 8.4.1
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Heep overflow in optimizer","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Compiling the following with optimisations:\r\n\r\n{{{\r\nmodule Test where\r\n\r\nimport Data.Bits (setBit)\r\n\r\nf = foldl setBit 0 [x | (x,_) <- zip [0..] [1]] :: Integer\r\n}}}\r\n\r\nfails with:\r\n\r\n{{{\r\n$ ghc -O0 -fforce-recomp Test.hs\r\n[1 of 1] Compiling Test ( Test.hs, Test.o )\r\n$ ghc -O -fforce-recomp Test.hs\r\n[1 of 1] Compiling Test ( Test.hs, Test.o )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.4.1 for x86_64-unknown-linux):\r\n\theap overflow\r\n}}}\r\n\r\nFails on 8.0.2, 8.2.2, and 8.4.1","type_of_failure":"OtherFailure","blocking":[]} -->8.4.2https://gitlab.haskell.org/ghc/ghc/-/issues/14934Repeated "impossible" go_axiom_rule error.2021-04-08T13:45:22ZGalen HuntingtonRepeated "impossible" go_axiom_rule error.I am getting the following error repeatedly:
```
ghc: panic! (the 'impossible' happened)
(GHC version 8.4.1 for x86_64-unknown-linux):
go_axiom_rule
Sub0R
Call stack:
CallStack (from HasCallStack):
callStackDoc, cal...I am getting the following error repeatedly:
```
ghc: panic! (the 'impossible' happened)
(GHC version 8.4.1 for x86_64-unknown-linux):
go_axiom_rule
Sub0R
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable
pprPanic, called at compiler/iface/TcIface.hs:1371:15 in ghc:TcIface
```
I got it on 8.2.1, and tried upgrading to 8.4.1 to see if it went away, but it did not.
It occurs frequently when I do a `--make` and recompile a subset of modules. I can avoid it by force-recompiling all modules, although of course this is inefficient.
Since I'm working with a codebase of thousands of lines and don't understand ghc's innards, I'm not sure where to start looking for the cause, to produce a minimal failing example. But it did start happening around the time I expanded my use of this module:
https://github.com/agrafix/superrecord
Since there are unsafe operations in there, it is possible it is doing something illicit, but it is hard to see how it would cause this.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Repeated \"impossible\" go_axiom_rule error.","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I am getting the following error repeatedly:\r\n\r\n{{{\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.4.1 for x86_64-unknown-linux):\r\n\tgo_axiom_rule\r\n Sub0R\r\n Call stack:\r\n CallStack (from HasCallStack):\r\n callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable\r\n pprPanic, called at compiler/iface/TcIface.hs:1371:15 in ghc:TcIface\r\n}}}\r\n\r\nI got it on 8.2.1, and tried upgrading to 8.4.1 to see if it went away, but it did not.\r\n\r\nIt occurs frequently when I do a `--make` and recompile a subset of modules. I can avoid it by force-recompiling all modules, although of course this is inefficient.\r\n\r\nSince I'm working with a codebase of thousands of lines and don't understand ghc's innards, I'm not sure where to start looking for the cause, to produce a minimal failing example. But it did start happening around the time I expanded my use of this module:\r\n\r\nhttps://github.com/agrafix/superrecord\r\n\r\nSince there are unsafe operations in there, it is possible it is doing something illicit, but it is hard to see how it would cause this.","type_of_failure":"OtherFailure","blocking":[]} -->8.4.2https://gitlab.haskell.org/ghc/ghc/-/issues/14933DeriveAnyClass can cause "No skolem info" GHC panic2019-07-07T18:14:59ZRyan ScottDeriveAnyClass can cause "No skolem info" GHC panicThis program panics:
```hs
{-# LANGUAGE DefaultSignatures #-}
{-# LANGUAGE DeriveAnyClass #-}
{-# LANGUAGE DeriveGeneric #-}
{-# LANGUAGE DerivingStrategies #-}
{-# LANGUAGE FlexibleContexts ...This program panics:
```hs
{-# LANGUAGE DefaultSignatures #-}
{-# LANGUAGE DeriveAnyClass #-}
{-# LANGUAGE DeriveGeneric #-}
{-# LANGUAGE DerivingStrategies #-}
{-# LANGUAGE FlexibleContexts #-}
{-# LANGUAGE GeneralizedNewtypeDeriving #-}
{-# LANGUAGE RankNTypes #-}
{-# LANGUAGE ScopedTypeVariables #-}
{-# LANGUAGE TypeFamilies #-}
module Bug where
import Control.Concurrent (ThreadId)
import Control.Monad.Reader
class Wrapped s where
type Unwrapped s :: *
_Wrapped' :: Iso' s (Unwrapped s)
type Iso' s a = forall f. Functor f => (a -> f a) -> s -> f s
class Fork m where
fork :: x -> m () -> m ThreadId
default fork :: ( Wrapped (m ())
, Unwrapped (m ()) ~ t ()
, Fork t
, Wrapped (m ThreadId)
, Unwrapped (m ThreadId) ~ t ThreadId
) => x -> m () -> m ThreadId
fork = undefined -- view _Unwrapped' . fork . view _Wrapped'
instance Fork m => Fork (ReaderT e m) where
fork x action = ReaderT $ \env -> fork x (runReaderT action env)
data Env
newtype MyThing m a = MyThing { unMyThing :: ReaderT Env m a }
deriving newtype (Functor, Applicative, Monad)
deriving anyclass (Fork)
instance Wrapped (MyThing m a) where
type Unwrapped (MyThing m a) = ReaderT Env m a
_Wrapped' = undefined -- iso unMyThing MyThing
```
```
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Bug.hs:39:24: error:ghc: panic! (the 'impossible' happened)
(GHC version 8.2.2 for x86_64-unknown-linux):
No skolem info:
m_a1Hs[sk:2]
Call stack:
CallStack (from HasCallStack):
prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable
callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable
pprPanic, called at compiler/typecheck/TcErrors.hs:2653:5 in ghc:TcErrors
```
(Program adapted from [here](https://github.com/ekmett/lens/issues/793#issuecomment-369597846).)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"DeriveAnyClass can cause \"No skolem info\" GHC panic","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":["deriving"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This program panics:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE DefaultSignatures #-}\r\n{-# LANGUAGE DeriveAnyClass #-}\r\n{-# LANGUAGE DeriveGeneric #-}\r\n{-# LANGUAGE DerivingStrategies #-}\r\n{-# LANGUAGE FlexibleContexts #-}\r\n{-# LANGUAGE GeneralizedNewtypeDeriving #-}\r\n{-# LANGUAGE RankNTypes #-}\r\n{-# LANGUAGE ScopedTypeVariables #-}\r\n{-# LANGUAGE TypeFamilies #-}\r\nmodule Bug where\r\n\r\nimport Control.Concurrent (ThreadId)\r\nimport Control.Monad.Reader\r\n\r\nclass Wrapped s where\r\n type Unwrapped s :: *\r\n _Wrapped' :: Iso' s (Unwrapped s)\r\n\r\ntype Iso' s a = forall f. Functor f => (a -> f a) -> s -> f s\r\n\r\nclass Fork m where\r\n fork :: x -> m () -> m ThreadId\r\n\r\n default fork :: ( Wrapped (m ())\r\n , Unwrapped (m ()) ~ t ()\r\n , Fork t\r\n , Wrapped (m ThreadId)\r\n , Unwrapped (m ThreadId) ~ t ThreadId\r\n ) => x -> m () -> m ThreadId\r\n fork = undefined -- view _Unwrapped' . fork . view _Wrapped'\r\n\r\ninstance Fork m => Fork (ReaderT e m) where\r\n fork x action = ReaderT $ \\env -> fork x (runReaderT action env)\r\n\r\ndata Env\r\n\r\nnewtype MyThing m a = MyThing { unMyThing :: ReaderT Env m a }\r\n deriving newtype (Functor, Applicative, Monad)\r\n deriving anyclass (Fork)\r\n\r\ninstance Wrapped (MyThing m a) where\r\n type Unwrapped (MyThing m a) = ReaderT Env m a\r\n _Wrapped' = undefined -- iso unMyThing MyThing\r\n}}}\r\n\r\n{{{\r\n[1 of 1] Compiling Bug ( Bug.hs, Bug.o )\r\n\r\nBug.hs:39:24: error:ghc: panic! (the 'impossible' happened)\r\n (GHC version 8.2.2 for x86_64-unknown-linux):\r\n No skolem info:\r\n m_a1Hs[sk:2]\r\n Call stack:\r\n CallStack (from HasCallStack):\r\n prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable\r\n callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable\r\n pprPanic, called at compiler/typecheck/TcErrors.hs:2653:5 in ghc:TcErrors\r\n}}}\r\n\r\n(Program adapted from [https://github.com/ekmett/lens/issues/793#issuecomment-369597846 here].)","type_of_failure":"OtherFailure","blocking":[]} -->8.4.2https://gitlab.haskell.org/ghc/ghc/-/issues/14932DeriveAnyClass produces unjustifiably untouchable unification variables2021-12-14T14:30:30ZRyan ScottDeriveAnyClass produces unjustifiably untouchable unification variablesThe following code (courtesy of kosmikus) should typecheck, but does not:
```hs
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE DeriveAnyClass #-}
{-# LANGUAGE DefaultSignatures #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE TypeOperators #-}
m...The following code (courtesy of kosmikus) should typecheck, but does not:
```hs
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE DeriveAnyClass #-}
{-# LANGUAGE DefaultSignatures #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE TypeOperators #-}
module Zero where
import GHC.Exts
class Zero a where
zero :: a
default zero :: (Code a ~ '[xs], All Zero xs) => a
zero = undefined
type family All c xs :: Constraint where
All c '[] = ()
All c (x : xs) = (c x, All c xs)
type family Code (a :: *) :: [[*]]
type instance Code B1 = '[ '[ ] ]
data B1 = B1
deriving Zero
```
This produces the following error:
```
GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /nfs/nfs7/home/rgscott/.ghci
[1 of 1] Compiling Zero ( Bug.hs, interpreted )
Bug.hs:23:11: error:
• Couldn't match type ‘xs0’ with ‘'[]’
arising from the 'deriving' clause of a data type declaration
‘xs0’ is untouchable
inside the constraints: All Zero xs0
bound by the deriving clause for ‘Zero B1’
at Bug.hs:23:11-14
• When deriving the instance for (Zero B1)
|
23 | deriving Zero
| ^^^^
```
This error is baffling, however, because `xs0` should be a unification variable that readily unifies with `'[]`! As evidence, this typechecks:
```
instance Zero B1
```
But the equivalent `deriving` clause does not.
I know what is going on here after some sleuthing: `DeriveAnyClass` (specifically, `inferConstraintsDAC`) is producing unification variables whose TcLevel is always bumped to three. However, in the program above, we will not form an implication constraints around those unification variables, since `zero` has no locally quantified type variables or given constraints. Thus, `simplifyDeriv` will try to simplify unification variables with TcLevel 3 at the top level, which results in them being untouchable. Blegh.
This was partially noticed in #13272, when we were failing to bump unification variables that //did// appear inside implication constraints. However, we overlooked this one corner case, which kosmikus happened to stumble upon in a `generics-sop` [example](https://stackoverflow.com/a/49335338/1482749).
Patch incoming.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | #13272 |
| Blocking | |
| CC | kosmikus |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"DeriveAnyClass produces unjustifiably untouchable unification variables","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[13272],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.1","keywords":["deriving"],"differentials":[],"test_case":"","architecture":"","cc":["kosmikus"],"type":"Bug","description":"The following code (courtesy of kosmikus) should typecheck, but does not:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE DataKinds #-}\r\n{-# LANGUAGE DeriveAnyClass #-}\r\n{-# LANGUAGE DefaultSignatures #-}\r\n{-# LANGUAGE TypeFamilies #-}\r\n{-# LANGUAGE TypeOperators #-}\r\nmodule Zero where\r\n\r\nimport GHC.Exts\r\n\r\nclass Zero a where\r\n zero :: a\r\n default zero :: (Code a ~ '[xs], All Zero xs) => a\r\n zero = undefined\r\n\r\ntype family All c xs :: Constraint where\r\n All c '[] = ()\r\n All c (x : xs) = (c x, All c xs)\r\n\r\ntype family Code (a :: *) :: [[*]]\r\ntype instance Code B1 = '[ '[ ] ]\r\n\r\ndata B1 = B1\r\n deriving Zero\r\n}}}\r\n\r\nThis produces the following error:\r\n\r\n{{{\r\nGHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help\r\nLoaded GHCi configuration from /nfs/nfs7/home/rgscott/.ghci\r\n[1 of 1] Compiling Zero ( Bug.hs, interpreted )\r\n\r\nBug.hs:23:11: error:\r\n • Couldn't match type ‘xs0’ with ‘'[]’\r\n arising from the 'deriving' clause of a data type declaration\r\n ‘xs0’ is untouchable\r\n inside the constraints: All Zero xs0\r\n bound by the deriving clause for ‘Zero B1’\r\n at Bug.hs:23:11-14\r\n • When deriving the instance for (Zero B1)\r\n |\r\n23 | deriving Zero\r\n | ^^^^\r\n}}}\r\n\r\nThis error is baffling, however, because `xs0` should be a unification variable that readily unifies with `'[]`! As evidence, this typechecks:\r\n\r\n{{{\r\ninstance Zero B1\r\n}}}\r\n\r\nBut the equivalent `deriving` clause does not.\r\n\r\nI know what is going on here after some sleuthing: `DeriveAnyClass` (specifically, `inferConstraintsDAC`) is producing unification variables whose TcLevel is always bumped to three. However, in the program above, we will not form an implication constraints around those unification variables, since `zero` has no locally quantified type variables or given constraints. Thus, `simplifyDeriv` will try to simplify unification variables with TcLevel 3 at the top level, which results in them being untouchable. Blegh.\r\n\r\nThis was partially noticed in #13272, when we were failing to bump unification variables that //did// appear inside implication constraints. However, we overlooked this one corner case, which kosmikus happened to stumble upon in a `generics-sop` [https://stackoverflow.com/a/49335338/1482749 example].\r\n\r\nPatch incoming.","type_of_failure":"OtherFailure","blocking":[]} -->8.4.2https://gitlab.haskell.org/ghc/ghc/-/issues/14916Missing checks when deriving special classes2022-02-16T12:06:47ZAndres LöhMissing checks when deriving special classesFor the following program
```hs
{-# LANGUAGE DeriveAnyClass #-}
module T where
import Data.Coerce
import Data.Typeable
data A = MkA deriving ((~) A)
data B = MkB deriving (Coercible B)
```
the deriving clause for `A` is accepted with...For the following program
```hs
{-# LANGUAGE DeriveAnyClass #-}
module T where
import Data.Coerce
import Data.Typeable
data A = MkA deriving ((~) A)
data B = MkB deriving (Coercible B)
```
the deriving clause for `A` is accepted without complaints, and the
deriving clause for `B` fails with the following error:
```
T.hs:8:24: error:
Top-level bindings for unlifted types aren't allowed:
|
8 | data B = MkB deriving (Coercible B)
| ^^^^^^^^^^^
```
Corresponding standalone deriving instances trigger errors
saying "Manual instances of this class are not permitted".
Probably similar error messages should be triggered here.8.4.2https://gitlab.haskell.org/ghc/ghc/-/issues/14905GHCi segfaults with +RTS -Di after hitting a breakpoint2019-07-07T18:15:06ZÖmer Sinan AğacanGHCi segfaults with +RTS -Di after hitting a breakpointSteps to reproduce:
- Compile stage2 with `-debug`
- Run GHCi with `+RTS -Di`
- Load an interpreted module with a definition, set a breakpoint on the definition
- Evaluate the definition
GHCi crashes with a segfault. Backtrace:
```
#0...Steps to reproduce:
- Compile stage2 with `-debug`
- Run GHCi with `+RTS -Di`
- Load an interpreted module with a definition, set a breakpoint on the definition
- Evaluate the definition
GHCi crashes with a segfault. Backtrace:
```
#0 0x00007ffff18bcaa9 in disInstr (bco=0x4200013f30, pc=1) at rts/Disassembler.c:71
#1 0x00007ffff18c89e9 in interpretBCO (cap=0x7ffff19431c0 <MainCapability>) at rts/Interpreter.c:986
#2 0x00007ffff18d19fe in schedule (initialCapability=0x7ffff19431c0 <MainCapability>, task=0x7fffe0000910) at rts/Schedule.c:471
#3 0x00007ffff18d4ee2 in scheduleWorker (cap=0x7ffff19431c0 <MainCapability>, task=0x7fffe0000910) at rts/Schedule.c:2553
#4 0x00007ffff18ccab8 in workerStart (task=0x7fffe0000910) at rts/Task.c:444
#5 0x00007ffff0c3c6ba in start_thread (arg=0x7fffee9aa700) at pthread_create.c:333
#6 0x00007ffff06f241d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
```
in this line:
```
71 debugBelch(" %s\n", ((CostCentre*)(literals[instrs[pc+3]]))->label);
```
`literals[instrs[pc+3]]` is null.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHCi segfaults with +RTS -Di after hitting a breakpoint","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Steps to reproduce:\r\n\r\n- Compile stage2 with `-debug`\r\n- Run GHCi with `+RTS -Di`\r\n- Load an interpreted module with a definition, set a breakpoint on the definition\r\n- Evaluate the definition\r\n\r\nGHCi crashes with a segfault. Backtrace:\r\n\r\n{{{\r\n#0 0x00007ffff18bcaa9 in disInstr (bco=0x4200013f30, pc=1) at rts/Disassembler.c:71\r\n#1 0x00007ffff18c89e9 in interpretBCO (cap=0x7ffff19431c0 <MainCapability>) at rts/Interpreter.c:986\r\n#2 0x00007ffff18d19fe in schedule (initialCapability=0x7ffff19431c0 <MainCapability>, task=0x7fffe0000910) at rts/Schedule.c:471\r\n#3 0x00007ffff18d4ee2 in scheduleWorker (cap=0x7ffff19431c0 <MainCapability>, task=0x7fffe0000910) at rts/Schedule.c:2553\r\n#4 0x00007ffff18ccab8 in workerStart (task=0x7fffe0000910) at rts/Task.c:444\r\n#5 0x00007ffff0c3c6ba in start_thread (arg=0x7fffee9aa700) at pthread_create.c:333\r\n#6 0x00007ffff06f241d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109\r\n}}}\r\n\r\nin this line:\r\n\r\n{{{\r\n71 debugBelch(\" %s\\n\", ((CostCentre*)(literals[instrs[pc+3]]))->label);\r\n}}}\r\n\r\n`literals[instrs[pc+3]]` is null.","type_of_failure":"OtherFailure","blocking":[]} -->8.4.2https://gitlab.haskell.org/ghc/ghc/-/issues/14894HEAD fails to build with -g12022-10-25T14:14:38ZniteriaHEAD fails to build with -g1I wanted to see how `-g1` vs `-g2` impact compile speed. Unfortunately I get linking errors trying to build GHC with `-g1`.
Steps:
1. Add:
```
GhcLibHcOpts += -g1
GhcRtsHcOpts += -g1
```
to `mk/build.mk`. I used devel2 flavor.
1. `....I wanted to see how `-g1` vs `-g2` impact compile speed. Unfortunately I get linking errors trying to build GHC with `-g1`.
Steps:
1. Add:
```
GhcLibHcOpts += -g1
GhcRtsHcOpts += -g1
```
to `mk/build.mk`. I used devel2 flavor.
1. `./boot && ./configure && make -j`
1. Observe failure
The failure (trimmed):
```
/data/users/bnitka/ghc-HEAD-dwarf-lint-fixes-g/libraries/base/dist-install/build/libHSbase-4.11.0.0.a(Internals.o)(.debug_info+0x1c94): error: undefined refe
rence to '.LcbG2_info_die'
/data/users/bnitka/ghc-HEAD-dwarf-lint-fixes-g/libraries/base/dist-install/build/libHSbase-4.11.0.0.a(Internals.o)(.debug_info+0x1cc7): error: undefined refe
rence to '.LcbGL_die'
/data/users/bnitka/ghc-HEAD-dwarf-lint-fixes-g/libraries/base/dist-install/build/libHSbase-4.11.0.0.a(Internals.o)(.debug_info+0x1cfa): error: undefined refe
rence to '.LcbI0_die'
/data/users/bnitka/ghc-HEAD-dwarf-lint-fixes-g/libraries/base/dist-install/build/libHSbase-4.11.0.0.a(Internals.o)(.debug_info+0x1d2d): error: undefined refe
rence to '.LcbIh_die'
/data/users/bnitka/ghc-HEAD-dwarf-lint-fixes-g/libraries/base/dist-install/build/libHSbase-4.11.0.0.a(Internals.o)(.debug_info+0x21a4): error: undefined refe
rence to '.LcbSn_info_die'
/data/users/bnitka/ghc-HEAD-dwarf-lint-fixes-g/libraries/base/dist-install/build/libHSbase-4.11.0.0.a(Internals.o)(.debug_info+0x21d1): error: undefined refe
rence to '.LcbTc_die'
/data/users/bnitka/ghc-HEAD-dwarf-lint-fixes-g/libraries/base/dist-install/build/libHSbase-4.11.0.0.a(Internals.o)(.debug_info+0x234f): error: undefined refe
rence to '.Lcc18_die'
/data/users/bnitka/ghc-HEAD-dwarf-lint-fixes-g/libraries/base/dist-install/build/libHSbase-4.11.0.0.a(Internals.o)(.debug_info+0x2c76): error: undefined refe
rence to '.Lccmj_info_die'
/data/users/bnitka/ghc-HEAD-dwarf-lint-fixes-g/libraries/base/dist-install/build/libHSbase-4.11.0.0.a(Internals.o)(.debug_info+0x2dff): error: undefined refe
rence to '.LccsV_die'
/data/users/bnitka/ghc-HEAD-dwarf-lint-fixes-g/libraries/base/dist-install/build/libHSbase-4.11.0.0.a(Internals.o)(.debug_info+0x2e2f): error: undefined refe
rence to '.Lcct6_info_die'
/data/users/bnitka/ghc-HEAD-dwarf-lint-fixes-g/libraries/base/dist-install/build/libHSbase-4.11.0.0.a(Internals.o)(.debug_info+0x2f38): error: undefined refe
rence to '.Lccv1_info_die'
/data/users/bnitka/ghc-HEAD-dwarf-lint-fixes-g/libraries/base/dist-install/build/libHSbase-4.11.0.0.a(Internals.o)(.debug_info+0x2f66): error: undefined refe
rence to '.Lccve_die'
```8.4.2https://gitlab.haskell.org/ghc/ghc/-/issues/14868-O -g breaks string literals2019-07-07T18:15:16Ztakano-akio-O -g breaks string literalsWith `foo.hs`:
```hs
main = print (4, "foo")
```
Compile it and run it like:
```
% ghc-stage2 -O -g foo.hs
% ./foo
(4,"\CANq@")
```
Note that the content of the string literal is broken, although the length is preserved.
With `-dcor...With `foo.hs`:
```hs
main = print (4, "foo")
```
Compile it and run it like:
```
% ghc-stage2 -O -g foo.hs
% ./foo
(4,"\CANq@")
```
Note that the content of the string literal is broken, although the length is preserved.
With `-dcore-lint`, the following error is produced:
```
*** Core Lint errors : in result of Simplifier ***
<no location info>: warning:
[RHS of ww2_s3hG :: Addr#]
Recursive or top-level binder has strict demand info: ww2_s3hG
Binder's demand info: <L,U>
```
The offending binding is:
```hs
ww2_s3hG :: Addr#
[LclId,
Unf=Unf{Src=<vanilla>, TopLvl=False, Value=True, ConLike=True,
WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 20 0}]
ww2_s3hG = src<foo.hs:1:18-22> "foo"#
```
Happens with ghc 8.4.1-rc1 and with HEAD (df2c3b33648).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"-O -g breaks string literals","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"With `foo.hs`:\r\n\r\n{{{#!hs\r\nmain = print (4, \"foo\")\r\n}}}\r\n\r\nCompile it and run it like:\r\n\r\n{{{\r\n% ghc-stage2 -O -g foo.hs\r\n% ./foo\r\n(4,\"\\CANq@\")\r\n}}}\r\n\r\nNote that the content of the string literal is broken, although the length is preserved.\r\n\r\nWith `-dcore-lint`, the following error is produced:\r\n\r\n{{{\r\n*** Core Lint errors : in result of Simplifier ***\r\n<no location info>: warning:\r\n [RHS of ww2_s3hG :: Addr#]\r\n Recursive or top-level binder has strict demand info: ww2_s3hG\r\n Binder's demand info: <L,U>\r\n}}}\r\n\r\nThe offending binding is:\r\n\r\n{{{#!hs\r\nww2_s3hG :: Addr#\r\n[LclId,\r\n Unf=Unf{Src=<vanilla>, TopLvl=False, Value=True, ConLike=True,\r\n WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 20 0}]\r\nww2_s3hG = src<foo.hs:1:18-22> \"foo\"#\r\n}}}\r\n\r\nHappens with ghc 8.4.1-rc1 and with HEAD (df2c3b33648).","type_of_failure":"OtherFailure","blocking":[]} -->8.4.2https://gitlab.haskell.org/ghc/ghc/-/issues/14846Renamer hangs (because of -XInstanceSigs?)2019-07-07T18:15:20ZIcelandjackRenamer hangs (because of -XInstanceSigs?)```hs
{-# Language RankNTypes, TypeInType, EmptyCase, GADTs, FlexibleInstances, ConstraintKinds, UndecidableInstances, AllowAmbiguousTypes, InstanceSigs, ScopedTypeVariables #-}
import Data.Kind
import Data.Proxy
type Cat ob = ob -> ob...```hs
{-# Language RankNTypes, TypeInType, EmptyCase, GADTs, FlexibleInstances, ConstraintKinds, UndecidableInstances, AllowAmbiguousTypes, InstanceSigs, ScopedTypeVariables #-}
import Data.Kind
import Data.Proxy
type Cat ob = ob -> ob -> Type
data Struct :: (k -> Constraint) -> Type where
S :: Proxy (a::k) -> Struct (cls::k -> Constraint)
type Structured a cls = (S ('Proxy :: Proxy a)::Struct cls)
data AStruct :: Struct cls -> Type where
AStruct :: cls a => AStruct (Structured a cls)
class StructI (structured::Struct (cls :: k -> Constraint)) where
struct :: AStruct structured
instance (Structured xx cls ~ structured, cls xx) => StructI structured where
struct :: AStruct (Structured xx cls)
struct = AStruct
data Hom :: Cat k -> Cat (Struct cls) where
class Category (cat::Cat ob) where
i :: StructI a => ríki a a
instance Category ríki => Category (Hom ríki :: Cat (Struct cls)) where
-- Commenting out this instance signature makes the issue go away
i :: forall a. StructI a => Hom ríki a a
i = case struct :: AStruct (Structured a cls) of
```
Running on 8.2.1 and 8.5.20180105 both loop until interrupted
```
$ ghci -ignore-dot-ghci 199.hs
GHCi, version 8.5.20180105: http://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling Main ( 199.hs, interpreted )
^CInterrupted.
>
>
```8.4.2Richard Eisenbergrae@richarde.devRichard Eisenbergrae@richarde.devhttps://gitlab.haskell.org/ghc/ghc/-/issues/14779Compiling with -g fails -lint-core checks2019-07-07T18:15:39ZniteriaCompiling with -g fails -lint-core checksCompiling the attached file produces:
```
$ inplace/bin/ghc-stage2 -O -dcore-lint -g -c Data.Fixed.hs
*** Core Lint errors : in result of Simplifier ***
<no location info>: warning:
[RHS of str_s2UI :: Addr#]
The type of this bi...Compiling the attached file produces:
```
$ inplace/bin/ghc-stage2 -O -dcore-lint -g -c Data.Fixed.hs
*** Core Lint errors : in result of Simplifier ***
<no location info>: warning:
[RHS of str_s2UI :: Addr#]
The type of this binder is unlifted: str_s2UI
Binder's type: Addr#
*** Offending Program ***
...
str_s2UI :: Addr#
[LclId,
Unf=Unf{Src=<vanilla>, TopLvl=False, Value=True, ConLike=True,
WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 30 0}]
str_s2UI = src<Data.Fixed.hs:78:31-39> "MkFixed"#
str_a2j4 :: String
[LclId,
Unf=Unf{Src=<vanilla>, TopLvl=False, Value=False, ConLike=True,
WorkFree=False, Expandable=True, Guidance=IF_ARGS [] 20 0}]
str_a2j4 = src<Data.Fixed.hs:78:31-39> unpackCString# str_s2UI
...
```
This came up when I wanted to compile GHC HEAD with `-g`.
There are a couple of related tickets, but some of them didn't reproduce. This is a small, self-contained example.
I'm hoping that it would be possible to solve this without fully solving #14123 which seems to have bigger scope.
My HEAD is d2511e3b61563ed3fc2c9aec2c90a4156373a24c.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------------------- |
| Version | |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Debugging) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | bgamari, simonmar, simonpj |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Compiling with -g fails -lint-core checks","status":"New","operating_system":"","component":"Compiler (Debugging)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["bgamari","simonmar","simonpj"],"type":"Bug","description":"Compiling the attached file produces:\r\n{{{\r\n$ inplace/bin/ghc-stage2 -O -dcore-lint -g -c Data.Fixed.hs\r\n*** Core Lint errors : in result of Simplifier ***\r\n<no location info>: warning:\r\n [RHS of str_s2UI :: Addr#]\r\n The type of this binder is unlifted: str_s2UI\r\n Binder's type: Addr#\r\n*** Offending Program ***\r\n...\r\nstr_s2UI :: Addr#\r\n[LclId,\r\n Unf=Unf{Src=<vanilla>, TopLvl=False, Value=True, ConLike=True,\r\n WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 30 0}]\r\nstr_s2UI = src<Data.Fixed.hs:78:31-39> \"MkFixed\"#\r\n\r\nstr_a2j4 :: String\r\n[LclId,\r\n Unf=Unf{Src=<vanilla>, TopLvl=False, Value=False, ConLike=True,\r\n WorkFree=False, Expandable=True, Guidance=IF_ARGS [] 20 0}]\r\nstr_a2j4 = src<Data.Fixed.hs:78:31-39> unpackCString# str_s2UI\r\n...\r\n}}}\r\n\r\n\r\nThis came up when I wanted to compile GHC HEAD with `-g`. \r\nThere are a couple of related tickets, but some of them didn't reproduce. This is a small, self-contained example.\r\nI'm hoping that it would be possible to solve this without fully solving #14123 which seems to have bigger scope.\r\n\r\nMy HEAD is d2511e3b61563ed3fc2c9aec2c90a4156373a24c.","type_of_failure":"OtherFailure","blocking":[]} -->8.4.2https://gitlab.haskell.org/ghc/ghc/-/issues/14740Unboxed tuple allowed in context: ((##)) => ()2019-07-07T18:15:48ZIcelandjackUnboxed tuple allowed in context: ((##)) => ()I have a feeling this is not intended
```
GHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help
Prelude> :set -XUnboxedTuples
Prelude> let x :: ((##)) => (); x = ()
Prelude> :t x
x :: ()
Prelude> x
()
Prelude>
```
<det...I have a feeling this is not intended
```
GHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help
Prelude> :set -XUnboxedTuples
Prelude> let x :: ((##)) => (); x = ()
Prelude> :t x
x :: ()
Prelude> x
()
Prelude>
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Parser) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Unboxed tuple allowed in context: ((##)) => ()","status":"New","operating_system":"","component":"Compiler (Parser)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":["UnboxedTuples"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I have a feeling this is not intended\r\n\r\n{{{\r\nGHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help\r\nPrelude> :set -XUnboxedTuples \r\nPrelude> let x :: ((##)) => (); x = ()\r\nPrelude> :t x\r\nx :: ()\r\nPrelude> x\r\n()\r\nPrelude> \r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.4.2Tao Hesighingnow@gmail.comTao Hesighingnow@gmail.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/14048Data instances of kind Constraint2019-07-07T18:18:42ZIcelandjackData instances of kind ConstraintContinuation of #12369.
Allow data instances ending in `Constraint`.
This may be a bug but GHC already accepts (something to do with #11715) `data family Bot :: Constraint` but I can't make instances of it. Also fails for `data family ...Continuation of #12369.
Allow data instances ending in `Constraint`.
This may be a bug but GHC already accepts (something to do with #11715) `data family Bot :: Constraint` but I can't make instances of it. Also fails for `data family Bot :: TYPE IntRep`.
I propose letting users take these disparate data types and type classes
```hs
data Compose :: (k' -> Type) -> (k -> k') -> (k -> Type) where
Compose :: f (g a) -> Compose f g a
data Compose2 :: (k' -> (kk -> Type)) -> (k -> k') -> (k -> (kk -> Type)) where
Compose2 :: f (g a) b -> Compose2 f g a b
-- ComposeC :: (k' -> Constraint) -> (k -> k') -> (k -> Constraint)
class f (g a) => ComposeC f g a
instance f (g a) => ComposeC f g a
-- ComposeC2 :: (k' -> (kk -> Constraint)) -> (k -> k') -> (k -> (kk -> Constraint))
class f (g a) b => ComposeC2 f g a b
instance f (g a) b => ComposeC2 f g a b
```
and unify them as instances of a 'data' family indexed by `Type`, `kk -> Type`, `Constraint`, `kk -> Constraint`.
(Same can be done for `Data.Functor.Product` and `class (f a, g a) => ProductC f g a`):
```hs
data family (·) :: (k' -> k'') -> (k -> k') -> (k -> k'')
data instance (f · g) a where
Compose :: f (g a) -> (f · g) a
data instance (f · g) a b where
Compose2 :: f (g a) b -> (f · g) a b
instance f (g a) => (f · g) a
instance f (g a) b => (f · g) a b
```
----
TODO Once we have #1311 allow data instances of unlifted types.
----
Fun note: `(·) @(kk -> Type)` is used by [Kmett](https://gist.github.com/ekmett/48f1b578cadeeaeee7a309ec6933d7ec) (as `Tensor`) & to motivate [quantified class constraints](http://i.cs.hku.hk/~bruno/papers/hs2017.pdf), this should automatically pick the right data instance:
```hs
instance (Trans t, Trans t') => Trans (t · t') where
lift :: Monad m => m ~> (t · t') m
lift = Compose2 . lift @t . lift @t'
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Data instances of kind Constraint","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Continuation of #12369.\r\n\r\nAllow data instances ending in `Constraint`.\r\n\r\nThis may be a bug but GHC already accepts (something to do with #11715) `data family Bot :: Constraint` but I can't make instances of it. Also fails for `data family Bot :: TYPE IntRep`.\r\n\r\nI propose letting users take these disparate data types and type classes \r\n\r\n{{{#!hs\r\ndata Compose :: (k' -> Type) -> (k -> k') -> (k -> Type) where\r\n Compose :: f (g a) -> Compose f g a\r\n\r\ndata Compose2 :: (k' -> (kk -> Type)) -> (k -> k') -> (k -> (kk -> Type)) where\r\n Compose2 :: f (g a) b -> Compose2 f g a b\r\n\r\n-- ComposeC :: (k' -> Constraint) -> (k -> k') -> (k -> Constraint)\r\nclass f (g a) => ComposeC f g a\r\ninstance f (g a) => ComposeC f g a\r\n\r\n-- ComposeC2 :: (k' -> (kk -> Constraint)) -> (k -> k') -> (k -> (kk -> Constraint))\r\nclass f (g a) b => ComposeC2 f g a b\r\ninstance f (g a) b => ComposeC2 f g a b\r\n}}}\r\n\r\nand unify them as instances of a 'data' family indexed by `Type`, `kk -> Type`, `Constraint`, `kk -> Constraint`.\r\n\r\n(Same can be done for `Data.Functor.Product` and `class (f a, g a) => ProductC f g a`):\r\n\r\n{{{#!hs\r\ndata family (·) :: (k' -> k'') -> (k -> k') -> (k -> k'')\r\n\r\ndata instance (f · g) a where\r\n Compose :: f (g a) -> (f · g) a\r\n\r\ndata instance (f · g) a b where\r\n Compose2 :: f (g a) b -> (f · g) a b\r\n\r\ninstance f (g a) => (f · g) a\r\ninstance f (g a) b => (f · g) a b\r\n}}}\r\n\r\n----\r\n\r\nTODO Once we have #1311 allow data instances of unlifted types.\r\n\r\n----\r\n\r\nFun note: `(·) @(kk -> Type)` is used by [https://gist.github.com/ekmett/48f1b578cadeeaeee7a309ec6933d7ec Kmett] (as `Tensor`) & to motivate [http://i.cs.hku.hk/~bruno/papers/hs2017.pdf quantified class constraints], this should automatically pick the right data instance:\r\n\r\n{{{#!hs\r\ninstance (Trans t, Trans t') => Trans (t · t') where\r\n lift :: Monad m => m ~> (t · t') m\r\n lift = Compose2 . lift @t . lift @t'\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.4.2https://gitlab.haskell.org/ghc/ghc/-/issues/11188Confusing "parse error in pattern" for spurious indentation.2019-07-07T18:31:33Zandreas.abelConfusing "parse error in pattern" for spurious indentation.The following problem exists at least in ghc 7.4.2 through 7.10.1:
```hs
main = do
putStrLn "Hello, lots of crap" $ do
a <- return 3
-- The following line is mis-indented, the error is incomprehensible
c <- do
retu...The following problem exists at least in ghc 7.4.2 through 7.10.1:
```hs
main = do
putStrLn "Hello, lots of crap" $ do
a <- return 3
-- The following line is mis-indented, the error is incomprehensible
c <- do
return 5
```
Error:
```
<file>:2:3:
Parse error in pattern: putStrLn
Possibly caused by a missing 'do'?
```
The hint about "missing do" exists from ghc 7.8, but is wrong in this case.
Problematic about this bug is that the wrong indentation can be arbitrary many lines from where ghc reports the (totally incomprehensible) error. My original problem is to find the syntax error here:
```hs
-- | Type check a function clause.
checkClause :: Type -> A.SpineClause -> TCM Clause
checkClause t c@(A.Clause (A.SpineLHS i x aps withPats) rhs0 wh) = do
unless (null withPats) $ do
typeError $ UnexpectedWithPatterns withPats
traceCall (CheckClause t c) $ do
aps <- expandPatternSynonyms aps
checkLeftHandSide (CheckPatternShadowing c) (Just x) aps t $
\ (LHSResult delta ps trhs perm) -> do
-- Note that we might now be in irrelevant context,
-- in case checkLeftHandSide walked over an irrelevant projection pattern.
-- As we will be type-checking the @rhs@ in @delta@, but the final
-- body should have bindings in the order of the pattern variables,
-- we need to apply the permutation to the checked rhs @v@.
let mkBody v = foldr (\ x t -> Bind $ Abs x t) b xs
where b = Body $ applySubst (renamingR perm) v
xs = [ stringToArgName $ "h" ++ show n
| n <- [0..permRange perm - 1] ]
-- introduce trailing implicits for checking the where decls
TelV htel t0 <- telViewUpTo' (-1) (not . visible) $ unArg trhs
(body, with) <- do
let n = size htel
addCtxTel htel $ checkWhere (size delta + n) wh $
-- for the body, we remove the implicits again
escapeContext n $
handleRHS aps (unArgs trhs) rhs0
escapeContext (size delta) $ checkWithFunction with
reportSDoc "tc.lhs.top" 10 $ escapeContext (size delta) $ vcat
[ text "Clause before translation:"
, nest 2 $ vcat
[ text "delta =" <+> prettyTCM delta
, text "perm =" <+> text (show perm)
, text "ps =" <+> text (show ps)
, text "body =" <+> text (show body)
, text "body =" <+> prettyTCM body
]
]
return $
Clause { clauseRange = getRange i
, clauseTel = killRange delta
, clausePerm = perm
, namedClausePats = ps
, clauseBody = body
, clauseType = Just trhs
}
```
```
src/full/Agda/TypeChecking/Rules/Def.hs:328:5:
Parse error in pattern: checkLeftHandSide
Possibly caused by a missing 'do'?
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 7.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler (Parser) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Confusing \"parse error in pattern\" for missing indentation.","status":"New","operating_system":"","component":"Compiler (Parser)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following problem exists at least in ghc 7.4.2 through 7.10.1:\r\n{{{#!hs\r\nmain = do\r\n putStrLn \"Hello, lots of crap\" $ do\r\n a <- return 3\r\n -- The following line is mis-indented, the error is incomprehensible\r\n c <- do\r\n return 5\r\n}}}\r\nError:\r\n{{{\r\n<file>:2:3:\r\n Parse error in pattern: putStrLn\r\n Possibly caused by a missing 'do'?\r\n}}}\r\nThe hint about \"missing do\" exists from ghc 7.8, but is wrong in this case.\r\nProblematic about this bug is that the wrong indentation can be arbitrary many lines from where ghc reports the (totally incomprehensible) error. My original problem is to find the syntax error here:\r\n{{{#!hs\r\n-- | Type check a function clause.\r\ncheckClause :: Type -> A.SpineClause -> TCM Clause\r\ncheckClause t c@(A.Clause (A.SpineLHS i x aps withPats) rhs0 wh) = do\r\n unless (null withPats) $ do\r\n typeError $ UnexpectedWithPatterns withPats\r\n traceCall (CheckClause t c) $ do\r\n aps <- expandPatternSynonyms aps\r\n checkLeftHandSide (CheckPatternShadowing c) (Just x) aps t $\r\n \\ (LHSResult delta ps trhs perm) -> do\r\n -- Note that we might now be in irrelevant context,\r\n -- in case checkLeftHandSide walked over an irrelevant projection pattern.\r\n\r\n -- As we will be type-checking the @rhs@ in @delta@, but the final\r\n -- body should have bindings in the order of the pattern variables,\r\n -- we need to apply the permutation to the checked rhs @v@.\r\n let mkBody v = foldr (\\ x t -> Bind $ Abs x t) b xs\r\n where b = Body $ applySubst (renamingR perm) v\r\n xs = [ stringToArgName $ \"h\" ++ show n\r\n | n <- [0..permRange perm - 1] ]\r\n\r\n -- introduce trailing implicits for checking the where decls\r\n TelV htel t0 <- telViewUpTo' (-1) (not . visible) $ unArg trhs\r\n (body, with) <- do\r\n let n = size htel\r\n addCtxTel htel $ checkWhere (size delta + n) wh $\r\n -- for the body, we remove the implicits again\r\n escapeContext n $\r\n handleRHS aps (unArgs trhs) rhs0\r\n\r\n escapeContext (size delta) $ checkWithFunction with\r\n\r\n reportSDoc \"tc.lhs.top\" 10 $ escapeContext (size delta) $ vcat\r\n [ text \"Clause before translation:\"\r\n , nest 2 $ vcat\r\n [ text \"delta =\" <+> prettyTCM delta\r\n , text \"perm =\" <+> text (show perm)\r\n , text \"ps =\" <+> text (show ps)\r\n , text \"body =\" <+> text (show body)\r\n , text \"body =\" <+> prettyTCM body\r\n ]\r\n ]\r\n\r\n return $\r\n Clause { clauseRange = getRange i\r\n , clauseTel = killRange delta\r\n , clausePerm = perm\r\n , namedClausePats = ps\r\n , clauseBody = body\r\n , clauseType = Just trhs\r\n }\r\n}}}\r\n{{{\r\nsrc/full/Agda/TypeChecking/Rules/Def.hs:328:5:\r\n Parse error in pattern: checkLeftHandSide\r\n Possibly caused by a missing 'do'?\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.4.2https://gitlab.haskell.org/ghc/ghc/-/issues/5129"evaluate" optimized away2023-12-15T20:11:41Zdons"evaluate" optimized awayReported on Stackoverflow: http://stackoverflow.com/questions/5697159/testing-for-error-calls-in-hunit
With optimizations on, the following program, which normally succeeds (correctly generating an exception), instead fails, and the exc...Reported on Stackoverflow: http://stackoverflow.com/questions/5697159/testing-for-error-calls-in-hunit
With optimizations on, the following program, which normally succeeds (correctly generating an exception), instead fails, and the exception is optimized away.
```
import Control.Exception
import Test.HUnit
throwIfNegative :: Int -> String
throwIfNegative n | n < 0 = error "negative"
| otherwise = "no worries"
{-# NOINLINE throwIfNegative #-}
case_negative =
handleJust errorCalls (const $ return ()) $ do
evaluate $ throwIfNegative (-1)
assertFailure "must throw when given a negative number"
where errorCalls (ErrorCall _) = Just ()
main = runTestTT $ TestCase case_negative
```
Looking at the core, after a few iterations, the call to `throwIfNegative` is dropped as dead code.
Using seq instead of evaluate is happy enough:
```
case_negative =
handleJust errorCalls (const $ return ()) $ do
throwIfNegative (-1) `seq` assertFailure "must throw when given a negative number"
where errorCalls (ErrorCall _) = Just ()
```
or a bang pattern:
```
case_negative =
handleJust errorCalls (const $ return ()) $ do
let !x = throwIfNegative (-1)
assertFailure "must throw when given a negative number"
where errorCalls (ErrorCall _) = Just ()
```
Possibly related to #2273
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.0.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"\"evaluate\" optimized away","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.3","keywords":["evaluate","seq,"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Reported on Stackoverflow: http://stackoverflow.com/questions/5697159/testing-for-error-calls-in-hunit\r\n\r\nWith optimizations on, the following program, which normally succeeds (correctly generating an exception), instead fails, and the exception is optimized away.\r\n\r\n{{{\r\nimport Control.Exception\r\nimport Test.HUnit\r\n\r\nthrowIfNegative :: Int -> String\r\nthrowIfNegative n | n < 0 = error \"negative\"\r\n | otherwise = \"no worries\"\r\n{-# NOINLINE throwIfNegative #-}\r\n\r\ncase_negative =\r\n handleJust errorCalls (const $ return ()) $ do\r\n evaluate $ throwIfNegative (-1)\r\n assertFailure \"must throw when given a negative number\"\r\n where errorCalls (ErrorCall _) = Just ()\r\n\r\nmain = runTestTT $ TestCase case_negative\r\n}}}\r\n\r\nLooking at the core, after a few iterations, the call to `throwIfNegative` is dropped as dead code.\r\n\r\nUsing seq instead of evaluate is happy enough:\r\n\r\n{{{\r\ncase_negative =\r\n handleJust errorCalls (const $ return ()) $ do\r\n throwIfNegative (-1) `seq` assertFailure \"must throw when given a negative number\"\r\n where errorCalls (ErrorCall _) = Just ()\r\n}}}\r\n\r\nor a bang pattern:\r\n\r\n{{{\r\ncase_negative =\r\n handleJust errorCalls (const $ return ()) $ do\r\n let !x = throwIfNegative (-1)\r\n assertFailure \"must throw when given a negative number\"\r\n where errorCalls (ErrorCall _) = Just ()\r\n}}}\r\n\r\nPossibly related to #2273","type_of_failure":"OtherFailure","blocking":[]} -->8.4.2Simon MarlowSimon Marlow