GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2023-01-20T15:28:09Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/3207readMutVar# is inlined/duplicated2023-01-20T15:28:09ZSimon MarlowreadMutVar# is inlined/duplicatedThe following code:
```
module Main where
import Control.Monad.ST.Lazy
import Data.STRef.Lazy
import Data.Array.ST
import Int
import Debug.Trace
data Refs s = Refs
{ memory :: STArray s Int8 Int8
, pc :: STRef s Int8...The following code:
```
module Main where
import Control.Monad.ST.Lazy
import Data.STRef.Lazy
import Data.Array.ST
import Int
import Debug.Trace
data Refs s = Refs
{ memory :: STArray s Int8 Int8
, pc :: STRef s Int8
}
main :: IO ()
main = do
print $ runST m
where
m = do
m <- newArray_ (0,30)
p <- newSTRef 0
let r = Refs m p
writeArray m 0 0x4
v <- readSTRef p
modifySTRef p (+1)
trace ("v: " ++ show v) $ return ()
op <- readArray m v
case trace ("v: " ++ show v) $ op of
0x4 -> modifySTRef p (+100) -- should run this
n -> error ("should never match this: " ++ show n)
```
generates this output:
```
> ./st
v: 0
v: 1
st: MArray: undefined array element
```
That is, the two instances of `trace (show v)` are printing different results, for the same v!
Looking at the Core, the problem seems to be that a call to `readMutVar#` has been inlined and duplicated. The `readMutVar#` primop doesn't have the `has_side_effects` flag set, and setting it (in `primops.txt.pp`) fixes it, but I'm not completely sure if that's the right fix. If it is, then there are lots of other similar primops that also need that flag set.
Bug report originally from a haskell-cafe post: [http://www.haskell.org/pipermail/haskell-cafe/2009-May/061010.html](http://www.haskell.org/pipermail/haskell-cafe/2009-May/061010.html)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.2 |
| 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":"readMutVar# is inlined/duplicated","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"6.12.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following code:\r\n\r\n{{{\r\nmodule Main where\r\n\r\nimport Control.Monad.ST.Lazy\r\nimport Data.STRef.Lazy\r\nimport Data.Array.ST\r\nimport Int\r\nimport Debug.Trace\r\n\r\ndata Refs s = Refs\r\n { memory :: STArray s Int8 Int8\r\n , pc :: STRef s Int8\r\n }\r\n\r\nmain :: IO ()\r\nmain = do\r\n print $ runST m\r\n where\r\n m = do\r\n m <- newArray_ (0,30)\r\n p <- newSTRef 0\r\n let r = Refs m p\r\n writeArray m 0 0x4\r\n v <- readSTRef p\r\n modifySTRef p (+1)\r\n trace (\"v: \" ++ show v) $ return ()\r\n op <- readArray m v\r\n case trace (\"v: \" ++ show v) $ op of\r\n 0x4 -> modifySTRef p (+100) -- should run this\r\n n -> error (\"should never match this: \" ++ show n)\r\n}}}\r\n\r\ngenerates this output:\r\n\r\n{{{\r\n> ./st \r\nv: 0\r\nv: 1\r\nst: MArray: undefined array element\r\n}}}\r\n\r\nThat is, the two instances of `trace (show v)` are printing different results, for the same v!\r\n\r\nLooking at the Core, the problem seems to be that a call to `readMutVar#` has been inlined and duplicated. The `readMutVar#` primop doesn't have the `has_side_effects` flag set, and setting it (in `primops.txt.pp`) fixes it, but I'm not completely sure if that's the right fix. If it is, then there are lots of other similar primops that also need that flag set.\r\n\r\nBug report originally from a haskell-cafe post: [http://www.haskell.org/pipermail/haskell-cafe/2009-May/061010.html]","type_of_failure":"OtherFailure","blocking":[]} -->6.10 branchIan Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3171threadDelay causes Ctrl-C to be ignored when running interpreted code2019-07-07T19:05:02ZchowellsthreadDelay causes Ctrl-C to be ignored when running interpreted codethe following program:
```
import Control.Concurrent
import Control.Concurrent.MVar
main = threadDelay 0 >> newEmptyMVar >>= takeMVar
```
will not respond to Ctrl-C when run via runghc, but does respond to Ctrl-C when compiled and exec...the following program:
```
import Control.Concurrent
import Control.Concurrent.MVar
main = threadDelay 0 >> newEmptyMVar >>= takeMVar
```
will not respond to Ctrl-C when run via runghc, but does respond to Ctrl-C when compiled and executed.
If the threadDelay is removed, it does respond to Ctrl-C both compiled and interpreted.
In 6.10.1, Ctrl-C has the normal effect whether the program is run compiled or interpreted.
The editline segmentation fault bug prevented us from testing the behavior in ghci.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"threadDelay causes Ctrl-C to be ignored when running interpreted code","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":["runghc"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"the following program:\r\n{{{\r\nimport Control.Concurrent\r\nimport Control.Concurrent.MVar\r\nmain = threadDelay 0 >> newEmptyMVar >>= takeMVar\r\n}}}\r\nwill not respond to Ctrl-C when run via runghc, but does respond to Ctrl-C when compiled and executed.\r\n\r\nIf the threadDelay is removed, it does respond to Ctrl-C both compiled and interpreted.\r\n\r\nIn 6.10.1, Ctrl-C has the normal effect whether the program is run compiled or interpreted.\r\n\r\nThe editline segmentation fault bug prevented us from testing the behavior in ghci.","type_of_failure":"OtherFailure","blocking":[]} -->6.10 branchIan Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3153Panic on syntactically wrong LANGUAGE pragma2019-07-07T19:05:07Zb_jonasPanic on syntactically wrong LANGUAGE pragmaI'm getting a panic from runghc. The program I'm compiling has a syntax error in the LANGUAGE pragma, but I still think I should get an error message instead of a panic.
I'm using ghc-6.10.2 compiled from vanilla sources (with extralibs...I'm getting a panic from runghc. The program I'm compiling has a syntax error in the LANGUAGE pragma, but I still think I should get an error message instead of a panic.
I'm using ghc-6.10.2 compiled from vanilla sources (with extralibs and a few options in build.mk) on an amd64 debian etch linux system.
Below you can see a transscript of the compilation including the panic message, and the source code.
```
[am]king ~/a/tmp$ runghc Bug
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.2 for x86_64-unknown-linux):
getOptions'.parseLanguage(2) went past eof token
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
1[am]king ~/a/tmp$ cat Bug.hs
{-# LANGUAGE - #-}
main = return ();
[am]king ~/a/tmp$ cat -A Bug.hs
{-# LANGUAGE - #-}$
main = return ();$
[am]king ~/a/tmp$ gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.3.3/configure --enable-languages=c,c++
Thread model: posix
gcc version 4.3.3 (GCC)
[am]king ~/a/tmp$ runghc -v -dcore-lint Bug
Glasgow Haskell Compiler, Version 6.10.2, for Haskell 98, stage 2 booted by GHC version 6.10.1
Using package config file: /usr/local/ghc/lib/ghc-6.10.2/./package.conf
hiding package base-3.0.3.1 to avoid conflict with later version base-4.1.0.0
wired-in package ghc-prim mapped to ghc-prim-0.1.0.0
wired-in package integer mapped to integer-0.1.0.1
wired-in package base mapped to base-4.1.0.0
wired-in package rts mapped to rts-1.0
wired-in package haskell98 mapped to haskell98-1.0.1.0
wired-in package syb mapped to syb-0.1.0.1
wired-in package template-haskell mapped to template-haskell-2.3.0.1
wired-in package dph-seq mapped to dph-seq-0.3
wired-in package dph-par mapped to dph-par-0.3
Hsc static flags: -ignore-dot-ghci -static
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
*** Chasing dependencies:
Chasing modules from:
Stable obj: []
Stable BCO: []
unload: retaining objs []
unload: retaining bcos []
Ready for upsweep []
Upsweep completely successful.
*** Deleting temp files:
Deleting:
*** Chasing dependencies:
Chasing modules from: *Bug.hs
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.2 for x86_64-unknown-linux):
getOptions'.parseLanguage(2) went past eof token
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
*** Deleting temp files:
Deleting:
*** Deleting temp dirs:
Deleting:
1[am]king ~/a/tmp$
```
(I found this bug when I tried to start a program with `{-# LANGUAGE -XPatternGuards #-}`.)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.2 |
| 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":"Panic on syntactically wrong LANGUAGE pragma","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I'm getting a panic from runghc. The program I'm compiling has a syntax error in the LANGUAGE pragma, but I still think I should get an error message instead of a panic. \r\n\r\nI'm using ghc-6.10.2 compiled from vanilla sources (with extralibs and a few options in build.mk) on an amd64 debian etch linux system. \r\n\r\nBelow you can see a transscript of the compilation including the panic message, and the source code. \r\n\r\n{{{\r\n[am]king ~/a/tmp$ runghc Bug\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 6.10.2 for x86_64-unknown-linux):\r\n\tgetOptions'.parseLanguage(2) went past eof token\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n1[am]king ~/a/tmp$ cat Bug.hs\r\n{-# LANGUAGE - #-}\r\nmain = return ();\r\n[am]king ~/a/tmp$ cat -A Bug.hs\r\n{-# LANGUAGE - #-}$\r\nmain = return ();$\r\n[am]king ~/a/tmp$ gcc -v\r\nUsing built-in specs.\r\nTarget: x86_64-unknown-linux-gnu\r\nConfigured with: ../gcc-4.3.3/configure --enable-languages=c,c++\r\nThread model: posix\r\ngcc version 4.3.3 (GCC) \r\n[am]king ~/a/tmp$ runghc -v -dcore-lint Bug\r\nGlasgow Haskell Compiler, Version 6.10.2, for Haskell 98, stage 2 booted by GHC version 6.10.1\r\nUsing package config file: /usr/local/ghc/lib/ghc-6.10.2/./package.conf\r\nhiding package base-3.0.3.1 to avoid conflict with later version base-4.1.0.0\r\nwired-in package ghc-prim mapped to ghc-prim-0.1.0.0\r\nwired-in package integer mapped to integer-0.1.0.1\r\nwired-in package base mapped to base-4.1.0.0\r\nwired-in package rts mapped to rts-1.0\r\nwired-in package haskell98 mapped to haskell98-1.0.1.0\r\nwired-in package syb mapped to syb-0.1.0.1\r\nwired-in package template-haskell mapped to template-haskell-2.3.0.1\r\nwired-in package dph-seq mapped to dph-seq-0.3\r\nwired-in package dph-par mapped to dph-par-0.3\r\nHsc static flags: -ignore-dot-ghci -static\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer ... linking ... done.\r\nLoading package base ... linking ... done.\r\n*** Chasing dependencies:\r\nChasing modules from: \r\nStable obj: []\r\nStable BCO: []\r\nunload: retaining objs []\r\nunload: retaining bcos []\r\nReady for upsweep []\r\nUpsweep completely successful.\r\n*** Deleting temp files:\r\nDeleting: \r\n*** Chasing dependencies:\r\nChasing modules from: *Bug.hs\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 6.10.2 for x86_64-unknown-linux):\r\n\tgetOptions'.parseLanguage(2) went past eof token\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n*** Deleting temp files:\r\nDeleting: \r\n*** Deleting temp dirs:\r\nDeleting: \r\n1[am]king ~/a/tmp$ \r\n}}}\r\n\r\n(I found this bug when I tried to start a program with `{-# LANGUAGE -XPatternGuards #-}`.)","type_of_failure":"OtherFailure","blocking":[]} -->6.10 branchIan Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3126GHC needs to be more careful about pattern match order2019-07-07T19:05:15Zclaus.reinke@talk21.comGHC needs to be more careful about pattern match orderThe [language report](http://haskell.org/onlinereport/exps.html#sect3.17.2) specifies pattern match order to be sequential, left-to-right, out-in, top-down. It explicitly allows for different implementations, as long as the differences a...The [language report](http://haskell.org/onlinereport/exps.html#sect3.17.2) specifies pattern match order to be sequential, left-to-right, out-in, top-down. It explicitly allows for different implementations, as long as the differences are not observable and certain [rules](http://haskell.org/onlinereport/exps.html#sect3.17.3) remain valid. One such rule is:
```
case e of {p1->e1;p2->e2} =
case e of {p1->e1;_->case e of {p2->e2;_->error "No match"}}
```
GHC invalidates this rule:
```
newtype N = N Int deriving (Show,Eq)
instance Num N where
fromInteger 0 = error "0"
fromInteger 1 = N 0
fromInteger _ = N 1
f x = case x of
1 -> False
0 -> True
g x = case x of
1 -> False
_ -> case x of
0 -> True
_ -> error "No match"
main = do
print $ g (N 0)
print $ f (N 0)
-- ghc
$ ghc -w -e main PMOrderSpec.hs
False
<interactive>: 0
-- hugs
Main> main
False
False
```
The same effect can be achieved via `Data.String.IsString` (see attached test case).
See also:
- [compilation of pattern matching?](http://www.haskell.org/pipermail/glasgow-haskell-users/2009-March/016949.html)
- [Wrongpat-matchorderforrecords](https://gitlab.haskell.org//ghc/ghc/issues/246)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.11 |
| 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 needs to be more careful about pattern match order","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The [http://haskell.org/onlinereport/exps.html#sect3.17.2 language report] specifies pattern match order to be sequential, left-to-right, out-in, top-down. It explicitly allows for different implementations, as long as the differences are not observable and certain [http://haskell.org/onlinereport/exps.html#sect3.17.3 rules] remain valid. One such rule is:\r\n{{{\r\n case e of {p1->e1;p2->e2} = \r\n case e of {p1->e1;_->case e of {p2->e2;_->error \"No match\"}}\r\n}}}\r\nGHC invalidates this rule:\r\n{{{\r\n newtype N = N Int deriving (Show,Eq)\r\n \r\n instance Num N where\r\n fromInteger 0 = error \"0\"\r\n fromInteger 1 = N 0\r\n fromInteger _ = N 1\r\n \r\n f x = case x of\r\n 1 -> False\r\n 0 -> True\r\n \r\n g x = case x of\r\n 1 -> False\r\n _ -> case x of\r\n 0 -> True\r\n _ -> error \"No match\"\r\n \r\n main = do\r\n print $ g (N 0)\r\n print $ f (N 0)\r\n\r\n -- ghc\r\n $ ghc -w -e main PMOrderSpec.hs\r\n False\r\n <interactive>: 0\r\n\r\n -- hugs\r\n Main> main\r\n False\r\n False\r\n}}}\r\nThe same effect can be achieved via `Data.String.IsString` (see attached test case).\r\n\r\nSee also: \r\n\r\n - [http://www.haskell.org/pipermail/glasgow-haskell-users/2009-March/016949.html compilation of pattern matching?]\r\n - [ticket:246 Wrong pat-match order for records]","type_of_failure":"OtherFailure","blocking":[]} -->6.10 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/3097Parser doesn't support doc comments on type aliases2019-07-07T19:05:25ZwaernParser doesn't support doc comments on type aliasesI want to add comments to type synonyms in order to fix the following Haddock bug, but I need some help.
> http://trac.haskell.org/haddock/ticket/9
In the parser, the rule for type synonyms is:
```
'type' type '=' ctype ...I want to add comments to type synonyms in order to fix the following Haddock bug, but I need some help.
> http://trac.haskell.org/haddock/ticket/9
In the parser, the rule for type synonyms is:
```
'type' type '=' ctype
```
Types with comments are already defined as `ctypedoc` and used for top-level types.
So it is tempting to just change `ctype` in the above line to `ctypedoc`. Indeed, I think originally `ctypedoc` was defined exactly as `ctype`, modulo comments. However, since then `ctype` has changed.
The differences are:
- `ctype` disallows foralls/contexts after a contex implication (=\>).
- `ctype` allows implicit parameters outside contexts. Seems to be disallowed by GHC later (after parsing).
- `ctype` allows type equalities (\~) outside contexts. Seems to be disallowed later also.
I haven't seen any further differences (besides comments).
Can I just change type synonyms to use `ctypedoc` without any other changes? Or do we need the features of `ctype` there? If so, then changing `ctypedoc` into just a commented version of `ctype` would not work as a solution, since then syntax like this (from base:GHC/Desugar.hs) breaks:
```
(>>>) :: forall arr. Arrow arr => forall a b c. arr a b -> arr b c -> arr a c
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.11 |
| 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":"Parser doesn't support doc comments on type aliases","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":["Haddock"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I want to add comments to type synonyms in order to fix the following Haddock bug, but I need some help.\r\n\r\n http://trac.haskell.org/haddock/ticket/9\r\n\r\nIn the parser, the rule for type synonyms is:\r\n{{{\r\n'type' type '=' ctype \r\n}}}\r\n\r\nTypes with comments are already defined as `ctypedoc` and used for top-level types.\r\n\r\nSo it is tempting to just change `ctype` in the above line to `ctypedoc`. Indeed, I think originally `ctypedoc` was defined exactly as `ctype`, modulo comments. However, since then `ctype` has changed.\r\n\r\nThe differences are:\r\n\r\n * `ctype` disallows foralls/contexts after a contex implication (=>).\r\n * `ctype` allows implicit parameters outside contexts. Seems to be disallowed by GHC later (after parsing).\r\n * `ctype` allows type equalities (~) outside contexts. Seems to be disallowed later also.\r\n\r\nI haven't seen any further differences (besides comments).\r\n\r\nCan I just change type synonyms to use `ctypedoc` without any other changes? Or do we need the features of `ctype` there? If so, then changing `ctypedoc` into just a commented version of `ctype` would not work as a solution, since then syntax like this (from base:GHC/Desugar.hs) breaks:\r\n{{{\r\n(>>>) :: forall arr. Arrow arr => forall a b c. arr a b -> arr b c -> arr a c\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->6.10 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/2723Unnecessary warning for record wildcards2019-07-07T19:07:09ZjudahUnnecessary warning for record wildcardsWhen compiling a file with record wildcards, -Wall produces a warning about shadowed bindings. Since the presence of a wildcard indicates that the shadowing was intentional, this warning seems unnecessary.
I reproduced this with both 6....When compiling a file with record wildcards, -Wall produces a warning about shadowed bindings. Since the presence of a wildcard indicates that the shadowing was intentional, this warning seems unnecessary.
I reproduced this with both 6.8.3 and 6.10.0.20081007:
```
{-# LANGUAGE RecordWildCards #-}
module WildCard where
data Record = Record {field1 :: Int, field2 :: Double}
test :: Record
test = let
field1 = 10
field2 = 10.0
in Record {..}
```
```
$ ghc --make -Wall WildCard.hs
[1 of 1] Compiling WildCard ( WildCard.hs, WildCard.o )
WildCard.hs:8:4:
Warning: This binding for `field1' shadows the existing binding
defined at WildCard.hs:4:22
In the binding group for: field1, field2
WildCard.hs:9:4:
Warning: This binding for `field2' shadows the existing binding
defined at WildCard.hs:4:37
In the binding group for: field1, field2
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.8.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":"Unnecessary warning for record wildcards","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When compiling a file with record wildcards, -Wall produces a warning about shadowed bindings. Since the presence of a wildcard indicates that the shadowing was intentional, this warning seems unnecessary.\r\n\r\nI reproduced this with both 6.8.3 and 6.10.0.20081007:\r\n\r\n{{{\r\n{-# LANGUAGE RecordWildCards #-}\r\nmodule WildCard where\r\n\r\ndata Record = Record {field1 :: Int, field2 :: Double}\r\n\r\ntest :: Record\r\ntest = let\r\n field1 = 10\r\n field2 = 10.0\r\n in Record {..}\r\n}}}\r\n\r\n{{{\r\n$ ghc --make -Wall WildCard.hs\r\n[1 of 1] Compiling WildCard ( WildCard.hs, WildCard.o )\r\n\r\nWildCard.hs:8:4:\r\n Warning: This binding for `field1' shadows the existing binding\r\n defined at WildCard.hs:4:22\r\n In the binding group for: field1, field2\r\n\r\nWildCard.hs:9:4:\r\n Warning: This binding for `field2' shadows the existing binding\r\n defined at WildCard.hs:4:37\r\n In the binding group for: field1, field2\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->6.10 branchIan Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/2246Numeric literal very badly optimized2019-07-07T19:09:33ZguestNumeric literal very badly optimizedCompile the following program with -ddump-simpl
```
main = interact $ show . (< 1e40) . read
```
Note how there's no literal value 1e40::Double anywhere in the code. Instead there's a call to fromRat to do the conversion.
Now replace ...Compile the following program with -ddump-simpl
```
main = interact $ show . (< 1e40) . read
```
Note how there's no literal value 1e40::Double anywhere in the code. Instead there's a call to fromRat to do the conversion.
Now replace 1e40 with (1e40::Double), and the code looks good. So it seems that when defaulting is involved the code is **much** worse.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| Version | 6.9 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | lennart@augustsson.net |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Numeric literal very badly optimized","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.9","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["lennart@augustsson.net"],"type":"Bug","description":"Compile the following program with -ddump-simpl\r\n\r\n{{{\r\nmain = interact $ show . (< 1e40) . read\r\n}}}\r\n\r\nNote how there's no literal value 1e40::Double anywhere in the code. Instead there's a call to fromRat to do the conversion.\r\n\r\nNow replace 1e40 with (1e40::Double), and the code looks good. So it seems that when defaulting is involved the code is '''much''' worse.","type_of_failure":"OtherFailure","blocking":[]} -->6.10 branchIan Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/2238panic nameModule tpl_B1{v}2019-07-07T19:09:36Zclaus.reinke@talk21.companic nameModule tpl_B1{v}using the attached code, we get
```
*Main> cfd True
"cfd"
*Main> ctf True
<interactive>:1:0:
No instance for (CTF Bool how)
arising from a use of `ctf' at <interactive>:1:0-7
Possible fix: add an instance declaration for ...using the attached code, we get
```
*Main> cfd True
"cfd"
*Main> ctf True
<interactive>:1:0:
No instance for (CTF Bool how)
arising from a use of `ctf' at <interactive>:1:0-7
Possible fix: add an instance declaration for (CTF Bool how)
In the expression: ctf True
In the definition of `it': it = ctf True
```
but if we uncomment the `CTF` instance, we get panic, even for cfd..
```
*Main> cfd True
: panic! (the 'impossible' happened)
(GHC version 6.9.20080217 for i386-unknown-mingw32):
nameModule tpl_B1{v}
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
*Main> ctf True
: panic! (the 'impossible' happened)
(GHC version 6.9.20080217 for i386-unknown-mingw32):
nameModule tpl_B1{v}
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.9 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"panic nameModule tpl_B1{v}","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.9","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"using the attached code, we get \r\n{{{\r\n*Main> cfd True\r\n\"cfd\"\r\n*Main> ctf True\r\n\r\n<interactive>:1:0:\r\n No instance for (CTF Bool how)\r\n arising from a use of `ctf' at <interactive>:1:0-7\r\n Possible fix: add an instance declaration for (CTF Bool how)\r\n In the expression: ctf True\r\n In the definition of `it': it = ctf True\r\n}}}\r\nbut if we uncomment the `CTF` instance, we get panic, even for cfd..\r\n{{{\r\n*Main> cfd True\r\n: panic! (the 'impossible' happened)\r\n (GHC version 6.9.20080217 for i386-unknown-mingw32):\r\n nameModule tpl_B1{v}\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n*Main> ctf True\r\n: panic! (the 'impossible' happened)\r\n (GHC version 6.9.20080217 for i386-unknown-mingw32):\r\n nameModule tpl_B1{v}\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->6.10 branchIan Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/2231ASSERT failed! file typecheck/TcMType.lhs line 442 t_a7Fa{tv} [tau]2019-07-07T19:09:37ZguestASSERT failed! file typecheck/TcMType.lhs line 442 t_a7Fa{tv} [tau]As discussed this afternoon on \#ghc.
From the attached tarball, unpack, cd sessions2, ghci Control/Concurrent/Session/Queens.hs, main
What should happen is that it prints "False". However, for me it consistently segfaults. GDB reveals...As discussed this afternoon on \#ghc.
From the attached tarball, unpack, cd sessions2, ghci Control/Concurrent/Session/Queens.hs, main
What should happen is that it prints "False". However, for me it consistently segfaults. GDB reveals things like:
```
*Control.Concurrent.Session.Queens> main
Loading package mtl-1.1.0.0 ... linking ... done.
Loading package array-0.1.0.0 ... linking ... done.
Loading package containers-0.1.0.1 ... linking ... done.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x41001950 (LWP 26393)]
0x00002b76022eae6b in memcpy () from /lib/libc.so.6
(gdb) bt
#0 0x00002b76022eae6b in memcpy () from /lib/libc.so.6
#1 0x000000000167f7b9 in schedule (initialCapability=<value optimized out>, task=0x1b9d100) at Schedule.c:2847
#2 0x000000000167f94f in workerStart (task=0x1b9d100) at Schedule.c:2528
#3 0x00002b760205e017 in start_thread () from /lib/libpthread.so.0
#4 0x00002b76023385bd in clone () from /lib/libc.so.6
#5 0x0000000000000000 in ?? ()
```
For some people, the first time you run main, it doesn't segfault but also doesn't print anything. Then the second time you run main, it will segfault then.
Compiling with ghc does result in the right (non-segfaulting) behaviour, both with -threaded and without.
For me, this is with 6.8.2, but Igloo confirmed that it segfaults HEAD too.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.8.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Linux |
| Architecture | x86_64 (amd64) |
</details>
<!-- {"blocked_by":[],"summary":"GHC RTS Segfault","status":"New","operating_system":"Linux","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"x86_64 (amd64)","cc":[""],"type":"Bug","description":"As discussed this afternoon on #ghc.\r\n\r\nFrom the attached tarball, unpack, cd sessions2, ghci Control/Concurrent/Session/Queens.hs, main\r\n\r\nWhat should happen is that it prints \"False\". However, for me it consistently segfaults. GDB reveals things like:\r\n\r\n{{{\r\n*Control.Concurrent.Session.Queens> main\r\nLoading package mtl-1.1.0.0 ... linking ... done.\r\nLoading package array-0.1.0.0 ... linking ... done.\r\nLoading package containers-0.1.0.1 ... linking ... done.\r\n\r\nProgram received signal SIGSEGV, Segmentation fault.\r\n[Switching to Thread 0x41001950 (LWP 26393)]\r\n0x00002b76022eae6b in memcpy () from /lib/libc.so.6\r\n(gdb) bt\r\n#0 0x00002b76022eae6b in memcpy () from /lib/libc.so.6\r\n#1 0x000000000167f7b9 in schedule (initialCapability=<value optimized out>, task=0x1b9d100) at Schedule.c:2847\r\n#2 0x000000000167f94f in workerStart (task=0x1b9d100) at Schedule.c:2528\r\n#3 0x00002b760205e017 in start_thread () from /lib/libpthread.so.0\r\n#4 0x00002b76023385bd in clone () from /lib/libc.so.6\r\n#5 0x0000000000000000 in ?? ()\r\n}}}\r\n\r\nFor some people, the first time you run main, it doesn't segfault but also doesn't print anything. Then the second time you run main, it will segfault then.\r\n\r\nCompiling with ghc does result in the right (non-segfaulting) behaviour, both with -threaded and without.\r\n\r\nFor me, this is with 6.8.2, but Igloo confirmed that it segfaults HEAD too.","type_of_failure":"OtherFailure","blocking":[]} -->6.10 branchSimon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/2188TH scoping problem2019-07-07T19:09:48ZIan Lynagh <igloo@earth.li>TH scoping problemIn the HEAD, these modules:
```
module TH_scope where
import TH_scope_helper
x :: ()
x = ()
where hold = $( wibble [d| hold :: ()
hold = () |] )
```
```
module TH_scope_helper where
import Language...In the HEAD, these modules:
```
module TH_scope where
import TH_scope_helper
x :: ()
x = ()
where hold = $( wibble [d| hold :: ()
hold = () |] )
```
```
module TH_scope_helper where
import Language.Haskell.TH
wibble :: Q [Dec] -> Q Exp
wibble _ = [| 'a' |]
```
give:
```
TH_scope.hs:8:31:
Misplaced type signature: hold :: ()
The type signature must be given where `hold' is declared
```
Renaming the outer `hold` fixes it.
The 6.8 branch seems OK.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 6.9 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Template Haskell |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"TH scoping problem","status":"New","operating_system":"Unknown","component":"Template Haskell","related":[],"milestone":"6.10 branch","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.9","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"In the HEAD, these modules:\r\n{{{\r\nmodule TH_scope where\r\n\r\nimport TH_scope_helper\r\n\r\nx :: ()\r\nx = ()\r\n where hold = $( wibble [d| hold :: ()\r\n hold = () |] )\r\n}}}\r\n{{{\r\nmodule TH_scope_helper where\r\n\r\nimport Language.Haskell.TH\r\n\r\nwibble :: Q [Dec] -> Q Exp\r\nwibble _ = [| 'a' |]\r\n}}}\r\ngive:\r\n{{{\r\nTH_scope.hs:8:31:\r\n Misplaced type signature: hold :: ()\r\n The type signature must be given where `hold' is declared\r\n}}}\r\nRenaming the outer `hold` fixes it.\r\n\r\nThe 6.8 branch seems OK.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.10 branchIan Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/2179Improve error message when `main' is not of the right type2019-07-07T19:09:51Zamiddelk@cs.uu.nlImprove error message when `main' is not of the right typeIf you run the following module with GHC(i):
> module Main where
> main = "hi"
You get the error message:
> Couldn't match expected type `IO a' against inferred type `\[Char\]'
> In the first argument of `GHC.TopHandler.runMainIO', na...If you run the following module with GHC(i):
> module Main where
> main = "hi"
You get the error message:
> Couldn't match expected type `IO a' against inferred type `\[Char\]'
> In the first argument of `GHC.TopHandler.runMainIO', namely `main'
> When checking the type of the function \`main'
The error message would be a bit nicer if the second line was hidden.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.8.2 |
| 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":"Improve error message when `main' is not of the right type","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"If you run the following module with GHC(i):\r\n\r\n> module Main where\r\n> main = \"hi\"\r\n\r\nYou get the error message:\r\n\r\n> Couldn't match expected type `IO a' against inferred type `[Char]'\r\n> In the first argument of `GHC.TopHandler.runMainIO', namely `main'\r\n> When checking the type of the function `main'\r\n\r\nThe error message would be a bit nicer if the second line was hidden.","type_of_failure":"OtherFailure","blocking":[]} -->6.10 branchIan Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/2141Internal error on invalid record update2019-07-07T19:10:01Zrl@cse.unsw.edu.auInternal error on invalid record updateA silly function:
```
foo :: () -> ()
foo x = x { foo = 1 }
```
1. 8.2 says:
```
GHC internal error: `foo' is not in scope
In the expression: x {foo = 1}
In the definition of `foo': foo x = x {foo = 1}
```
HEAD's message is a bit mor...A silly function:
```
foo :: () -> ()
foo x = x { foo = 1 }
```
1. 8.2 says:
```
GHC internal error: `foo' is not in scope
In the expression: x {foo = 1}
In the definition of `foo': foo x = x {foo = 1}
```
HEAD's message is a bit more illuminating:
```
GHC internal error: `foo' is not in scope during type checking, but it passed the renamer
tcg_type_env of environment: []
In the expression: x {foo = 1}
In the definition of `foo': foo x = x {foo = 1}
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.8.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Internal error on invalid record update","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"A silly function:\r\n\r\n{{{\r\nfoo :: () -> ()\r\nfoo x = x { foo = 1 }\r\n}}}\r\n\r\n6.8.2 says:\r\n\r\n{{{\r\nGHC internal error: `foo' is not in scope\r\nIn the expression: x {foo = 1}\r\nIn the definition of `foo': foo x = x {foo = 1}\r\n}}}\r\n\r\nHEAD's message is a bit more illuminating:\r\n\r\n{{{\r\nGHC internal error: `foo' is not in scope during type checking, but it passed the renamer\r\ntcg_type_env of environment: []\r\nIn the expression: x {foo = 1}\r\nIn the definition of `foo': foo x = x {foo = 1}\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.10 branchIan Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/2137Location of shadowed binding is wrong in warning2019-07-07T19:10:02ZIan Lynagh <igloo@earth.li>Location of shadowed binding is wrong in warningIf we have this module:
```
module Q where
z :: a
z = r
where
_a = 'a'
_f r = r
_b = 'b'
r = undefined
_c = 'c'
```
then the location of the shadowed `r` is wrong (it's the same as the locat...If we have this module:
```
module Q where
z :: a
z = r
where
_a = 'a'
_f r = r
_b = 'b'
r = undefined
_c = 'c'
```
then the location of the shadowed `r` is wrong (it's the same as the location of the one doing the shadowing):
```
$ ghc -fforce-recomp -Wall -c q.hs
q.hs:8:11:
Warning: This binding for `r' shadows the existing binding
bound at q.hs:8:11
In the definition of `_f'
```
1. 8 is fine (it doesn't try to give the location).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.9 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Location of shadowed binding is wrong in warning","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"6.10 branch","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.9","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"If we have this module:\r\n{{{\r\nmodule Q where\r\n\r\nz :: a\r\nz = r\r\n where\r\n _a = 'a'\r\n _f r = r\r\n _b = 'b'\r\n r = undefined\r\n _c = 'c'\r\n}}}\r\nthen the location of the shadowed `r` is wrong (it's the same as the location of the one doing the shadowing):\r\n{{{\r\n$ ghc -fforce-recomp -Wall -c q.hs\r\nq.hs:8:11:\r\n Warning: This binding for `r' shadows the existing binding\r\n bound at q.hs:8:11\r\n In the definition of `_f'\r\n}}}\r\n\r\n6.8 is fine (it doesn't try to give the location).\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.10 branchIan Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/2098validate fails for PPC Mac OS X 10.42019-07-07T19:10:14Zthorkilnaurvalidate fails for PPC Mac OS X 10.4Lately (http://www.haskell.org/pipermail/cvs-ghc/2008-February/041135.html) validate has been failing for PPC Mac OS X 10.4 as follows:
```
../compiler/stage1/ghc-inplace -no-user-package-conf -Werror -H64m -Onot -fasm -istage2/utils ...Lately (http://www.haskell.org/pipermail/cvs-ghc/2008-February/041135.html) validate has been failing for PPC Mac OS X 10.4 as follows:
```
../compiler/stage1/ghc-inplace -no-user-package-conf -Werror -H64m -Onot -fasm -istage2/utils -istage2/basicTypes -istage2/types -istage2/hsSyn -istage2/prelude -istage2/rename -istage2/typecheck -istage2/deSugar -istage2/coreSyn -istage2/vectorise -istage2/specialise -istage2/simplCore -istage2/stranal -istage2/stgSyn -istage2/simplStg -istage2/codeGen -istage2/main -istage2/profiling -istage2/parser -istage2/cprAnalysis -istage2/ndpFlatten -istage2/iface -istage2/cmm -istage2/nativeGen -istage2/ghci -Wall -fno-warn-name-shadowing -fno-warn-orphans -Istage2 -package hpc -package bytestring -DGHCI -package template-haskell -DGHCI_TABLES_NEXT_TO_CODE -package readline -DUSE_READLINE -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -Iparser -package unix -package Cabal -ignore-package lang -recomp -Rghc-timing -Onot -fasm -H16M '-#include "cutils.h"' -package-name ghc-6.9.20080208 -fgenerics -c ghci/ByteCodeFFI.lhs -o stage2/ghci/ByteCodeFFI.o -ohi stage2/ghci/ByteCodeFFI.hi
ghci/ByteCodeFFI.lhs:690:18:
Couldn't match expected type `PrimRep'
against inferred type `CgRep'
In the pattern: FloatArg
In a case alternative:
FloatArg
| nextFPR < 14
-> (3223257088 .|. (fromIntegral haskellArgOffset .&. 65535)
.|.
(fromIntegral nextFPR `shiftL` 21))
: pass_parameters args (nextFPR + 1) offsetW'
In the expression:
let
haskellArgOffset = a_offW * bytes_per_word
offsetW' = offsetW + primRepSizeW a_rep
pass_word w | offsetW + w < 8 = [...]
| otherwise = [...]
where
src = ...
....
in
case a_rep of
FloatArg
| nextFPR < 14
-> (3223257088 .|. (fromIntegral haskellArgOffset .&. 65535)
.|.
(fromIntegral nextFPR `shiftL` 21))
: pass_parameters args (nextFPR + 1) offsetW'
DoubleArg
| nextFPR < 14
-> (3357474816 .|. (fromIntegral haskellArgOffset .&. 65535)
.|.
(fromIntegral nextFPR `shiftL` 21))
: pass_parameters args (nextFPR + 1) offsetW'
_ -> concatMap pass_word ([0 .. primRepSizeW a_rep - 1])
++
pass_parameters args nextFPR offsetW'
ghci/ByteCodeFFI.lhs:705:12:
Couldn't match expected type `PrimRep'
against inferred type `CgRep'
In the pattern: VoidArg
In a case alternative: VoidArg -> []
In the expression:
case r_rep of
VoidArg -> []
FloatArg -> [3493789696 .|. (fromIntegral result_off .&. 65535)]
DoubleArg -> [3628007424 .|. (fromIntegral result_off .&. 65535)]
_ | primRepSizeW r_rep == 2
-> [2424242176 .|. (fromIntegral result_off .&. 65535),
2426339328 .|. (fromIntegral (result_off + 4) .&. 65535)]
_ | primRepSizeW r_rep == 1
-> [2424242176 .|. (fromIntegral result_off .&. 65535)]
<<ghc: 47687720 bytes, 9 GCs, 2690342/5255332 avg/max bytes residency (2 samples), 17M in use, 0.01 INIT (0.00 elapsed), 0.87 MUT (2.73 elapsed), 0.61 GC (1.47 elapsed) :ghc>>
make[2]: *** [stage2/ghci/ByteCodeFFI.o] Error 1
make[2]: *** Waiting for unfinished jobs....
<<ghc: 208607448 bytes, 28 GCs, 3604469/5941884 avg/max bytes residency (3 samples), 20M in use, 0.01 INIT (0.00 elapsed), 4.79 MUT (11.39 elapsed), 1.36 GC (2.55 elapsed) :ghc>>
make[1]: *** [stage2] Error 2
make: *** [bootstrap2] Error 2
```
Best regards
Thorkil
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.9 |
| 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":"validate fails for PPC Mac OS X 10.4","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.9","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Lately (http://www.haskell.org/pipermail/cvs-ghc/2008-February/041135.html) validate has been failing for PPC Mac OS X 10.4 as follows:\r\n{{{\r\n../compiler/stage1/ghc-inplace -no-user-package-conf -Werror -H64m -Onot -fasm -istage2/utils -istage2/basicTypes -istage2/types -istage2/hsSyn -istage2/prelude -istage2/rename -istage2/typecheck -istage2/deSugar -istage2/coreSyn -istage2/vectorise -istage2/specialise -istage2/simplCore -istage2/stranal -istage2/stgSyn -istage2/simplStg -istage2/codeGen -istage2/main -istage2/profiling -istage2/parser -istage2/cprAnalysis -istage2/ndpFlatten -istage2/iface -istage2/cmm -istage2/nativeGen -istage2/ghci -Wall -fno-warn-name-shadowing -fno-warn-orphans -Istage2 -package hpc -package bytestring -DGHCI -package template-haskell -DGHCI_TABLES_NEXT_TO_CODE -package readline -DUSE_READLINE -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -Iparser -package unix -package Cabal -ignore-package lang -recomp -Rghc-timing -Onot -fasm -H16M '-#include \"cutils.h\"' -package-name ghc-6.9.20080208 -fgenerics -c ghci/ByteCodeFFI.lhs -o stage2/ghci/ByteCodeFFI.o -ohi stage2/ghci/ByteCodeFFI.hi\r\n\r\nghci/ByteCodeFFI.lhs:690:18:\r\n Couldn't match expected type `PrimRep'\r\n against inferred type `CgRep'\r\n In the pattern: FloatArg\r\n In a case alternative:\r\n FloatArg\r\n | nextFPR < 14\r\n -> (3223257088 .|. (fromIntegral haskellArgOffset .&. 65535)\r\n .|.\r\n (fromIntegral nextFPR `shiftL` 21))\r\n : pass_parameters args (nextFPR + 1) offsetW'\r\n In the expression:\r\n let\r\n haskellArgOffset = a_offW * bytes_per_word\r\n offsetW' = offsetW + primRepSizeW a_rep\r\n pass_word w | offsetW + w < 8 = [...]\r\n | otherwise = [...]\r\n where\r\n src = ...\r\n ....\r\n in\r\n case a_rep of\r\n FloatArg\r\n | nextFPR < 14\r\n -> (3223257088 .|. (fromIntegral haskellArgOffset .&. 65535)\r\n .|.\r\n (fromIntegral nextFPR `shiftL` 21))\r\n : pass_parameters args (nextFPR + 1) offsetW'\r\n DoubleArg\r\n | nextFPR < 14\r\n -> (3357474816 .|. (fromIntegral haskellArgOffset .&. 65535)\r\n .|.\r\n (fromIntegral nextFPR `shiftL` 21))\r\n : pass_parameters args (nextFPR + 1) offsetW'\r\n _ -> concatMap pass_word ([0 .. primRepSizeW a_rep - 1])\r\n ++\r\n pass_parameters args nextFPR offsetW'\r\n\r\nghci/ByteCodeFFI.lhs:705:12:\r\n Couldn't match expected type `PrimRep'\r\n against inferred type `CgRep'\r\n In the pattern: VoidArg\r\n In a case alternative: VoidArg -> []\r\n In the expression:\r\n case r_rep of\r\n VoidArg -> []\r\n FloatArg -> [3493789696 .|. (fromIntegral result_off .&. 65535)]\r\n DoubleArg -> [3628007424 .|. (fromIntegral result_off .&. 65535)]\r\n _ | primRepSizeW r_rep == 2\r\n -> [2424242176 .|. (fromIntegral result_off .&. 65535),\r\n 2426339328 .|. (fromIntegral (result_off + 4) .&. 65535)]\r\n _ | primRepSizeW r_rep == 1\r\n -> [2424242176 .|. (fromIntegral result_off .&. 65535)]\r\n<<ghc: 47687720 bytes, 9 GCs, 2690342/5255332 avg/max bytes residency (2 samples), 17M in use, 0.01 INIT (0.00 elapsed), 0.87 MUT (2.73 elapsed), 0.61 GC (1.47 elapsed) :ghc>>\r\nmake[2]: *** [stage2/ghci/ByteCodeFFI.o] Error 1\r\nmake[2]: *** Waiting for unfinished jobs....\r\n<<ghc: 208607448 bytes, 28 GCs, 3604469/5941884 avg/max bytes residency (3 samples), 20M in use, 0.01 INIT (0.00 elapsed), 4.79 MUT (11.39 elapsed), 1.36 GC (2.55 elapsed) :ghc>>\r\nmake[1]: *** [stage2] Error 2\r\nmake: *** [bootstrap2] Error 2\r\n}}}\r\nBest regards\r\nThorkil\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.10 branchSimon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/2004Pattern matching against GADTs without -XGADTs has odd behavior.2019-07-07T19:10:41ZguestPattern matching against GADTs without -XGADTs has odd behavior.I'm getting a weird error message declaring a function in GHCi, but the same function declared in the source file works.
Repro case:
```
{-# LANGUAGE GADTs #-}
module Bug where
data Witness a b c where
Z :: Witness a as (a,as)
P...I'm getting a weird error message declaring a function in GHCi, but the same function declared in the source file works.
Repro case:
```
{-# LANGUAGE GADTs #-}
module Bug where
data Witness a b c where
Z :: Witness a as (a,as)
P :: Witness a as xs -> Witness a (b,as) (b,xs)
data Expr a vars where
Lam :: String -> Expr a (b,vars) -> Expr (b -> a) vars
Ap :: Expr (b -> a) vars -> Expr b vars -> Expr a vars
subst :: Witness a vs vsa -> Expr a vs -> Expr b vsa -> Expr b vs
subst = undefined
subAp :: Expr a vs -> Expr a vs
subAp (Ap (Lam _ e) v) = subst Z v e
```
This compiles fine. But in GHCi:
```
> let { subAp2 :: Expr a vs -> Expr a vs ; subAp2 (Ap (Lam _ e) v) = subst Z v e }
<interactive>:1:79:
Couldn't match expected type `a1' against inferred type `a2'
`a1' is a rigid type variable bound by
the type signature for `subAp2' at <interactive>:1:21
`a2' is a rigid type variable bound by
the constructor `Lam' at <interactive>:1:54
Expected type: Expr a1 (Decl b vs)
Inferred type: Expr a2 (Decl b1 vs)
In the third argument of `subst', namely `e'
In the expression: subst Z v e
```
Interestingly, if I do `:set -XGADTs` followed by that declaration, it works.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.8.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Pattern matching against GADTs without -XGADTs has odd behavior.","status":"New","operating_system":"Unknown","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"I'm getting a weird error message declaring a function in GHCi, but the same function declared in the source file works.\r\n\r\nRepro case:\r\n\r\n{{{\r\n{-# LANGUAGE GADTs #-}\r\nmodule Bug where\r\n\r\ndata Witness a b c where\r\n Z :: Witness a as (a,as)\r\n P :: Witness a as xs -> Witness a (b,as) (b,xs)\r\n\r\ndata Expr a vars where\r\n Lam :: String -> Expr a (b,vars) -> Expr (b -> a) vars\r\n Ap :: Expr (b -> a) vars -> Expr b vars -> Expr a vars\r\n\r\nsubst :: Witness a vs vsa -> Expr a vs -> Expr b vsa -> Expr b vs\r\nsubst = undefined\r\n\r\nsubAp :: Expr a vs -> Expr a vs\r\nsubAp (Ap (Lam _ e) v) = subst Z v e\r\n}}}\r\n\r\nThis compiles fine. But in GHCi:\r\n{{{\r\n> let { subAp2 :: Expr a vs -> Expr a vs ; subAp2 (Ap (Lam _ e) v) = subst Z v e }\r\n\r\n<interactive>:1:79:\r\n Couldn't match expected type `a1' against inferred type `a2'\r\n `a1' is a rigid type variable bound by\r\n the type signature for `subAp2' at <interactive>:1:21\r\n `a2' is a rigid type variable bound by\r\n the constructor `Lam' at <interactive>:1:54\r\n Expected type: Expr a1 (Decl b vs)\r\n Inferred type: Expr a2 (Decl b1 vs)\r\n In the third argument of `subst', namely `e'\r\n In the expression: subst Z v e\r\n}}}\r\n\r\nInterestingly, if I do {{{:set -XGADTs}}} followed by that declaration, it works.","type_of_failure":"OtherFailure","blocking":[]} -->6.10 branchIan Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/1963Pressing ^C at the right moment can trash GHC's package list2019-07-07T19:10:51ZIan Lynagh <igloo@earth.li>Pressing ^C at the right moment can trash GHC's package listIn
http://www.haskell.org/pipermail/libraries/2007-December/008727.html
Peter Gammie says
```
To my surprise, if you type ^C at the right moment you can trash GHC's
(system-wide) package list.
```
I'm not sure if this is in ghc-pkg or ...In
http://www.haskell.org/pipermail/libraries/2007-December/008727.html
Peter Gammie says
```
To my surprise, if you type ^C at the right moment you can trash GHC's
(system-wide) package list.
```
I'm not sure if this is in ghc-pkg or ghc, but we should check that this can't happen with either program.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.8.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Pressing ^C at the right moment can trash GHC's package list","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"6.8.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"In\r\nhttp://www.haskell.org/pipermail/libraries/2007-December/008727.html\r\nPeter Gammie says\r\n{{{\r\nTo my surprise, if you type ^C at the right moment you can trash GHC's\r\n(system-wide) package list.\r\n}}}\r\nI'm not sure if this is in ghc-pkg or ghc, but we should check that this can't happen with either program.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.10 branchSimon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/1814Lightweight quoting Stage error in interactive mode2019-07-07T19:11:37ZguestLightweight quoting Stage error in interactive mode```
ghc/compiler/stage2$ ./ghc-inplace --interactive -fth
GHCi, version 6.9.20071025: http://www.haskell.org/ghc/ :? for help
Loading package base ... linking ... done.
Prelude> :m +Language.Haskell.TH
Prelude Language.Haskell.TH> let f...```
ghc/compiler/stage2$ ./ghc-inplace --interactive -fth
GHCi, version 6.9.20071025: http://www.haskell.org/ghc/ :? for help
Loading package base ... linking ... done.
Prelude> :m +Language.Haskell.TH
Prelude Language.Haskell.TH> let f = 1
Prelude Language.Haskell.TH> :m +Language.Haskell.TH
Prelude Language.Haskell.TH> $(do {i <- reify 'f; runIO $ putStrLn (pprint i); [| 1 |]})
<interactive>:1:17:
Stage error: the non-top-level quoted name 'f
must be used at the same stage at which is is bound
In the first argument of `reify', namely 'f
In a 'do' expression: i <- reify 'f
In the expression:
$(do i <- reify 'f
runIO $ putStrLn (pprint i)
[| 1 |])
```
This error didn't show with version 6.6
```
$ ghci -fth
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version 6.6.1, for Haskell 98.
/ /_\\/ __ / /___| | http://www.haskell.org/ghc/
\____/\/ /_/\____/|_| Type :? for help.
Loading package base ... linking ... done.
Prelude> let f = 1
Prelude> :m +Language.Haskell.TH
Prelude Language.Haskell.TH> $(do {i <- reify 'f; runIO $ putStrLn (pprint i); [| 1 |]})
Loading package template-haskell ... linking ... done.
f_0 :: GHC.Num.Integer
f_0 :: GHC.Num.Integer
f_0 :: GHC.Num.Integer
f_0 :: GHC.Num.Integer
1
Prelude Language.Haskell.TH>
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------ |
| Version | 6.9 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Template Haskell |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | alfonso.acosta@gmail.com |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Lightweight quoting Stage error in interactive mode","status":"New","operating_system":"Unknown","component":"Template Haskell","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.9","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":["alfonso.acosta@gmail.com"],"type":"Bug","description":"{{{\r\nghc/compiler/stage2$ ./ghc-inplace --interactive -fth\r\nGHCi, version 6.9.20071025: http://www.haskell.org/ghc/ :? for help\r\nLoading package base ... linking ... done.\r\nPrelude> :m +Language.Haskell.TH\r\nPrelude Language.Haskell.TH> let f = 1\r\nPrelude Language.Haskell.TH> :m +Language.Haskell.TH\r\nPrelude Language.Haskell.TH> $(do {i <- reify 'f; runIO $ putStrLn (pprint i); [| 1 |]})\r\n\r\n<interactive>:1:17:\r\n Stage error: the non-top-level quoted name 'f\r\n must be used at the same stage at which is is bound\r\n In the first argument of `reify', namely 'f\r\n In a 'do' expression: i <- reify 'f\r\n In the expression:\r\n $(do i <- reify 'f\r\n runIO $ putStrLn (pprint i)\r\n [| 1 |])\r\n}}}\r\n\r\nThis error didn't show with version 6.6\r\n\r\n{{{\r\n$ ghci -fth\r\n ___ ___ _\r\n / _ \\ /\\ /\\/ __(_)\r\n / /_\\// /_/ / / | | GHC Interactive, version 6.6.1, for Haskell 98.\r\n/ /_\\\\/ __ / /___| | http://www.haskell.org/ghc/\r\n\\____/\\/ /_/\\____/|_| Type :? for help.\r\n\r\nLoading package base ... linking ... done.\r\nPrelude> let f = 1\r\nPrelude> :m +Language.Haskell.TH\r\nPrelude Language.Haskell.TH> $(do {i <- reify 'f; runIO $ putStrLn (pprint i); [| 1 |]})\r\nLoading package template-haskell ... linking ... done.\r\nf_0 :: GHC.Num.Integer\r\nf_0 :: GHC.Num.Integer\r\nf_0 :: GHC.Num.Integer\r\nf_0 :: GHC.Num.Integer\r\n1\r\nPrelude Language.Haskell.TH> \r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.10 branchIan Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/1813Strange type representation bug with phantom type synonyms in interactive mode2019-07-07T19:11:37ZguestStrange type representation bug with phantom type synonyms in interactive modeSorry for the confusing summary
The following module defines a phatom type synonym and a simple function
```
module Phantom where
type PhantomSyn a = Int
f = (\_ -> 2) :: PhantomSyn a -> Int
```
When running in interactive mode (th...Sorry for the confusing summary
The following module defines a phatom type synonym and a simple function
```
module Phantom where
type PhantomSyn a = Int
f = (\_ -> 2) :: PhantomSyn a -> Int
```
When running in interactive mode (the bug doesn't seem to be reproducible otherwise) the typechecker gives a strange error
```
./ghc-inplace --interactive /tmp/Phantom.hs
GHCi, version 6.9.20071025: http://www.haskell.org/ghc/ :? for help
Loading package base ... linking ... done.
[1 of 1] Compiling Phantom ( /tmp/Phantom.hs, interpreted )
Ok, modules loaded: Phantom.
*Phantom> f "incorrectParam"
<interactive>:1:2:
Couldn't match expected type `PhantomSyn GHC.Prim.Any'
against inferred type `[Char]'
Expected type: PhantomSyn GHC.Prim.Any
Inferred type: [Char]
In the first argument of `f', namely `"incorrectParam"'
In the expression: f "incorrectParam"
```
The typechecker should output
```
Expected type: PhantomSyn a
```
If I skip the interactive mode (including the erroneous declaration in the Phantom.hs itself) or I define f as
```
f :: PhantomSyn a -> Int
f = (\_ -> 2)
```
The incorrect error report disappears.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.9 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Strange type representation bug with phantom type synonyms in interactive mode","status":"New","operating_system":"Unknown","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.9","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"Sorry for the confusing summary \r\n\r\nThe following module defines a phatom type synonym and a simple function\r\n\r\n{{{\r\nmodule Phantom where\r\n\r\ntype PhantomSyn a = Int\r\n\r\nf = (\\_ -> 2) :: PhantomSyn a -> Int\r\n}}}\r\n\r\nWhen running in interactive mode (the bug doesn't seem to be reproducible otherwise) the typechecker gives a strange error\r\n\r\n\r\n{{{\r\n./ghc-inplace --interactive /tmp/Phantom.hs\r\nGHCi, version 6.9.20071025: http://www.haskell.org/ghc/ :? for help\r\nLoading package base ... linking ... done.\r\n[1 of 1] Compiling Phantom ( /tmp/Phantom.hs, interpreted )\r\nOk, modules loaded: Phantom.\r\n*Phantom> f \"incorrectParam\"\r\n\r\n<interactive>:1:2:\r\n Couldn't match expected type `PhantomSyn GHC.Prim.Any'\r\n against inferred type `[Char]'\r\n Expected type: PhantomSyn GHC.Prim.Any\r\n Inferred type: [Char]\r\n In the first argument of `f', namely `\"incorrectParam\"'\r\n In the expression: f \"incorrectParam\"\r\n}}}\r\n\r\nThe typechecker should output \r\n\r\n\r\n{{{\r\nExpected type: PhantomSyn a\r\n}}}\r\n\r\n\r\nIf I skip the interactive mode (including the erroneous declaration in the Phantom.hs itself) or I define f as\r\n\r\n{{{\r\nf :: PhantomSyn a -> Int\r\nf = (\\_ -> 2)\r\n}}}\r\n\r\nThe incorrect error report disappears.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.10 branchIan Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/1805"tail" is different under Solaris2019-07-07T19:11:39Zguest"tail" is different under SolarisEvery new shell-hack bears the risk of failing under solaris:
```
perl gen_flags.xsl.pl "ghc ghci" "/usr/local/lib/ghc-6.8.0.20071025" > flags.xsl
rm -f flags.xml
head -n 1 ../users_guide/flags.xml >> flags.xml
echo "<!DOCTYPE sect1 [<!...Every new shell-hack bears the risk of failing under solaris:
```
perl gen_flags.xsl.pl "ghc ghci" "/usr/local/lib/ghc-6.8.0.20071025" > flags.xsl
rm -f flags.xml
head -n 1 ../users_guide/flags.xml >> flags.xml
echo "<!DOCTYPE sect1 [<!ENTITY ndash \"-\"> \
<!ENTITY ldquo \"\`\"> \
<!ENTITY rdquo \"'\">]>" >> flags.xml
tail -n +2 ../users_guide/flags.xml >> flags.xml
usage: tail [+/-[n][lbc][f]] [file]
tail [+/-[n][l][r|f]] [file]
gmake[2]: *** [flags.xml] Error 2
gmake[2]: *** Deleting file `flags.xml'
Failed making all in man: 1
gmake[1]: *** [all] Error 1
gmake: *** [stage1] Error 1
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------ |
| Version | 6.8 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | Christian.Maeder@dfki.de |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"\"tail\" is different under Solaris","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["Christian.Maeder@dfki.de"],"type":"Bug","description":"Every new shell-hack bears the risk of failing under solaris:\r\n\r\n{{{\r\nperl gen_flags.xsl.pl \"ghc ghci\" \"/usr/local/lib/ghc-6.8.0.20071025\" > flags.xsl\r\nrm -f flags.xml\r\nhead -n 1 ../users_guide/flags.xml >> flags.xml\r\necho \"<!DOCTYPE sect1 [<!ENTITY ndash \\\"-\\\"> \\\r\n <!ENTITY ldquo \\\"\\`\\\"> \\\r\n <!ENTITY rdquo \\\"'\\\">]>\" >> flags.xml\r\ntail -n +2 ../users_guide/flags.xml >> flags.xml\r\nusage: tail [+/-[n][lbc][f]] [file]\r\n tail [+/-[n][l][r|f]] [file]\r\ngmake[2]: *** [flags.xml] Error 2\r\ngmake[2]: *** Deleting file `flags.xml'\r\nFailed making all in man: 1\r\ngmake[1]: *** [all] Error 1\r\ngmake: *** [stage1] Error 1\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.10 branchIan Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/1779unknown symbol `hs_hpc_module'2019-07-07T19:11:46Zguestunknown symbol `hs_hpc_module'During a :load command I got:
\<interactive\>: /home/foo/Bar/Baz.o: unknown symbol \`hs_hpc_module'
No test case available
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ...During a :load command I got:
\<interactive\>: /home/foo/Bar/Baz.o: unknown symbol \`hs_hpc_module'
No test case available
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.9 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"unknown symbol `hs_hpc_module'","status":"New","operating_system":"Unknown","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.9","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"During a :load command I got:\r\n<interactive>: /home/foo/Bar/Baz.o: unknown symbol `hs_hpc_module'\r\n\r\nNo test case available","type_of_failure":"OtherFailure","blocking":[]} -->6.10 branchIan Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>