GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:24:53Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/12852threadWaitReadSTM does not provide a way to unregister action.2019-07-07T18:24:53ZAlexander VershilovthreadWaitReadSTM does not provide a way to unregister action.In non-threaded RTS or on windows RTS does not return meaningful unregister action:
```hs
threadWaitWriteSTM :: Fd -> IO (Sync.STM (), IO ())
threadWaitWriteSTM fd
#ifndef mingw32_HOST_OS
| threaded = Event.threadWaitWriteSTM fd
#en...In non-threaded RTS or on windows RTS does not return meaningful unregister action:
```hs
threadWaitWriteSTM :: Fd -> IO (Sync.STM (), IO ())
threadWaitWriteSTM fd
#ifndef mingw32_HOST_OS
| threaded = Event.threadWaitWriteSTM fd
#endif
| otherwise = do
m <- Sync.newTVarIO False
_ <- Sync.forkIO $ do
threadWaitWrite fd
Sync.atomically $ Sync.writeTVar m True
let waitAction = do b <- Sync.readTVar m
if b then return () else retry
let killAction = return ()
return (waitAction, killAction)
```
As a result in case if data will never arrive, helper thread will never be deallocated. This may lead to a memory leaks in some cases, see https://github.com/lpeterse/haskell-socket/issues/27 for details.
Minimal testcase is:
```hs
import GHC.Conc
import GHC.IO
import GHC.IO.FD as FD
import System.Posix.IO
import System.Posix.Types
main = do
(rfd,wfd) <- createPipe
(waitread, unregister) <- threadWaitReadSTM rfd
unregister
result0 <- atomically $ (fmap (const False) waitread) `orElse` return True
print result0
fdWrite wfd "test"
threadDelay 20000
result1 <- atomically $ (fmap (const False) waitread) `orElse` return True
print result1
(waitread1, _) <- threadWaitReadSTM rfd
threadDelay 20000
result2 <- atomically $ (fmap (const True) waitread1) `orElse` return False
print result2
```
Expected output will be True, True, True, but non-threaded runtime gives True, False, True
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Core Libraries |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ekmett |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"threadWaitReadSTM does not provide a way to unregister action.","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ekmett"],"type":"Bug","description":"In non-threaded RTS or on windows RTS does not return meaningful unregister action:\r\n\r\n{{{#!hs\r\nthreadWaitWriteSTM :: Fd -> IO (Sync.STM (), IO ())\r\nthreadWaitWriteSTM fd \r\n#ifndef mingw32_HOST_OS\r\n | threaded = Event.threadWaitWriteSTM fd\r\n#endif\r\n | otherwise = do\r\n m <- Sync.newTVarIO False\r\n _ <- Sync.forkIO $ do\r\n threadWaitWrite fd\r\n Sync.atomically $ Sync.writeTVar m True\r\n let waitAction = do b <- Sync.readTVar m\r\n if b then return () else retry\r\n let killAction = return ()\r\n return (waitAction, killAction)\r\n}}}\r\n\r\nAs a result in case if data will never arrive, helper thread will never be deallocated. This may lead to a memory leaks in some cases, see https://github.com/lpeterse/haskell-socket/issues/27 for details.\r\n\r\nMinimal testcase is:\r\n{{{#!hs\r\nimport GHC.Conc\r\nimport GHC.IO\r\nimport GHC.IO.FD as FD\r\nimport System.Posix.IO\r\nimport System.Posix.Types\r\n\r\nmain = do\r\n (rfd,wfd) <- createPipe\r\n (waitread, unregister) <- threadWaitReadSTM rfd\r\n unregister\r\n result0 <- atomically $ (fmap (const False) waitread) `orElse` return True\r\n print result0\r\n fdWrite wfd \"test\"\r\n threadDelay 20000\r\n result1 <- atomically $ (fmap (const False) waitread) `orElse` return True\r\n print result1\r\n (waitread1, _) <- threadWaitReadSTM rfd\r\n threadDelay 20000\r\n result2 <- atomically $ (fmap (const True) waitread1) `orElse` return False\r\n print result2\r\n}}}\r\n\r\nExpected output will be True, True, True, but non-threaded runtime gives True, False, True","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12849hsc2hs trouble with floating-point constants in cross-compilation mode2021-11-10T13:28:50Zrwbartonhsc2hs trouble with floating-point constants in cross-compilation modeSplit off from #7983.
GCC 4.6 rejects some uses of floating-point constants in the declaration of a local static array. From [ticket:7983\#comment:109626](https://gitlab.haskell.org//ghc/ghc/issues/7983#note_109626):
> This is caused b...Split off from #7983.
GCC 4.6 rejects some uses of floating-point constants in the declaration of a local static array. From [ticket:7983\#comment:109626](https://gitlab.haskell.org//ghc/ghc/issues/7983#note_109626):
> This is caused by a regression in GCC from gcc-4.4 to gcc-4.6: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46028
>
> ```
> $ cat Test_hsc_test0.c
> void _hsc2hs_test1()
> {
> static int test_array[(89.) > 0 ? 2 : 1];
> }
>
> $ /usr/bin/gcc-4.4 -c ./Test_hsc_test0.c
>
> $ /usr/bin/gcc-4.6 -c ./Test_hsc_test0.c
> ./Test_hsc_test0.c: In function ‘_hsc2hs_test1’:
> ./Test_hsc_test0.c:3:16: error: storage size of ‘test_array’ isn’t constant
> ```
This means that (if your C compiler is affected by this issue) hsc2hs can't handle
```
(#const 89.)
```
in cross-compilation mode.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | hsc2hs |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"hsc2hs trouble with floating-point constants in cross-compilation mode","status":"New","operating_system":"","component":"hsc2hs","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Split off from #7983.\r\n\r\nGCC 4.6 rejects some uses of floating-point constants in the declaration of a local static array. From ticket:7983#comment:5:\r\n\r\n> This is caused by a regression in GCC from gcc-4.4 to gcc-4.6: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46028\r\n>\r\n> {{{\r\n> $ cat Test_hsc_test0.c\r\n> void _hsc2hs_test1()\r\n> {\r\n> static int test_array[(89.) > 0 ? 2 : 1];\r\n> }\r\n> \r\n> $ /usr/bin/gcc-4.4 -c ./Test_hsc_test0.c\r\n> \r\n> $ /usr/bin/gcc-4.6 -c ./Test_hsc_test0.c\r\n> ./Test_hsc_test0.c: In function ‘_hsc2hs_test1’:\r\n> ./Test_hsc_test0.c:3:16: error: storage size of ‘test_array’ isn’t constant\r\n> }}}\r\n\r\nThis means that (if your C compiler is affected by this issue) hsc2hs can't handle\r\n{{{\r\n(#const 89.)\r\n}}}\r\nin cross-compilation mode.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12841Remove or explain target triple normalization2019-07-07T18:24:56ZShea Levyshea@shealevy.comRemove or explain target triple normalizationCurrently during configure, GHC normalizes the triple passed e.g. with --target. It's not clear why this happens, and it has caused problems in the past (See #12840, #12487), so we should probably either just remove the GHC triples altog...Currently during configure, GHC normalizes the triple passed e.g. with --target. It's not clear why this happens, and it has caused problems in the past (See #12840, #12487), so we should probably either just remove the GHC triples altogether or add some explanations for why they're around.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Remove or explain target triple normalization","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Currently during configure, GHC normalizes the triple passed e.g. with --target. It's not clear why this happens, and it has caused problems in the past (See #12840, #12487), so we should probably either just remove the GHC triples altogether or add some explanations for why they're around.","type_of_failure":"OtherFailure","blocking":[]} -->John EricsonJohn Ericsonhttps://gitlab.haskell.org/ghc/ghc/-/issues/12832GHC infers too simplified contexts2019-07-07T18:24:58Zdanilo2GHC infers too simplified contextsI'm almost sure it was working well in GHC 7.\*.
Let's consider this simple example:
```
{-# LANGUAGE NoMonomorphismRestriction #-}
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE EmptyDataDecls #-...I'm almost sure it was working well in GHC 7.\*.
Let's consider this simple example:
```
{-# LANGUAGE NoMonomorphismRestriction #-}
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE EmptyDataDecls #-}
module Main where
import Prelude
class Monad m => Foo m
class Monad m => Bar m
class Monad m => Baz m
data IM a
data I
impossible = error "impossible"
class Test m a where test :: a -> m ()
instance {-# OVERLAPPABLE #-} (Foo m, Bar m, Baz m) => Test m a where test _ = return ()
instance {-# OVERLAPPABLE #-} Test IM a where test = impossible
class Run m a where run :: a -> m ()
main :: IO ()
main = return ()
```
it compiles and runs fine. What should happen when we add the following def?
```
instance Run m Int where
run = test
```
We SHOULD get an error that there is `No instance for (Test m Int) arising from a use of ‘test’`. Instead we get very strange one `No instance for (Foo m) arising from a use of ‘test’.` If we add it, we get the next one `No instance for (Bar m) arising from a use of ‘test’.` etc ...
If we comment out the first overlappable instance, we get proper error about missing `Test m Int` context. In fact if we add context `Test m Int` it works in every case, only the inferred error is just wrong.
This is a serious problem and here is why. Imagine that we create an API for end-user and we give him the `test` function. Moreover, we know that expanding the context would not bring any further info unless `m` is known. If we create such "impossible" instances like in the example, user will get a very simple error message about a missing context. Right now user gets a big error stack about missing expanded contexts instead of simple one.https://gitlab.haskell.org/ghc/ghc/-/issues/12829Multiline input (‘:set +m’) terminated by trailing whitespace2019-07-07T18:24:59ZIcelandjackMultiline input (‘:set +m’) terminated by trailing whitespace```
$ ghci -ignore-dot-ghci
GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help
Prelude> :set +m
Prelude> let
Prelude| a :: Int
Prelude| a = 5
Prelude|
Prelude>
```
works fine with [multiline input](https://downloads.haskell...```
$ ghci -ignore-dot-ghci
GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help
Prelude> :set +m
Prelude> let
Prelude| a :: Int
Prelude| a = 5
Prelude|
Prelude>
```
works fine with [multiline input](https://downloads.haskell.org/~ghc/master/users-guide/ghci.html#multiline-input), but if you add one trailing space it immediately terminates the input
```
Prelude> let
Prelude| a :: Int␣
<interactive>:11:1: error:
The type signature for ‘a’ lacks an accompanying binding
```
I don't know if this is the desired behavior but this means I can't copy/paste code into GHCi that has a trailing whitespace.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| 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":"Multiline input (‘:set +m’) terminated by trailing whitespace","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\n$ ghci -ignore-dot-ghci\r\nGHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help\r\nPrelude> :set +m\r\nPrelude> let\r\nPrelude| a :: Int\r\nPrelude| a = 5\r\nPrelude| \r\nPrelude> \r\n}}}\r\n\r\nworks fine with [https://downloads.haskell.org/~ghc/master/users-guide/ghci.html#multiline-input multiline input], but if you add one trailing space it immediately terminates the input\r\n\r\n{{{\r\nPrelude> let\r\nPrelude| a :: Int␣\r\n\r\n<interactive>:11:1: error:\r\n The type signature for ‘a’ lacks an accompanying binding\r\n}}}\r\n\r\nI don't know if this is the desired behavior but this means I can't copy/paste code into GHCi that has a trailing whitespace.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12823Inconsistency in acceptance of equality constraints in different forms2019-07-07T18:25:00ZDavid FeuerInconsistency in acceptance of equality constraints in different formsCurrently, we (correctly) require a language extension to accept a declaration like
<table><tr><th>foo </th>
<td>a \~ b =\> f a -\> f b</td></tr>
<tr><td></td>
<td>foo x = x</td></tr></table>
Suppose I write
```hs
{-# LANGUAGE GADTs, ...Currently, we (correctly) require a language extension to accept a declaration like
<table><tr><th>foo </th>
<td>a \~ b =\> f a -\> f b</td></tr>
<tr><td></td>
<td>foo x = x</td></tr></table>
Suppose I write
```hs
{-# LANGUAGE GADTs, UndecidableInstances, ConstraintKinds #-}
module A where
class a ~ b => Equal a b
instance a ~ b => Equal a b
type EqualS a b = a ~ b
```
and then
```hs
-- No extensions
module B where
-- This works
useEqual :: Equal a b => f a -> f b
useEqual x = x
-- But this does not
useEqualF :: EqualF a b => f a -> f b
useEqualF x = x
```
It seems that GHC expands type synonyms, but does not reduce constraints, before deciding whether enough extensions are in play to allow equality constraints. This mismatch feels weird. Is there something about `~` proper, and not `Equal`, that triggers the difficulties with let generalization? If not, I think they should either both work or both fail (probably both fail).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.0.1 |
| Type | FeatureRequest |
| 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":"Inconsistency in acceptance of equality constraints in different forms","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":["GADTs"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Currently, we (correctly) require a language extension to accept a declaration like\r\n\r\n foo :: a ~ b => f a -> f b\r\n foo x = x\r\n\r\nSuppose I write\r\n\r\n{{{#!hs\r\n{-# LANGUAGE GADTs, UndecidableInstances, ConstraintKinds #-}\r\nmodule A where\r\nclass a ~ b => Equal a b\r\ninstance a ~ b => Equal a b\r\n\r\ntype EqualS a b = a ~ b\r\n}}}\r\n\r\nand then\r\n\r\n{{{#!hs\r\n-- No extensions\r\nmodule B where\r\n\r\n-- This works\r\nuseEqual :: Equal a b => f a -> f b\r\nuseEqual x = x\r\n\r\n-- But this does not\r\nuseEqualF :: EqualF a b => f a -> f b\r\nuseEqualF x = x\r\n}}}\r\n\r\nIt seems that GHC expands type synonyms, but does not reduce constraints, before deciding whether enough extensions are in play to allow equality constraints. This mismatch feels weird. Is there something about `~` proper, and not `Equal`, that triggers the difficulties with let generalization? If not, I think they should either both work or both fail (probably both fail).","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12822Cleanup GHC verbosity flags2019-07-07T18:25:00ZSylvain HenryCleanup GHC verbosity flags1) In the discussion of [D2679](https://phabricator.haskell.org/D2679)#77898, Simon Marlow suggested that we make verbosity levels (`-v0`, `-v1`...) work just like optimization levels (`-O0`, `-O1`...), i.e., that we make each verbosity ...1) In the discussion of [D2679](https://phabricator.haskell.org/D2679)#77898, Simon Marlow suggested that we make verbosity levels (`-v0`, `-v1`...) work just like optimization levels (`-O0`, `-O1`...), i.e., that we make each verbosity level a collection of verbosity flags.
Currently the verbosity level is tested against explicitly in several places in GHC's code.
2) Homogenize verbosity flags: currently, flags that change GHC's reporting have various prefixes:
> - `-fprint-*`
> - `-fshow-*`
> - `-dshow-passes`
> - `-ddump-*`
> - `-dppr-*`
> - `-dverbose-*`
Maybe we should homogenize (some of) them by using a common `-v` prefix as in `-vshow-source-paths`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Cleanup GHC verbosity flags","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":["newcomer,flags"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"1) In the discussion of Phab:D2679#77898, Simon Marlow suggested that we make verbosity levels (`-v0`, `-v1`...) work just like optimization levels (`-O0`, `-O1`...), i.e., that we make each verbosity level a collection of verbosity flags.\r\n\r\nCurrently the verbosity level is tested against explicitly in several places in GHC's code.\r\n\r\n2) Homogenize verbosity flags: currently, flags that change GHC's reporting have various prefixes:\r\n - `-fprint-*`\r\n - `-fshow-*`\r\n - `-dshow-passes`\r\n - `-ddump-*`\r\n - `-dppr-*`\r\n - `-dverbose-*`\r\nMaybe we should homogenize (some of) them by using a common `-v` prefix as in `-vshow-source-paths`.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12820Regression around pattern synonyms and higher-rank types2019-07-07T18:25:01ZRichard Eisenbergrae@richarde.devRegression around pattern synonyms and higher-rank typesGHC 8.0.1 accepts, but HEAD rejects:
```hs
{-# LANGUAGE PatternSynonyms, RankNTypes, ViewPatterns #-}
module Bug where
pattern P :: (forall a. a -> a) -> String
pattern P x <- (\ _ -> id -> x)
```
(Sidenote: kudos to the parser on fi...GHC 8.0.1 accepts, but HEAD rejects:
```hs
{-# LANGUAGE PatternSynonyms, RankNTypes, ViewPatterns #-}
module Bug where
pattern P :: (forall a. a -> a) -> String
pattern P x <- (\ _ -> id -> x)
```
(Sidenote: kudos to the parser on figuring out my view pattern.)
HEAD gives this error:
```
Bug.hs:6:30: error:
• Couldn't match expected type ‘forall a. a -> a’
with actual type ‘a0 -> a0’
• In the declaration for pattern synonym ‘P’
• Relevant bindings include x :: a0 -> a0 (bound at Bug.hs:6:30)
```
The code looks correct to me.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.1 |
| 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":"Regression around pattern synonyms and higher-rank types","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"GHC 8.0.1 accepts, but HEAD rejects:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE PatternSynonyms, RankNTypes, ViewPatterns #-}\r\n\r\nmodule Bug where\r\n\r\npattern P :: (forall a. a -> a) -> String\r\npattern P x <- (\\ _ -> id -> x)\r\n}}}\r\n\r\n(Sidenote: kudos to the parser on figuring out my view pattern.)\r\n\r\nHEAD gives this error:\r\n\r\n{{{\r\nBug.hs:6:30: error:\r\n • Couldn't match expected type ‘forall a. a -> a’\r\n with actual type ‘a0 -> a0’\r\n • In the declaration for pattern synonym ‘P’\r\n • Relevant bindings include x :: a0 -> a0 (bound at Bug.hs:6:30)\r\n}}}\r\n\r\nThe code looks correct to me.","type_of_failure":"OtherFailure","blocking":[]} -->Richard Eisenbergrae@richarde.devRichard Eisenbergrae@richarde.devhttps://gitlab.haskell.org/ghc/ghc/-/issues/12818Allow reify to find top-level bindings in later declaration groups2019-07-07T18:25:01ZFacundo DomínguezAllow reify to find top-level bindings in later declaration groupsSome time ago, at Tweag we were considering inspecting the types of declarations added with `addTopDecls` like this:
```
{-# LANGUAGE TemplateHaskell #-}
import Language.Haskell.TH.Syntax
main :: IO ()
main =
$(do
ds <- [d| f...Some time ago, at Tweag we were considering inspecting the types of declarations added with `addTopDecls` like this:
```
{-# LANGUAGE TemplateHaskell #-}
import Language.Haskell.TH.Syntax
main :: IO ()
main =
$(do
ds <- [d| f = True |]
addTopDecls ds
addModFinalizer $ do
VarI _ t _ <- reify (mkName "f")
runIO $ hPutStrLn stderr ("f :: " ++ show t)
[| return () |]
)
```
`f` is not in scope when the finalizer is added. But its type would be known when the finalizer runs.
This worked before the patch https://phabricator.haskell.org/D2286.
There is a patch that we submitted to address this https://phabricator.haskell.org/D2519, but it turned out later that we didn't need it and the patch was considered less than ideal.
We are opening this ticket to keep track of the nuance in case someone finds the patch useful later.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Template Haskell |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | mboes, simonpj |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Allow reify to find top-level bindings in later declaration groups","status":"New","operating_system":"","component":"Template Haskell","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["mboes","simonpj"],"type":"Bug","description":"Some time ago, at Tweag we were considering inspecting the types of declarations added with `addTopDecls` like this:\r\n\r\n{{{\r\n{-# LANGUAGE TemplateHaskell #-}\r\nimport Language.Haskell.TH.Syntax\r\n\r\nmain :: IO ()\r\nmain =\r\n $(do\r\n ds <- [d| f = True |]\r\n addTopDecls ds\r\n addModFinalizer $ do\r\n VarI _ t _ <- reify (mkName \"f\")\r\n runIO $ hPutStrLn stderr (\"f :: \" ++ show t)\r\n [| return () |]\r\n )\r\n}}}\r\n`f` is not in scope when the finalizer is added. But its type would be known when the finalizer runs.\r\n\r\nThis worked before the patch https://phabricator.haskell.org/D2286.\r\nThere is a patch that we submitted to address this https://phabricator.haskell.org/D2519, but it turned out later that we didn't need it and the patch was considered less than ideal.\r\n\r\nWe are opening this ticket to keep track of the nuance in case someone finds the patch useful later.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12817Degraded performance with constraint synonyms2019-07-07T18:25:02ZEric CrockettDegraded performance with constraint synonymsThe attached bug demonstrates how using constraint synonyms can negatively impact performance.
I have two functions which are identical, except that one uses a constraint synonym:
```
type CElt r = (Num r, Eq r)
fooSlow :: (CElt r) =>...The attached bug demonstrates how using constraint synonyms can negatively impact performance.
I have two functions which are identical, except that one uses a constraint synonym:
```
type CElt r = (Num r, Eq r)
fooSlow :: (CElt r) => Bar r -> Bar r
{-# INLINABLE fooSlow #-}
fooSlow (C1 u) = either (fromEitherBar . eitherFoo) (fromEitherBar . eitherFoo) u
fooSlow (C2 c) = C2 $ fooSlow c
fooFast :: (Num r, Eq r) => Bar r -> Bar r
{-# INLINABLE fooFast #-}
fooFast (C1 u) = either (fromEitherBar . eitherFoo) (fromEitherBar . eitherFoo) u
fooFast (C2 c) = C2 $ fooFast c
```
Using criterion, `fooSlow` is about 3x slower than `fooFast`. Main.hs needs `criterion` and `deepseq`, but the problem should be evident just from inspecting the core of Bar.hs, which only relies on `base`. Code was compiled with GHC-8.0.1 with `-O2`.
For some context, in my real code from which this example was extracted, the 'fast' (no constraint synonym) version takes 78 microseconds, while the 'slow' version with the synonym takes 360 microseconds.https://gitlab.haskell.org/ghc/ghc/-/issues/12813GHC panic when installing haskell-opencv with nix2019-07-07T18:25:03ZturionGHC panic when installing haskell-opencv with nixI installed https://github.com/LumiGuide/haskell-opencv using their recommended build system "nix", i.e. starting nix-shell in the cloned repository, waiting half an hour for several builds to complete and then doing the following from w...I installed https://github.com/LumiGuide/haskell-opencv using their recommended build system "nix", i.e. starting nix-shell in the cloned repository, waiting half an hour for several builds to complete and then doing the following from within the nix-shell:
```
[nix-shell:~/haskell-opencv]$ cabal build
Package has never been configured. Configuring with default flags. If this
fails, please run configure manually.
Resolving dependencies...
[1 of 1] Compiling Main ( dist/setup/setup.hs, dist/setup/Main.o )
Linking ./dist/setup/setup ...
Configuring opencv-0.0.0...
Building opencv-0.0.0...
Preprocessing library opencv-0.0.0...
In file included from Types.hsc:96:0:
/nix/store/ybmw9vbx8s8791lc7iggf8yd88kgwmxs-bindings-DSL-1.0.23/lib/ghc-8.0.1/bindings-DSL-1.0.23/include/bindings.dsl.h:191:3: Warnung: »bc_fielddata« definiert, aber nicht verwendet [-Wunused-variable]
} bc_fielddata;
^
In file included from Features2d.hsc:69:0:
/nix/store/ybmw9vbx8s8791lc7iggf8yd88kgwmxs-bindings-DSL-1.0.23/lib/ghc-8.0.1/bindings-DSL-1.0.23/include/bindings.dsl.h:191:3: Warnung: »bc_fielddata« definiert, aber nicht verwendet [-Wunused-variable]
} bc_fielddata;
^
In file included from HighGui.hsc:87:0:
/nix/store/ybmw9vbx8s8791lc7iggf8yd88kgwmxs-bindings-DSL-1.0.23/lib/ghc-8.0.1/bindings-DSL-1.0.23/include/bindings.dsl.h:191:3: Warnung: »bc_fielddata« definiert, aber nicht verwendet [-Wunused-variable]
} bc_fielddata;
^
In file included from ColorMaps.hsc:28:0:
/nix/store/ybmw9vbx8s8791lc7iggf8yd88kgwmxs-bindings-DSL-1.0.23/lib/ghc-8.0.1/bindings-DSL-1.0.23/include/bindings.dsl.h:191:3: Warnung: »bc_fielddata« definiert, aber nicht verwendet [-Wunused-variable]
} bc_fielddata;
^
In file included from Drawing.hsc:52:0:
/nix/store/ybmw9vbx8s8791lc7iggf8yd88kgwmxs-bindings-DSL-1.0.23/lib/ghc-8.0.1/bindings-DSL-1.0.23/include/bindings.dsl.h:191:3: Warnung: »bc_fielddata« definiert, aber nicht verwendet [-Wunused-variable]
} bc_fielddata;
^
In file included from GeometricImgTransform.hsc:81:0:
/nix/store/ybmw9vbx8s8791lc7iggf8yd88kgwmxs-bindings-DSL-1.0.23/lib/ghc-8.0.1/bindings-DSL-1.0.23/include/bindings.dsl.h:191:3: Warnung: »bc_fielddata« definiert, aber nicht verwendet [-Wunused-variable]
} bc_fielddata;
^
In file included from ImgFiltering.hsc:72:0:
/nix/store/ybmw9vbx8s8791lc7iggf8yd88kgwmxs-bindings-DSL-1.0.23/lib/ghc-8.0.1/bindings-DSL-1.0.23/include/bindings.dsl.h:191:3: Warnung: »bc_fielddata« definiert, aber nicht verwendet [-Wunused-variable]
} bc_fielddata;
^
In file included from ObjectDetection.hsc:36:0:
/nix/store/ybmw9vbx8s8791lc7iggf8yd88kgwmxs-bindings-DSL-1.0.23/lib/ghc-8.0.1/bindings-DSL-1.0.23/include/bindings.dsl.h:191:3: Warnung: »bc_fielddata« definiert, aber nicht verwendet [-Wunused-variable]
} bc_fielddata;
^
In file included from StructuralAnalysis.hsc:47:0:
/nix/store/ybmw9vbx8s8791lc7iggf8yd88kgwmxs-bindings-DSL-1.0.23/lib/ghc-8.0.1/bindings-DSL-1.0.23/include/bindings.dsl.h:191:3: Warnung: »bc_fielddata« definiert, aber nicht verwendet [-Wunused-variable]
} bc_fielddata;
^
In file included from Video.hsc:32:0:
/nix/store/ybmw9vbx8s8791lc7iggf8yd88kgwmxs-bindings-DSL-1.0.23/lib/ghc-8.0.1/bindings-DSL-1.0.23/include/bindings.dsl.h:191:3: Warnung: »bc_fielddata« definiert, aber nicht verwendet [-Wunused-variable]
} bc_fielddata;
^
In file included from MotionAnalysis.hsc:44:0:
/nix/store/ybmw9vbx8s8791lc7iggf8yd88kgwmxs-bindings-DSL-1.0.23/lib/ghc-8.0.1/bindings-DSL-1.0.23/include/bindings.dsl.h:191:3: Warnung: »bc_fielddata« definiert, aber nicht verwendet [-Wunused-variable]
} bc_fielddata;
^
In file included from Constants.hsc:9:0:
/nix/store/ybmw9vbx8s8791lc7iggf8yd88kgwmxs-bindings-DSL-1.0.23/lib/ghc-8.0.1/bindings-DSL-1.0.23/include/bindings.dsl.h:191:3: Warnung: »bc_fielddata« definiert, aber nicht verwendet [-Wunused-variable]
} bc_fielddata;
^
In file included from ArrayOps.hsc:19:0:
/nix/store/ybmw9vbx8s8791lc7iggf8yd88kgwmxs-bindings-DSL-1.0.23/lib/ghc-8.0.1/bindings-DSL-1.0.23/include/bindings.dsl.h:191:3: Warnung: »bc_fielddata« definiert, aber nicht verwendet [-Wunused-variable]
} bc_fielddata;
^
In file included from Constants.hsc:9:0:
/nix/store/ybmw9vbx8s8791lc7iggf8yd88kgwmxs-bindings-DSL-1.0.23/lib/ghc-8.0.1/bindings-DSL-1.0.23/include/bindings.dsl.h:191:3: Warnung: »bc_fielddata« definiert, aber nicht verwendet [-Wunused-variable]
} bc_fielddata;
^
In file included from Marshal.hsc:21:0:
/nix/store/ybmw9vbx8s8791lc7iggf8yd88kgwmxs-bindings-DSL-1.0.23/lib/ghc-8.0.1/bindings-DSL-1.0.23/include/bindings.dsl.h:191:3: Warnung: »bc_fielddata« definiert, aber nicht verwendet [-Wunused-variable]
} bc_fielddata;
^
In file included from ImgCodecs.hsc:31:0:
/nix/store/ybmw9vbx8s8791lc7iggf8yd88kgwmxs-bindings-DSL-1.0.23/lib/ghc-8.0.1/bindings-DSL-1.0.23/include/bindings.dsl.h:191:3: Warnung: »bc_fielddata« definiert, aber nicht verwendet [-Wunused-variable]
} bc_fielddata;
^
In file included from MiscImgTransform.hsc:14:0:
/nix/store/ybmw9vbx8s8791lc7iggf8yd88kgwmxs-bindings-DSL-1.0.23/lib/ghc-8.0.1/bindings-DSL-1.0.23/include/bindings.dsl.h:191:3: Warnung: »bc_fielddata« definiert, aber nicht verwendet [-Wunused-variable]
} bc_fielddata;
^
In file included from Types.hsc:18:0:
/nix/store/ybmw9vbx8s8791lc7iggf8yd88kgwmxs-bindings-DSL-1.0.23/lib/ghc-8.0.1/bindings-DSL-1.0.23/include/bindings.dsl.h:191:3: Warnung: »bc_fielddata« definiert, aber nicht verwendet [-Wunused-variable]
} bc_fielddata;
^
In file included from Constants.hsc:9:0:
/nix/store/ybmw9vbx8s8791lc7iggf8yd88kgwmxs-bindings-DSL-1.0.23/lib/ghc-8.0.1/bindings-DSL-1.0.23/include/bindings.dsl.h:191:3: Warnung: »bc_fielddata« definiert, aber nicht verwendet [-Wunused-variable]
} bc_fielddata;
^
In file included from Constants.hsc:11:0:
/nix/store/ybmw9vbx8s8791lc7iggf8yd88kgwmxs-bindings-DSL-1.0.23/lib/ghc-8.0.1/bindings-DSL-1.0.23/include/bindings.dsl.h:191:3: Warnung: »bc_fielddata« definiert, aber nicht verwendet [-Wunused-variable]
} bc_fielddata;
^
[ 1 of 70] Compiling OpenCV.Internal.VideoIO.Constants ( dist/build/OpenCV/Internal/VideoIO/Constants.hs, dist/build/OpenCV/Internal/VideoIO/Constants.o )
[ 2 of 70] Compiling OpenCV.Internal.VideoIO.Types ( src/OpenCV/Internal/VideoIO/Types.hs, dist/build/OpenCV/Internal/VideoIO/Types.o )
[ 3 of 70] Compiling OpenCV.VideoIO.Types ( src/OpenCV/VideoIO/Types.hs, dist/build/OpenCV/VideoIO/Types.o )
[ 4 of 70] Compiling OpenCV.Internal.Photo.Constants ( dist/build/OpenCV/Internal/Photo/Constants.hs, dist/build/OpenCV/Internal/Photo/Constants.o )
[ 5 of 70] Compiling OpenCV.Internal.ImgProc.MiscImgTransform ( dist/build/OpenCV/Internal/ImgProc/MiscImgTransform.hs, dist/build/OpenCV/Internal/ImgProc/MiscImgTransform.o )
[ 6 of 70] Compiling OpenCV.Internal.ImgCodecs ( dist/build/OpenCV/Internal/ImgCodecs.hs, dist/build/OpenCV/Internal/ImgCodecs.o )
[ 7 of 70] Compiling OpenCV.Internal.Core.Types.Constants ( dist/build/OpenCV/Internal/Core/Types/Constants.hs, dist/build/OpenCV/Internal/Core/Types/Constants.o )
[ 8 of 70] Compiling OpenCV.Internal.C.PlacementNew ( src/OpenCV/Internal/C/PlacementNew.hs, dist/build/OpenCV/Internal/C/PlacementNew.o )
[ 9 of 70] Compiling OpenCV.Internal.C.PlacementNew.TH ( src/OpenCV/Internal/C/PlacementNew/TH.hs, dist/build/OpenCV/Internal/C/PlacementNew/TH.o )
[10 of 70] Compiling OpenCV.Internal.Mutable ( src/OpenCV/Internal/Mutable.hs, dist/build/OpenCV/Internal/Mutable.o )
[11 of 70] Compiling OpenCV.Internal.Core.ArrayOps ( dist/build/OpenCV/Internal/Core/ArrayOps.hs, dist/build/OpenCV/Internal/Core/ArrayOps.o )
[12 of 70] Compiling OpenCV.Internal ( src/OpenCV/Internal.hs, dist/build/OpenCV/Internal.o )
[13 of 70] Compiling OpenCV.Internal.Calib3d.Constants ( dist/build/OpenCV/Internal/Calib3d/Constants.hs, dist/build/OpenCV/Internal/Calib3d/Constants.o )
[14 of 70] Compiling OpenCV.Internal.C.Types ( src/OpenCV/Internal/C/Types.hs, dist/build/OpenCV/Internal/C/Types.o )
[15 of 70] Compiling OpenCV.Internal.Core.Types.Matx ( src/OpenCV/Internal/Core/Types/Matx.hs, dist/build/OpenCV/Internal/Core/Types/Matx.o )
[16 of 70] Compiling OpenCV.Internal.Core.Types.Matx.TH ( src/OpenCV/Internal/Core/Types/Matx/TH.hs, dist/build/OpenCV/Internal/Core/Types/Matx/TH.o )
[17 of 70] Compiling OpenCV.Internal.Core.Types.Point ( src/OpenCV/Internal/Core/Types/Point.hs, dist/build/OpenCV/Internal/Core/Types/Point.o )
[18 of 70] Compiling OpenCV.Internal.Core.Types.Point.TH ( src/OpenCV/Internal/Core/Types/Point/TH.hs, dist/build/OpenCV/Internal/Core/Types/Point/TH.o )
[19 of 70] Compiling OpenCV.Internal.Core.Types.Size ( src/OpenCV/Internal/Core/Types/Size.hs, dist/build/OpenCV/Internal/Core/Types/Size.o )
[20 of 70] Compiling OpenCV.Internal.Core.Types.Size.TH ( src/OpenCV/Internal/Core/Types/Size/TH.hs, dist/build/OpenCV/Internal/Core/Types/Size/TH.o )
[21 of 70] Compiling OpenCV.Internal.Core.Types.Vec ( src/OpenCV/Internal/Core/Types/Vec.hs, dist/build/OpenCV/Internal/Core/Types/Vec.o )
[22 of 70] Compiling OpenCV.Internal.Core.Types.Vec.TH ( src/OpenCV/Internal/Core/Types/Vec/TH.hs, dist/build/OpenCV/Internal/Core/Types/Vec/TH.o )
[23 of 70] Compiling OpenCV.Internal.C.Inline ( src/OpenCV/Internal/C/Inline.hs, dist/build/OpenCV/Internal/C/Inline.o )
[24 of 70] Compiling OpenCV.Core.Types.Size ( src/OpenCV/Core/Types/Size.hs, dist/build/OpenCV/Core/Types/Size.o )
[25 of 70] Compiling OpenCV.Core.Types.Vec ( src/OpenCV/Core/Types/Vec.hs, dist/build/OpenCV/Core/Types/Vec.o )
[26 of 70] Compiling OpenCV.TypeLevel ( src/OpenCV/TypeLevel.hs, dist/build/OpenCV/TypeLevel.o )
[27 of 70] Compiling OpenCV.Internal.ImgProc.MiscImgTransform.TypeLevel ( src/OpenCV/Internal/ImgProc/MiscImgTransform/TypeLevel.hs, dist/build/OpenCV/Internal/ImgProc/MiscImgTransform/TypeLevel.o )
[28 of 70] Compiling OpenCV.Internal.ImgProc.MiscImgTransform.ColorCodes ( src/OpenCV/Internal/ImgProc/MiscImgTransform/ColorCodes.hs, dist/build/OpenCV/Internal/ImgProc/MiscImgTransform/ColorCodes.o )
[29 of 70] Compiling OpenCV.ImgProc.MiscImgTransform.ColorCodes ( src/OpenCV/ImgProc/MiscImgTransform/ColorCodes.hs, dist/build/OpenCV/ImgProc/MiscImgTransform/ColorCodes.o )
[30 of 70] Compiling OpenCV.Internal.Core.Types.Mat.Depth ( src/OpenCV/Internal/Core/Types/Mat/Depth.hs, dist/build/OpenCV/Internal/Core/Types/Mat/Depth.o )
[31 of 70] Compiling OpenCV.Internal.Exception ( src/OpenCV/Internal/Exception.hs, dist/build/OpenCV/Internal/Exception.o )
[32 of 70] Compiling OpenCV.Exception ( src/OpenCV/Exception.hs, dist/build/OpenCV/Exception.o )
[33 of 70] Compiling OpenCV.Internal.Core.Types.Mat.Marshal ( dist/build/OpenCV/Internal/Core/Types/Mat/Marshal.hs, dist/build/OpenCV/Internal/Core/Types/Mat/Marshal.o )
[34 of 70] Compiling OpenCV.Core.Types.Point ( src/OpenCV/Core/Types/Point.hs, dist/build/OpenCV/Core/Types/Point.o )
[35 of 70] Compiling OpenCV.Internal.Core.Types ( src/OpenCV/Internal/Core/Types.hs, dist/build/OpenCV/Internal/Core/Types.o )
[36 of 70] Compiling OpenCV.Internal.Core.Types.Mat ( src/OpenCV/Internal/Core/Types/Mat.hs, dist/build/OpenCV/Internal/Core/Types/Mat.o )
<no location info>: error:
ghc: panic! (the 'impossible' happened)
(GHC version 8.0.1 for x86_64-unknown-linux):
Loading temp shared object failed: /run/user/1000/ghc26419_0/libghc_275.so: undefined symbol: inline_c_OpenCV_Internal_Exception_1_2402dbf3aea4f7f79392b71ed42618962a22e9aa
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
[39 of 70] Compiling OpenCV.Internal.Core.Types.Rect ( src/OpenCV/Internal/Core/Types/Rect.hs, dist/build/OpenCV/Internal/Core/Types/Rect.o )
[40 of 70] Compiling OpenCV.Internal.Core.Types.Rect.TH ( src/OpenCV/Internal/Core/Types/Rect/TH.hs, dist/build/OpenCV/Internal/Core/Types/Rect/TH.o )
[41 of 70] Compiling OpenCV.Core.Types.Rect ( src/OpenCV/Core/Types/Rect.hs, dist/build/OpenCV/Core/Types/Rect.o )
<no location info>: error:
ghc: panic! (the 'impossible' happened)
(GHC version 8.0.1 for x86_64-unknown-linux):
Loading temp shared object failed: /run/user/1000/ghc26419_0/libghc_281.so: undefined symbol: inline_c_OpenCV_Core_Types_Point_19_5c3d561e8841e5271fd465bfb109504b1d56b3f6
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
[42 of 70] Compiling OpenCV.Core.Types.Matx ( src/OpenCV/Core/Types/Matx.hs, dist/build/OpenCV/Core/Types/Matx.o )
```
<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":"GHC panic when installing haskell-opencv with nix","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":"I installed https://github.com/LumiGuide/haskell-opencv using their recommended build system \"nix\", i.e. starting nix-shell in the cloned repository, waiting half an hour for several builds to complete and then doing the following from within the nix-shell:\r\n{{{\r\n[nix-shell:~/haskell-opencv]$ cabal build\r\nPackage has never been configured. Configuring with default flags. If this\r\nfails, please run configure manually.\r\nResolving dependencies...\r\n[1 of 1] Compiling Main ( dist/setup/setup.hs, dist/setup/Main.o )\r\nLinking ./dist/setup/setup ...\r\nConfiguring opencv-0.0.0...\r\nBuilding opencv-0.0.0...\r\nPreprocessing library opencv-0.0.0...\r\nIn file included from Types.hsc:96:0:\r\n/nix/store/ybmw9vbx8s8791lc7iggf8yd88kgwmxs-bindings-DSL-1.0.23/lib/ghc-8.0.1/bindings-DSL-1.0.23/include/bindings.dsl.h:191:3: Warnung: »bc_fielddata« definiert, aber nicht verwendet [-Wunused-variable]\r\n } bc_fielddata;\r\n ^\r\nIn file included from Features2d.hsc:69:0:\r\n/nix/store/ybmw9vbx8s8791lc7iggf8yd88kgwmxs-bindings-DSL-1.0.23/lib/ghc-8.0.1/bindings-DSL-1.0.23/include/bindings.dsl.h:191:3: Warnung: »bc_fielddata« definiert, aber nicht verwendet [-Wunused-variable]\r\n } bc_fielddata;\r\n ^\r\nIn file included from HighGui.hsc:87:0:\r\n/nix/store/ybmw9vbx8s8791lc7iggf8yd88kgwmxs-bindings-DSL-1.0.23/lib/ghc-8.0.1/bindings-DSL-1.0.23/include/bindings.dsl.h:191:3: Warnung: »bc_fielddata« definiert, aber nicht verwendet [-Wunused-variable]\r\n } bc_fielddata;\r\n ^\r\nIn file included from ColorMaps.hsc:28:0:\r\n/nix/store/ybmw9vbx8s8791lc7iggf8yd88kgwmxs-bindings-DSL-1.0.23/lib/ghc-8.0.1/bindings-DSL-1.0.23/include/bindings.dsl.h:191:3: Warnung: »bc_fielddata« definiert, aber nicht verwendet [-Wunused-variable]\r\n } bc_fielddata;\r\n ^\r\n\tIn file included from Drawing.hsc:52:0:\r\n/nix/store/ybmw9vbx8s8791lc7iggf8yd88kgwmxs-bindings-DSL-1.0.23/lib/ghc-8.0.1/bindings-DSL-1.0.23/include/bindings.dsl.h:191:3: Warnung: »bc_fielddata« definiert, aber nicht verwendet [-Wunused-variable]\r\n } bc_fielddata;\r\n ^\r\nIn file included from GeometricImgTransform.hsc:81:0:\r\n/nix/store/ybmw9vbx8s8791lc7iggf8yd88kgwmxs-bindings-DSL-1.0.23/lib/ghc-8.0.1/bindings-DSL-1.0.23/include/bindings.dsl.h:191:3: Warnung: »bc_fielddata« definiert, aber nicht verwendet [-Wunused-variable]\r\n } bc_fielddata;\r\n ^\r\nIn file included from ImgFiltering.hsc:72:0:\r\n/nix/store/ybmw9vbx8s8791lc7iggf8yd88kgwmxs-bindings-DSL-1.0.23/lib/ghc-8.0.1/bindings-DSL-1.0.23/include/bindings.dsl.h:191:3: Warnung: »bc_fielddata« definiert, aber nicht verwendet [-Wunused-variable]\r\n } bc_fielddata;\r\n ^\r\nIn file included from ObjectDetection.hsc:36:0:\r\n/nix/store/ybmw9vbx8s8791lc7iggf8yd88kgwmxs-bindings-DSL-1.0.23/lib/ghc-8.0.1/bindings-DSL-1.0.23/include/bindings.dsl.h:191:3: Warnung: »bc_fielddata« definiert, aber nicht verwendet [-Wunused-variable]\r\n } bc_fielddata;\r\n ^\r\nIn file included from StructuralAnalysis.hsc:47:0:\r\n/nix/store/ybmw9vbx8s8791lc7iggf8yd88kgwmxs-bindings-DSL-1.0.23/lib/ghc-8.0.1/bindings-DSL-1.0.23/include/bindings.dsl.h:191:3: Warnung: »bc_fielddata« definiert, aber nicht verwendet [-Wunused-variable]\r\n } bc_fielddata;\r\n ^\r\nIn file included from Video.hsc:32:0:\r\n/nix/store/ybmw9vbx8s8791lc7iggf8yd88kgwmxs-bindings-DSL-1.0.23/lib/ghc-8.0.1/bindings-DSL-1.0.23/include/bindings.dsl.h:191:3: Warnung: »bc_fielddata« definiert, aber nicht verwendet [-Wunused-variable]\r\n } bc_fielddata;\r\n ^\r\nIn file included from MotionAnalysis.hsc:44:0:\r\n/nix/store/ybmw9vbx8s8791lc7iggf8yd88kgwmxs-bindings-DSL-1.0.23/lib/ghc-8.0.1/bindings-DSL-1.0.23/include/bindings.dsl.h:191:3: Warnung: »bc_fielddata« definiert, aber nicht verwendet [-Wunused-variable]\r\n } bc_fielddata;\r\n ^\r\nIn file included from Constants.hsc:9:0:\r\n/nix/store/ybmw9vbx8s8791lc7iggf8yd88kgwmxs-bindings-DSL-1.0.23/lib/ghc-8.0.1/bindings-DSL-1.0.23/include/bindings.dsl.h:191:3: Warnung: »bc_fielddata« definiert, aber nicht verwendet [-Wunused-variable]\r\n } bc_fielddata;\r\n ^\r\nIn file included from ArrayOps.hsc:19:0:\r\n/nix/store/ybmw9vbx8s8791lc7iggf8yd88kgwmxs-bindings-DSL-1.0.23/lib/ghc-8.0.1/bindings-DSL-1.0.23/include/bindings.dsl.h:191:3: Warnung: »bc_fielddata« definiert, aber nicht verwendet [-Wunused-variable]\r\n } bc_fielddata;\r\n ^\r\nIn file included from Constants.hsc:9:0:\r\n/nix/store/ybmw9vbx8s8791lc7iggf8yd88kgwmxs-bindings-DSL-1.0.23/lib/ghc-8.0.1/bindings-DSL-1.0.23/include/bindings.dsl.h:191:3: Warnung: »bc_fielddata« definiert, aber nicht verwendet [-Wunused-variable]\r\n } bc_fielddata;\r\n ^\r\nIn file included from Marshal.hsc:21:0:\r\n/nix/store/ybmw9vbx8s8791lc7iggf8yd88kgwmxs-bindings-DSL-1.0.23/lib/ghc-8.0.1/bindings-DSL-1.0.23/include/bindings.dsl.h:191:3: Warnung: »bc_fielddata« definiert, aber nicht verwendet [-Wunused-variable]\r\n } bc_fielddata;\r\n ^\r\nIn file included from ImgCodecs.hsc:31:0:\r\n/nix/store/ybmw9vbx8s8791lc7iggf8yd88kgwmxs-bindings-DSL-1.0.23/lib/ghc-8.0.1/bindings-DSL-1.0.23/include/bindings.dsl.h:191:3: Warnung: »bc_fielddata« definiert, aber nicht verwendet [-Wunused-variable]\r\n } bc_fielddata;\r\n ^\r\nIn file included from MiscImgTransform.hsc:14:0:\r\n/nix/store/ybmw9vbx8s8791lc7iggf8yd88kgwmxs-bindings-DSL-1.0.23/lib/ghc-8.0.1/bindings-DSL-1.0.23/include/bindings.dsl.h:191:3: Warnung: »bc_fielddata« definiert, aber nicht verwendet [-Wunused-variable]\r\n } bc_fielddata;\r\n ^\r\nIn file included from Types.hsc:18:0:\r\n/nix/store/ybmw9vbx8s8791lc7iggf8yd88kgwmxs-bindings-DSL-1.0.23/lib/ghc-8.0.1/bindings-DSL-1.0.23/include/bindings.dsl.h:191:3: Warnung: »bc_fielddata« definiert, aber nicht verwendet [-Wunused-variable]\r\n } bc_fielddata;\r\n ^\r\nIn file included from Constants.hsc:9:0:\r\n/nix/store/ybmw9vbx8s8791lc7iggf8yd88kgwmxs-bindings-DSL-1.0.23/lib/ghc-8.0.1/bindings-DSL-1.0.23/include/bindings.dsl.h:191:3: Warnung: »bc_fielddata« definiert, aber nicht verwendet [-Wunused-variable]\r\n } bc_fielddata;\r\n ^\r\nIn file included from Constants.hsc:11:0:\r\n/nix/store/ybmw9vbx8s8791lc7iggf8yd88kgwmxs-bindings-DSL-1.0.23/lib/ghc-8.0.1/bindings-DSL-1.0.23/include/bindings.dsl.h:191:3: Warnung: »bc_fielddata« definiert, aber nicht verwendet [-Wunused-variable]\r\n } bc_fielddata;\r\n ^\r\n[ 1 of 70] Compiling OpenCV.Internal.VideoIO.Constants ( dist/build/OpenCV/Internal/VideoIO/Constants.hs, dist/build/OpenCV/Internal/VideoIO/Constants.o )\r\n[ 2 of 70] Compiling OpenCV.Internal.VideoIO.Types ( src/OpenCV/Internal/VideoIO/Types.hs, dist/build/OpenCV/Internal/VideoIO/Types.o )\r\n[ 3 of 70] Compiling OpenCV.VideoIO.Types ( src/OpenCV/VideoIO/Types.hs, dist/build/OpenCV/VideoIO/Types.o )\r\n[ 4 of 70] Compiling OpenCV.Internal.Photo.Constants ( dist/build/OpenCV/Internal/Photo/Constants.hs, dist/build/OpenCV/Internal/Photo/Constants.o )\r\n[ 5 of 70] Compiling OpenCV.Internal.ImgProc.MiscImgTransform ( dist/build/OpenCV/Internal/ImgProc/MiscImgTransform.hs, dist/build/OpenCV/Internal/ImgProc/MiscImgTransform.o )\r\n[ 6 of 70] Compiling OpenCV.Internal.ImgCodecs ( dist/build/OpenCV/Internal/ImgCodecs.hs, dist/build/OpenCV/Internal/ImgCodecs.o )\r\n[ 7 of 70] Compiling OpenCV.Internal.Core.Types.Constants ( dist/build/OpenCV/Internal/Core/Types/Constants.hs, dist/build/OpenCV/Internal/Core/Types/Constants.o )\r\n[ 8 of 70] Compiling OpenCV.Internal.C.PlacementNew ( src/OpenCV/Internal/C/PlacementNew.hs, dist/build/OpenCV/Internal/C/PlacementNew.o )\r\n[ 9 of 70] Compiling OpenCV.Internal.C.PlacementNew.TH ( src/OpenCV/Internal/C/PlacementNew/TH.hs, dist/build/OpenCV/Internal/C/PlacementNew/TH.o )\r\n[10 of 70] Compiling OpenCV.Internal.Mutable ( src/OpenCV/Internal/Mutable.hs, dist/build/OpenCV/Internal/Mutable.o )\r\n[11 of 70] Compiling OpenCV.Internal.Core.ArrayOps ( dist/build/OpenCV/Internal/Core/ArrayOps.hs, dist/build/OpenCV/Internal/Core/ArrayOps.o )\r\n[12 of 70] Compiling OpenCV.Internal ( src/OpenCV/Internal.hs, dist/build/OpenCV/Internal.o )\r\n[13 of 70] Compiling OpenCV.Internal.Calib3d.Constants ( dist/build/OpenCV/Internal/Calib3d/Constants.hs, dist/build/OpenCV/Internal/Calib3d/Constants.o )\r\n[14 of 70] Compiling OpenCV.Internal.C.Types ( src/OpenCV/Internal/C/Types.hs, dist/build/OpenCV/Internal/C/Types.o )\r\n[15 of 70] Compiling OpenCV.Internal.Core.Types.Matx ( src/OpenCV/Internal/Core/Types/Matx.hs, dist/build/OpenCV/Internal/Core/Types/Matx.o )\r\n[16 of 70] Compiling OpenCV.Internal.Core.Types.Matx.TH ( src/OpenCV/Internal/Core/Types/Matx/TH.hs, dist/build/OpenCV/Internal/Core/Types/Matx/TH.o )\r\n[17 of 70] Compiling OpenCV.Internal.Core.Types.Point ( src/OpenCV/Internal/Core/Types/Point.hs, dist/build/OpenCV/Internal/Core/Types/Point.o )\r\n[18 of 70] Compiling OpenCV.Internal.Core.Types.Point.TH ( src/OpenCV/Internal/Core/Types/Point/TH.hs, dist/build/OpenCV/Internal/Core/Types/Point/TH.o )\r\n[19 of 70] Compiling OpenCV.Internal.Core.Types.Size ( src/OpenCV/Internal/Core/Types/Size.hs, dist/build/OpenCV/Internal/Core/Types/Size.o )\r\n[20 of 70] Compiling OpenCV.Internal.Core.Types.Size.TH ( src/OpenCV/Internal/Core/Types/Size/TH.hs, dist/build/OpenCV/Internal/Core/Types/Size/TH.o )\r\n[21 of 70] Compiling OpenCV.Internal.Core.Types.Vec ( src/OpenCV/Internal/Core/Types/Vec.hs, dist/build/OpenCV/Internal/Core/Types/Vec.o )\r\n[22 of 70] Compiling OpenCV.Internal.Core.Types.Vec.TH ( src/OpenCV/Internal/Core/Types/Vec/TH.hs, dist/build/OpenCV/Internal/Core/Types/Vec/TH.o )\r\n[23 of 70] Compiling OpenCV.Internal.C.Inline ( src/OpenCV/Internal/C/Inline.hs, dist/build/OpenCV/Internal/C/Inline.o )\r\n[24 of 70] Compiling OpenCV.Core.Types.Size ( src/OpenCV/Core/Types/Size.hs, dist/build/OpenCV/Core/Types/Size.o )\r\n[25 of 70] Compiling OpenCV.Core.Types.Vec ( src/OpenCV/Core/Types/Vec.hs, dist/build/OpenCV/Core/Types/Vec.o )\r\n[26 of 70] Compiling OpenCV.TypeLevel ( src/OpenCV/TypeLevel.hs, dist/build/OpenCV/TypeLevel.o )\r\n[27 of 70] Compiling OpenCV.Internal.ImgProc.MiscImgTransform.TypeLevel ( src/OpenCV/Internal/ImgProc/MiscImgTransform/TypeLevel.hs, dist/build/OpenCV/Internal/ImgProc/MiscImgTransform/TypeLevel.o )\r\n[28 of 70] Compiling OpenCV.Internal.ImgProc.MiscImgTransform.ColorCodes ( src/OpenCV/Internal/ImgProc/MiscImgTransform/ColorCodes.hs, dist/build/OpenCV/Internal/ImgProc/MiscImgTransform/ColorCodes.o )\r\n[29 of 70] Compiling OpenCV.ImgProc.MiscImgTransform.ColorCodes ( src/OpenCV/ImgProc/MiscImgTransform/ColorCodes.hs, dist/build/OpenCV/ImgProc/MiscImgTransform/ColorCodes.o )\r\n[30 of 70] Compiling OpenCV.Internal.Core.Types.Mat.Depth ( src/OpenCV/Internal/Core/Types/Mat/Depth.hs, dist/build/OpenCV/Internal/Core/Types/Mat/Depth.o )\r\n[31 of 70] Compiling OpenCV.Internal.Exception ( src/OpenCV/Internal/Exception.hs, dist/build/OpenCV/Internal/Exception.o )\r\n[32 of 70] Compiling OpenCV.Exception ( src/OpenCV/Exception.hs, dist/build/OpenCV/Exception.o )\r\n[33 of 70] Compiling OpenCV.Internal.Core.Types.Mat.Marshal ( dist/build/OpenCV/Internal/Core/Types/Mat/Marshal.hs, dist/build/OpenCV/Internal/Core/Types/Mat/Marshal.o )\r\n[34 of 70] Compiling OpenCV.Core.Types.Point ( src/OpenCV/Core/Types/Point.hs, dist/build/OpenCV/Core/Types/Point.o )\r\n[35 of 70] Compiling OpenCV.Internal.Core.Types ( src/OpenCV/Internal/Core/Types.hs, dist/build/OpenCV/Internal/Core/Types.o )\r\n[36 of 70] Compiling OpenCV.Internal.Core.Types.Mat ( src/OpenCV/Internal/Core/Types/Mat.hs, dist/build/OpenCV/Internal/Core/Types/Mat.o )\r\n\r\n<no location info>: error:\r\n ghc: panic! (the 'impossible' happened)\r\n (GHC version 8.0.1 for x86_64-unknown-linux):\r\n\tLoading temp shared object failed: /run/user/1000/ghc26419_0/libghc_275.so: undefined symbol: inline_c_OpenCV_Internal_Exception_1_2402dbf3aea4f7f79392b71ed42618962a22e9aa\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n[39 of 70] Compiling OpenCV.Internal.Core.Types.Rect ( src/OpenCV/Internal/Core/Types/Rect.hs, dist/build/OpenCV/Internal/Core/Types/Rect.o )\r\n[40 of 70] Compiling OpenCV.Internal.Core.Types.Rect.TH ( src/OpenCV/Internal/Core/Types/Rect/TH.hs, dist/build/OpenCV/Internal/Core/Types/Rect/TH.o )\r\n[41 of 70] Compiling OpenCV.Core.Types.Rect ( src/OpenCV/Core/Types/Rect.hs, dist/build/OpenCV/Core/Types/Rect.o )\r\n\r\n<no location info>: error:\r\n ghc: panic! (the 'impossible' happened)\r\n (GHC version 8.0.1 for x86_64-unknown-linux):\r\n\tLoading temp shared object failed: /run/user/1000/ghc26419_0/libghc_281.so: undefined symbol: inline_c_OpenCV_Core_Types_Point_19_5c3d561e8841e5271fd465bfb109504b1d56b3f6\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n[42 of 70] Compiling OpenCV.Core.Types.Matx ( src/OpenCV/Core/Types/Matx.hs, dist/build/OpenCV/Core/Types/Matx.o )\r\n\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12812Debugging functions should throw warnings2019-07-07T18:25:03ZsiddhanathanDebugging functions should throw warningsThe function Debug.Trace.trace is useful for debugging, however, we don't want this function to be present in production code. An excerpt from Debug.Trace explains why:
```
The 'trace' function should /only/ be used for debugging, or fo...The function Debug.Trace.trace is useful for debugging, however, we don't want this function to be present in production code. An excerpt from Debug.Trace explains why:
```
The 'trace' function should /only/ be used for debugging, or for monitoring
execution. The function is not referentially transparent: its type indicates
that it is a pure function but it has the side effect of outputting the
trace message.
```
It would be useful if the compiler threw warnings when such functions are used.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | lowest |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Debugging functions should throw warnings","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"The function Debug.Trace.trace is useful for debugging, however, we don't want this function to be present in production code. An excerpt from Debug.Trace explains why:\r\n\r\n\r\n{{{\r\nThe 'trace' function should /only/ be used for debugging, or for monitoring\r\nexecution. The function is not referentially transparent: its type indicates\r\nthat it is a pure function but it has the side effect of outputting the\r\ntrace message.\r\n}}}\r\n\r\nIt would be useful if the compiler threw warnings when such functions are used.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12798LLVM seeming to over optimize, producing inefficient assembly code...2023-01-30T21:11:23ZGordonBGoodLLVM seeming to over optimize, producing inefficient assembly code...Since in many cases, the use of the LLVM backend is the only way to avoid the NCG's poor register allocation (ticket #8971), this is a concern that using "-fllvm" is producing overly complex code through a (seeming) failed attempt to opt...Since in many cases, the use of the LLVM backend is the only way to avoid the NCG's poor register allocation (ticket #8971), this is a concern that using "-fllvm" is producing overly complex code through a (seeming) failed attempt to optimize.
The following code uses a very simple "odds-only" implementation of the Sieve of Eratosthenes with a very tight inner culling loop limited to using a 16 Kilobyte buffer (\<= the size of most modern CPU L1 data cache size) to reproduce the problem; it uses a "twos" Look Up Table (LUT) for better speed than using a variable shift left operation for setting the composite bits in the buffer array as it (should) take the same number of registers and the array look-up instruction is easier for the CPU to fuse than a variable shift left:
```hs
-- GHC_EfficiencyBug.hs
{-# LANGUAGE FlexibleContexts #-}
{-# OPTIONS_GHC -O3 -fllvm -rtsopts -keep-s-files #-} -- or -O2
import Control.Monad.ST
import Data.Word
import Data.Bits
import Data.Array.ST (runSTUArray)
import Data.Array.Base
numLOOPS = 10000 :: Int
twos :: UArray Int Word32
twos = listArray (0, 31) [1 `shiftL` i | i <- [0 .. 31]]
soe :: () -> [Word32]
soe() = 2 : [fromIntegral i * 2 + 3 | (i, False) <- assocs bufb] where
bufb = runSTUArray $ do
let bfLmt = (256 * 1024) `div` 2 - 1 -- to 2^18 + 2 is 128 KBits - 1 = 16 KBytes
cmpstsb <- newArray (0, bfLmt) False :: ST s (STUArray s Int Bool)
cmpstsw <- (castSTUArray :: STUArray s Int Bool -> ST s (STUArray s Int Word32)) cmpstsb
let loop n = -- cull a number of times to test timing
if n <= 0 then return cmpstsb else
let cullp i =
let p = i + i + 3 in
let s = (p * p - 3) `div` 2 in
if s > bfLmt then loop (n - 1) else do
isCmpst <- unsafeRead cmpstsb i
if isCmpst then cullp (i + 1) else -- is Prime
let cull j = -- very tight inner loop where all the time is spent
if j > bfLmt then cullp (i + 1) else do
let sh = unsafeAt twos (j .&. 31) -- (1 `shiftL` (j .&. 31)))
let w = j `shiftR` 5
ov <- unsafeRead cmpstsw w
unsafeWrite cmpstsw w (ov .|. sh)
cull (j + p)
in cull s
in cullp 0
loop numLOOPS
main = print $ length $ soe()
```
The main culling is repeated "numLOOPS" times to get a reasonable execution time for accurate timing and to make the time required to use the List comprehension to determine the number of found primes (the answer) a negligible part of the execution time. Timing results can be produced by running "./GHC_EfficiencyBug +RTS -s".
The desired assembly code result for the tight inner loop is as for the Rust/LLVM compiler, in this case for x86_64 64-bit code:
```
.p2align 4, 0x90
.LBB10_27:
movq %rcx, %rdx
shrq $5, %rdx
movl %ecx, %esi
andl $31, %esi
movl (%rbp,%rsi,4), %esi
orl %esi, (%r14,%rdx,4)
addq %rax, %rcx
.LBB10_26:
cmpq %r13, %rcx
jb .LBB10_27
```
The above code is extremely efficient on a CPU that is not cache bottle necked (such as the AMD Bulldozer series are) and takes just about three clock cycles per inner composite culling loop on Intel Sky Lake; it is just as efficient for x86 code since there are only seven registers used in this inner loop.
Due to this attempt at "over-optimization", the GHC/LLVM backend produces the following x86_64 64-bit code:
```
.align 16, 0x90
.LBB34_2: # %c8T2
# =>This Inner Loop Header: Depth=1
movq %rcx, %rsi
sarq $5, %rsi
movl %r8d, %edi
andl $124, %edi
movl 16(%rax,%rdi), %edi
orl %edi, 16(%r11,%rsi,4)
addq %r14, %rcx
addq %rdx, %r8
cmpq %r10, %rcx
jle .LBB34_2
```
As can be seen, instead of just masking the "twos" index register by 31 (0x1F), the code is using two extra separate registers to contain "(j \* 4)" increment and the accumulated index, which increment is added to the "twos" index register per loop and masked by 124 (0x7C or 0x1F times 4), requiring an extra two registers and an extra instruction for the extra addition. This isn't a problem as to the number of registers for x86_64 code which has more than enough, but it adds the extra instruction execution time of one third of a CPU clock cycle (I know, only one ninth extra time).
However, for 32-bit x86 code with barely enough registers previously, the use of the extra registers triggers a chain of three register reloads as can be seen in the following assembly code:
```
.align 16, 0x90
LBB33_2: # %c8Wb
# =>This Inner Loop Header: Depth=1
movl %ebx, %ebp
sarl $5, %ebp
movl %edi, %ecx
andl $124, %ecx
movl %esi, %edx
movl %eax, %esi
movl 36(%esp), %eax # 4-byte Reload
movl 8(%eax,%ecx), %ecx
movl %esi, %eax
movl %edx, %esi
orl %ecx, 8(%esi,%ebp,4)
addl 32(%esp), %ebx # 4-byte Folded Reload
addl 28(%esp), %edi # 4-byte Folded Reload
cmpl %eax, %ebx
jle LBB33_2
```
**The above code runs about 25% slower than it should on Intel Sky Lake for this 32-bit code.**
This was tested for GHC version 8.0.1 under both Windows and Linux for both 32-bit and 64-bit code with identical results for each native code width.
The code was also tested for 32 and 64 bit code produced by the NCG; for this specific problem, NCG takes the simple approach and does not waste the extra register. However, due to the inefficient allocation of registers as per ticket #8971, not moving the loop completion check to the end of the loop and thus requiring an extra jump instruction, and not combining the read/modify/write into a single instruction, it is still slower (much slower for 32-bit code) than the LLVM produced code. As its problems are known, I have not documented the NCG code.
Conclusion: This may seem like a nit picky type of bug as in some use cases the execution time cost is very small, but it may be an indication of problems in other use cases that cause more serious effects on execution speed. It is my feeling that for such low level somewhat imperative types of code, GHC should really produce code that is as fast as C/C++/Rust.https://gitlab.haskell.org/ghc/ghc/-/issues/12792Wrong error message when using a data type as a class instance head2019-07-07T18:25:08ZJoachim Breitnermail@joachim-breitner.deWrong error message when using a data type as a class instance head```
Prelude> data List a = Nil | Cons a (List a)
Prelude> instance List a
<interactive>:3:10: error:
• Expected a constraint, but ‘List a’ has kind ‘*’
• In the instance declaration for ‘List a’
Prelude> instance List a where fo...```
Prelude> data List a = Nil | Cons a (List a)
Prelude> instance List a
<interactive>:3:10: error:
• Expected a constraint, but ‘List a’ has kind ‘*’
• In the instance declaration for ‘List a’
Prelude> instance List a where foo = foo
<interactive>:2:23: error:
‘foo’ is not a (visible) method of class ‘List’
```
Clearly, the constraint check should happen before we look at the method names.
Happens with 7.10 and 8.0.1 and HEAD.
Shouldn’t be hard, marking at newcomer.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.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":"Wrong error message when using a data type as a class instance head","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.1","keywords":["newcomer"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\nPrelude> data List a = Nil | Cons a (List a)\r\nPrelude> instance List a\r\n\r\n<interactive>:3:10: error:\r\n • Expected a constraint, but ‘List a’ has kind ‘*’\r\n • In the instance declaration for ‘List a’\r\nPrelude> instance List a where foo = foo\r\n\r\n<interactive>:2:23: error:\r\n ‘foo’ is not a (visible) method of class ‘List’\r\n}}}\r\n\r\nClearly, the constraint check should happen before we look at the method names.\r\n\r\nHappens with 7.10 and 8.0.1 and HEAD.\r\n\r\nShouldn’t be hard, marking at newcomer.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12786genericReplicateM and genericReplicateM_2019-07-07T18:25:09ZuznxgenericReplicateM and genericReplicateM_Add genericReplicateM and genericReplicateM_ to core libraries, probably Control.Monad, generalizing replicateM and replicateM_ to any Integral type, similar to all the other generic\* functions.
This was proposed and supported with no ...Add genericReplicateM and genericReplicateM_ to core libraries, probably Control.Monad, generalizing replicateM and replicateM_ to any Integral type, similar to all the other generic\* functions.
This was proposed and supported with no objections on the libraries mailing list:
https://mail.haskell.org/pipermail/libraries/2015-July/026016.html
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Core Libraries |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ekmett |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"genericReplicateM and genericReplicateM_","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ekmett"],"type":"FeatureRequest","description":"Add genericReplicateM and genericReplicateM_ to core libraries, probably Control.Monad, generalizing replicateM and replicateM_ to any Integral type, similar to all the other generic* functions.\r\n\r\nThis was proposed and supported with no objections on the libraries mailing list:\r\nhttps://mail.haskell.org/pipermail/libraries/2015-July/026016.html","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12779isTrue# doesn't work in ghci anymore2019-07-07T18:25:11ZÖmer Sinan AğacanisTrue# doesn't work in ghci anymore```haskell
GHCi, version 8.1.20161028: http://www.haskell.org/ghc/ :? for help
Prelude> :set -XMagicHash
Prelude> :m + GHC.Types
Prelude GHC.Types> isTrue# 123#
True
Prelude GHC.Types> [1] 3181 segmentation fault ghc-stage2 --inter...```haskell
GHCi, version 8.1.20161028: http://www.haskell.org/ghc/ :? for help
Prelude> :set -XMagicHash
Prelude> :m + GHC.Types
Prelude GHC.Types> isTrue# 123#
True
Prelude GHC.Types> [1] 3181 segmentation fault ghc-stage2 --interactive
```
This is also the reason why #12718 is segfaulting. I'm currently working on this.
`isTrue#` is failing in 8.0.1 too.https://gitlab.haskell.org/ghc/ghc/-/issues/12778Expose variables bound in quotations to reify2022-02-02T21:13:18ZFacundo DomínguezExpose variables bound in quotations to reifyConsider the following program:
```
{-# LANGUAGE TemplateHaskell #-}
module A where
import Language.Haskell.TH as TH
import Language.Haskell.TH.Syntax as TH
foo :: IO ()
foo = $([| let x = True
in $(do addModFinalizer $ do
...Consider the following program:
```
{-# LANGUAGE TemplateHaskell #-}
module A where
import Language.Haskell.TH as TH
import Language.Haskell.TH.Syntax as TH
foo :: IO ()
foo = $([| let x = True
in $(do addModFinalizer $ do
Just name <- TH.lookupValueName "x"
TH.reify name >>= runIO . print
[| return () |]
)
|])
```
When compiled, `TH.lookupValueName` fails to find `x`.
```
$ inplace/bin/ghc-stage2 A.hs -fforce-recomp
[1 of 1] Compiling A ( A.hs, A.o )
A.hs:7:9: error:
• Pattern match failure in do expression at A.hs:9:23-31
• In the expression: (let x_a3Jy = True in return ())
In an equation for ‘foo’: foo = (let x_a3Jy = True in return ())
```
It would make producing bindings in `inline-java` better if the type of `x` could be found in the finalizer.
According to comments in ghc,
`[| \x -> $(f [| x |]) |]`
desugars to
```
gensym (unpackString "x"#) `bindQ` \ x1::String ->
lam (pvar x1) (f (var x1))
```
which erases any hint that a splice point existed at all. This information is necessary to know which variables were in scope.
How about we add a some new methods to the `Q` monad for the sake of marking inner splices:
```
class Q m where
...
qSpliceE :: m Exp -> m Exp
qSpliceP :: m Pat -> m Pat
qSpliceT :: m Type -> m Type
...
```
Now
`[| \x -> $(f [| x |]) |]`
would desugar to
```
gensym (unpackString "x"#) `bindQ` \ x1::String ->
lam (pvar x1) (qSpliceE (f (var x1)))
```
When the renamer executes these primitives, it would be aware of the inner splices and could treat them similarly to top-level splices.
<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 | goldfire, mboes, simonpj |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Expose variables bound in quotations to reify","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["goldfire","mboes","simonpj"],"type":"Bug","description":"Consider the following program:\r\n{{{\r\n{-# LANGUAGE TemplateHaskell #-}\r\nmodule A where\r\nimport Language.Haskell.TH as TH\r\nimport Language.Haskell.TH.Syntax as TH\r\n\r\nfoo :: IO ()\r\nfoo = $([| let x = True\r\n in $(do addModFinalizer $ do\r\n Just name <- TH.lookupValueName \"x\"\r\n TH.reify name >>= runIO . print\r\n [| return () |]\r\n )\r\n |])\r\n}}}\r\nWhen compiled, {{{TH.lookupValueName}}} fails to find {{{x}}}.\r\n{{{\r\n$ inplace/bin/ghc-stage2 A.hs -fforce-recomp\r\n[1 of 1] Compiling A ( A.hs, A.o )\r\n\r\nA.hs:7:9: error:\r\n • Pattern match failure in do expression at A.hs:9:23-31\r\n • In the expression: (let x_a3Jy = True in return ())\r\n In an equation for ‘foo’: foo = (let x_a3Jy = True in return ())\r\n}}}\r\n\r\nIt would make producing bindings in {{{inline-java}}} better if the type of {{{x}}} could be found in the finalizer.\r\n\r\nAccording to comments in ghc,\r\n{{{[| \\x -> $(f [| x |]) |]}}}\r\ndesugars to\r\n{{{\r\ngensym (unpackString \"x\"#) `bindQ` \\ x1::String ->\r\n lam (pvar x1) (f (var x1))\r\n}}}\r\nwhich erases any hint that a splice point existed at all. This information is necessary to know which variables were in scope.\r\n\r\nHow about we add a some new methods to the `Q` monad for the sake of marking inner splices:\r\n{{{\r\nclass Q m where\r\n ...\r\n qSpliceE :: m Exp -> m Exp\r\n qSpliceP :: m Pat -> m Pat\r\n qSpliceT :: m Type -> m Type\r\n ...\r\n}}}\r\nNow\r\n{{{[| \\x -> $(f [| x |]) |]}}}\r\nwould desugar to\r\n{{{\r\ngensym (unpackString \"x\"#) `bindQ` \\ x1::String ->\r\n lam (pvar x1) (qSpliceE (f (var x1)))\r\n}}}\r\n\r\nWhen the renamer executes these primitives, it would be aware of the inner splices and could treat them similarly to top-level splices.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12774bkpcabal02 test fails on OS X2020-01-23T19:36:33ZBen Gamaribkpcabal02 test fails on OS XWhile testing on Darwin today I noticed that the `bkpcabal02` test seems to fail.
```
=====> bkpcabal02(normal) 1 of 1 [0, 0, 0]
cd "./backpack/cabal/bkpcabal02/bkpcabal02.run" && $MAKE -s --no-print-directory bkpcabal02 CLEANUP=1
Wro...While testing on Darwin today I noticed that the `bkpcabal02` test seems to fail.
```
=====> bkpcabal02(normal) 1 of 1 [0, 0, 0]
cd "./backpack/cabal/bkpcabal02/bkpcabal02.run" && $MAKE -s --no-print-directory bkpcabal02 CLEANUP=1
Wrong exit code (expected 0 , actual 2 )
Stdout:
Preprocessing library 'bkpcabal01-0.1.0.0-DwERz0Bcrkn4WeBnYMX11h-p' for
bkpcabal01-0.1.0.0...
Preprocessing library 'bkpcabal01-0.1.0.0-DwERz0Bcrkn4WeBnYMX11h-q' for
bkpcabal01-0.1.0.0...
Stderr:
make[2]: *** [bkpcabal02] Error 1
*** unexpected failure for bkpcabal02(normal)
```
Or more verbosely,
```
$ make bkpcabal02
rm -f -r tmp.d inst dist Setup
/Applications/Xcode-7.2/Xcode.app/Contents/Developer/usr/bin/make -s --no-print-directory clean
'/Users/bgamari/ghc/inplace/test spaces/ghc-pkg' init tmp.d
'/Users/bgamari/ghc/inplace/test spaces/ghc-stage2' -v0 --make Setup
cp p/H.hsig.in1 p/H.hsig
# typecheck everything
./Setup -v0 configure --enable-library-vanilla --disable-shared --with-ghc='/Users/bgamari/ghc/inplace/test spaces/ghc-stage2' --ghc-options='-dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -dno-debug-output' --package-db=tmp.d --prefix='/Users/bgamari/ghc/testsuite/tests/backpack/cabal/bkpcabal02/inst'
./Setup -v0 build
./Setup -v0 -v1 build
Preprocessing library 'bkpcabal01-0.1.0.0-DwERz0Bcrkn4WeBnYMX11h-p' for
bkpcabal01-0.1.0.0...
Preprocessing library 'bkpcabal01-0.1.0.0-DwERz0Bcrkn4WeBnYMX11h-q' for
bkpcabal01-0.1.0.0...
cp p/H.hsig.in2 p/H.hsig
! ./Setup -v0 build
make: *** [bkpcabal02] Error 1
```
It looks like the `./Setup build` command is finishing successfully where it is expected to fail. I generally don't mind debugging this sort of issue but in this case it's quite unclear why this is expected to fail.
Edward, can you add some comments to the `all.T` for this testcase (and perhaps the other Backpack tests too if neceessary) explaining what this test is supposed to be testing for and why `Setup build` should fail?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ezyang |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"bkpcabal02 test fails on OS X","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"8.2.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ezyang"],"type":"Task","description":"While testing on Darwin today I noticed that the `bkpcabal02` test seems to fail.\r\n{{{\r\n=====> bkpcabal02(normal) 1 of 1 [0, 0, 0]\r\ncd \"./backpack/cabal/bkpcabal02/bkpcabal02.run\" && $MAKE -s --no-print-directory bkpcabal02 CLEANUP=1 \r\nWrong exit code (expected 0 , actual 2 )\r\nStdout:\r\nPreprocessing library 'bkpcabal01-0.1.0.0-DwERz0Bcrkn4WeBnYMX11h-p' for\r\nbkpcabal01-0.1.0.0...\r\nPreprocessing library 'bkpcabal01-0.1.0.0-DwERz0Bcrkn4WeBnYMX11h-q' for\r\nbkpcabal01-0.1.0.0...\r\n\r\nStderr:\r\nmake[2]: *** [bkpcabal02] Error 1\r\n\r\n*** unexpected failure for bkpcabal02(normal)\r\n}}}\r\n\r\nOr more verbosely,\r\n{{{\r\n$ make bkpcabal02\r\nrm -f -r tmp.d inst dist Setup\r\n/Applications/Xcode-7.2/Xcode.app/Contents/Developer/usr/bin/make -s --no-print-directory clean\r\n'/Users/bgamari/ghc/inplace/test spaces/ghc-pkg' init tmp.d\r\n'/Users/bgamari/ghc/inplace/test spaces/ghc-stage2' -v0 --make Setup\r\ncp p/H.hsig.in1 p/H.hsig\r\n# typecheck everything\r\n./Setup -v0 configure --enable-library-vanilla --disable-shared --with-ghc='/Users/bgamari/ghc/inplace/test spaces/ghc-stage2' --ghc-options='-dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -dno-debug-output' --package-db=tmp.d --prefix='/Users/bgamari/ghc/testsuite/tests/backpack/cabal/bkpcabal02/inst'\r\n./Setup -v0 build\r\n./Setup -v0 -v1 build\r\nPreprocessing library 'bkpcabal01-0.1.0.0-DwERz0Bcrkn4WeBnYMX11h-p' for\r\nbkpcabal01-0.1.0.0...\r\nPreprocessing library 'bkpcabal01-0.1.0.0-DwERz0Bcrkn4WeBnYMX11h-q' for\r\nbkpcabal01-0.1.0.0...\r\ncp p/H.hsig.in2 p/H.hsig\r\n! ./Setup -v0 build\r\nmake: *** [bkpcabal02] Error 1\r\n}}}\r\n\r\nIt looks like the `./Setup build` command is finishing successfully where it is expected to fail. I generally don't mind debugging this sort of issue but in this case it's quite unclear why this is expected to fail.\r\n\r\nEdward, can you add some comments to the `all.T` for this testcase (and perhaps the other Backpack tests too if neceessary) explaining what this test is supposed to be testing for and why `Setup build` should fail?","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12773Data.Functor.Classes instances for ZipList2019-07-07T18:25:13ZIcelandjackData.Functor.Classes instances for ZipListSince `Data.Functor.Classes` is now maintained by the CLC, how about instances from [prelude-extras](https://hackage.haskell.org/package/prelude-extras-0.4.0.1/src/src/Prelude/Extras.hs), at least instances for `ZipList`
```hs
instance ...Since `Data.Functor.Classes` is now maintained by the CLC, how about instances from [prelude-extras](https://hackage.haskell.org/package/prelude-extras-0.4.0.1/src/src/Prelude/Extras.hs), at least instances for `ZipList`
```hs
instance Eq1 ZipList
instance Ord1 ZipList
instance Show1 ZipList
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Core Libraries |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ekmett |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Data.Functor.Classes instances for ZipList","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ekmett"],"type":"FeatureRequest","description":"Since `Data.Functor.Classes` is now maintained by the CLC, how about instances from [https://hackage.haskell.org/package/prelude-extras-0.4.0.1/src/src/Prelude/Extras.hs prelude-extras], at least instances for `ZipList`\r\n\r\n{{{#!hs\r\ninstance Eq1 ZipList\r\ninstance Ord1 ZipList\r\ninstance Show1 ZipList\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12765Don't optimize coercions with -O02022-11-01T15:33:28ZBen GamariDon't optimize coercions with -O0During the call today Simon and I discussed the possibility of omitting coercion optimization from the desugarer's simple optimization (`simpleOptPgm`) when compiling with `-O0`. The justification here was to perhaps speed-up unoptimized...During the call today Simon and I discussed the possibility of omitting coercion optimization from the desugarer's simple optimization (`simpleOptPgm`) when compiling with `-O0`. The justification here was to perhaps speed-up unoptimized compilation times for programs like that of #12506, which has very large coercions (presumably due to #8095).
The rationale was that while this first pass of coercion simplification during desugaring may reduce the size of some of these coercions, we only walk over them once more during code generation, so there's little benefit given the cost.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Don't optimize coercions with -O0","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.2.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"During the call today Simon and I discussed the possibility of omitting coercion optimization from the desugarer's simple optimization (`simpleOptPgm`) when compiling with `-O0`. The justification here was to perhaps speed-up unoptimized compilation times for programs like that of #12506, which has very large coercions (presumably due to #8095).\r\n\r\nThe rationale was that while this first pass of coercion simplification during desugaring may reduce the size of some of these coercions, we only walk over them once more during code generation, so there's little benefit given the cost.","type_of_failure":"OtherFailure","blocking":[]} -->