GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:31:50Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/11127Update cabal submodule to 1.22.52019-07-07T18:31:50ZlukexiUpdate cabal submodule to 1.22.5For 7.10.3, this will fold in a critical fix for Mac (the Cabal side of #10568), along with a fix to prevent c-sources from being recompiled unnecessarily (a big deal when working with large C/C++ bindings).
The commit is `fb7ce39`
htt...For 7.10.3, this will fold in a critical fix for Mac (the Cabal side of #10568), along with a fix to prevent c-sources from being recompiled unnecessarily (a big deal when working with large C/C++ bindings).
The commit is `fb7ce39`
https://github.com/haskell/cabal/tree/1.227.10.3https://gitlab.haskell.org/ghc/ghc/-/issues/11076Demand information of foreign calls is wrong2019-07-07T18:32:13ZLuite StegemanDemand information of foreign calls is wrongForeign calls of all types (including prim calls) use `mkFCallId` to create a fresh `Id` for each one. This Id claims to be strict in all arguments, which is not correct for foreign calls that allow lifted types to be passed. This also c...Foreign calls of all types (including prim calls) use `mkFCallId` to create a fresh `Id` for each one. This Id claims to be strict in all arguments, which is not correct for foreign calls that allow lifted types to be passed. This also causes some trouble for GHCJS.
I hope to get a fix in 7.10.3. Can we leave the strictness sig out entirely perhaps? Most arguments would be trivially strict since they're unboxed.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.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":"Demand information of foreign calls is wrong","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Foreign calls of all types (including prim calls) use `mkFCallId` to create a fresh `Id` for each one. This Id claims to be strict in all arguments, which is not correct for foreign calls that allow lifted types to be passed. This also causes some trouble for GHCJS.\r\n\r\nI hope to get a fix in 7.10.3. Can we leave the strictness sig out entirely perhaps? Most arguments would be trivially strict since they're unboxed.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.3https://gitlab.haskell.org/ghc/ghc/-/issues/11064Call Arity has the trivial application case wrong2019-07-07T18:32:17ZJoachim Breitnermail@joachim-breitner.deCall Arity has the trivial application case wrongIn `e x`, the result of `x` is not shared in contrast to `e (f x)`, where CorePrep will turn it into `let y = f x in e x`. So in
```
let f = ...
in e (f x)
```
we know that f is called at most once, but in
```
let f = ...
in e...In `e x`, the result of `x` is not shared in contrast to `e (f x)`, where CorePrep will turn it into `let y = f x in e x`. So in
```
let f = ...
in e (f x)
```
we know that f is called at most once, but in
```
let f = ...
in e f
```
we do not know that.
Previously Call Arity would assume that in `e x`, `x` is evaluated at
most once. This rarely would make a difference (the argument `x` is
analized with an incoming arity of 0, so no eta-expansion would be done
anyways), but of course this should still be fixed.
I just validated a patch and will push shortly.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.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":"Call Arity has the trivial application case wrong","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"nomeata"},"version":"7.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In `e x`, the result of `x` is not shared in contrast to `e (f x)`, where CorePrep will turn it into `let y = f x in e x`. So in\r\n{{{\r\n let f = ...\r\n in e (f x)\r\n}}}\r\nwe know that f is called at most once, but in\r\n{{{\r\n let f = ...\r\n in e f\r\n}}}\r\nwe do not know that.\r\n\r\nPreviously Call Arity would assume that in `e x`, `x` is evaluated at\r\nmost once. This rarely would make a difference (the argument `x` is\r\nanalized with an incoming arity of 0, so no eta-expansion would be done\r\nanyways), but of course this should still be fixed.\r\n\r\nI just validated a patch and will push shortly.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.3Joachim Breitnermail@joachim-breitner.deJoachim Breitnermail@joachim-breitner.dehttps://gitlab.haskell.org/ghc/ghc/-/issues/11061GHC 7.10.3 RC1: build broken on OS X2019-07-07T18:32:19ZPeter Trommlerptrommler@acm.orgGHC 7.10.3 RC1: build broken on OS XRichard reported on ghc-devs:
> ```
> checking for readelf... no
> configure: error: cannot find readelf in your PATH
> ```
OS X uses Mach-O not ELF. So `readelf` does not work on Mach-O binaries.
<details><summary>Trac metadata</summ...Richard reported on ghc-devs:
> ```
> checking for readelf... no
> configure: error: cannot find readelf in your PATH
> ```
OS X uses Mach-O not ELF. So `readelf` does not work on Mach-O binaries.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC 7.10.3 RC1: build broken on OS X","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"7.10.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Richard reported on ghc-devs:\r\n> {{{\r\n> checking for readelf... no\r\n> configure: error: cannot find readelf in your PATH\r\n> }}}\r\n\r\nOS X uses Mach-O not ELF. So `readelf` does not work on Mach-O binaries.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.3https://gitlab.haskell.org/ghc/ghc/-/issues/11055GHC 7.8.4 crash on ARM while building Stack 0.1.72019-07-07T18:32:21ZLokathorGHC 7.8.4 crash on ARM while building Stack 0.1.7I was attempting to get stack on a raspberry pi 2. I had made a sandbox and installed the dependencies just fine. I go to build stack itself and the following happens:
```
daniel@pixie stack $ cabal build
Package has never been configur...I was attempting to get stack on a raspberry pi 2. I had made a sandbox and installed the dependencies just fine. I go to build stack itself and the following happens:
```
daniel@pixie stack $ cabal build
Package has never been configured. Configuring with default flags. If this
fails, please run configure manually.
Resolving dependencies...
Configuring stack-0.1.7.0...
Building stack-0.1.7.0...
Preprocessing library stack-0.1.7.0...
[ 1 of 74] Compiling Data.Set.Monad ( src/Data/Set/Monad.hs, dist/build/Data/Set/Monad.o )
ghc: internal error: scavenge: unimplemented/strange closure type 15028 @ 0x6dfe143c
(GHC version 7.8.4 for arm_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Aborted
```
The folder is still there so I could attach files or some such if needed. I know that GHC on ARM is full of weird instruction problems that have only recently been fixed, but I wasn't sure if this was related or not.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.4 |
| 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 7.8.4 crash on ARM while building Stack 0.1.7","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I was attempting to get stack on a raspberry pi 2. I had made a sandbox and installed the dependencies just fine. I go to build stack itself and the following happens:\r\n\r\n{{{\r\ndaniel@pixie stack $ cabal build\r\nPackage has never been configured. Configuring with default flags. If this\r\nfails, please run configure manually.\r\nResolving dependencies...\r\nConfiguring stack-0.1.7.0...\r\nBuilding stack-0.1.7.0...\r\nPreprocessing library stack-0.1.7.0...\r\n[ 1 of 74] Compiling Data.Set.Monad ( src/Data/Set/Monad.hs, dist/build/Data/Set/Monad.o )\r\nghc: internal error: scavenge: unimplemented/strange closure type 15028 @ 0x6dfe143c\r\n (GHC version 7.8.4 for arm_unknown_linux)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\nAborted\r\n}}}\r\n\r\nThe folder is still there so I could attach files or some such if needed. I know that GHC on ARM is full of weird instruction problems that have only recently been fixed, but I wasn't sure if this was related or not.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.3https://gitlab.haskell.org/ghc/ghc/-/issues/11003Suggested fix for incorrect directory permissions is wrong2019-07-07T18:32:43ZDavid FeuerSuggested fix for incorrect directory permissions is wrongIf the current directory is group- or world- writable, I get an error
```
*** WARNING: /home/blahblah/src/yproj is writable by someone else, IGNORING!
Suggested fix: execute 'chmod 644 /home/blahblah/src/yproj'
```
This is extremely ba...If the current directory is group- or world- writable, I get an error
```
*** WARNING: /home/blahblah/src/yproj is writable by someone else, IGNORING!
Suggested fix: execute 'chmod 644 /home/blahblah/src/yproj'
```
This is extremely bad advice, because `644 = rw-r--r--`, meaning the directory is not executable, so nothing it contains can be accessed, and a user who's insufficiently familiar with Unix permissions will be very confused. The message should instead suggest `755=rwxr-xr-x`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Suggested fix for incorrect directory permissions is wrong","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"7.10.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"If the current directory is group- or world- writable, I get an error\r\n\r\n{{{\r\n*** WARNING: /home/blahblah/src/yproj is writable by someone else, IGNORING!\r\nSuggested fix: execute 'chmod 644 /home/blahblah/src/yproj'\r\n}}}\r\n\r\nThis is extremely bad advice, because `644 = rw-r--r--`, meaning the directory is not executable, so nothing it contains can be accessed, and a user who's insufficiently familiar with Unix permissions will be very confused. The message should instead suggest `755=rwxr-xr-x`.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.3https://gitlab.haskell.org/ghc/ghc/-/issues/10997Pattern synonym causes Iface error.2022-08-11T06:14:48ZMatthew PickeringPattern synonym causes Iface error.From the mailing list..
Hello,
We have a pattern synonym as follows
```
type family Showable (a :: k) :: Constraint where
Showable (a :: *) = (Show a)
Showable a = ()
pattern Just' :: () => (Showable a) => a -> (Maybe a)
pat...From the mailing list..
Hello,
We have a pattern synonym as follows
```
type family Showable (a :: k) :: Constraint where
Showable (a :: *) = (Show a)
Showable a = ()
pattern Just' :: () => (Showable a) => a -> (Maybe a)
pattern Just' a <- (extractJust -> (True, a)) where
Just' a = Just a
```
When we try to use the pattern in a different package, the error was
```
[1 of 1] Compiling Bar ( Bar.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Bar.o )
/tmp/test/p2/.stack-work/install/x86_64-linux/lts-3.5/7.10.2/lib/x86_64-linux-ghc-7.10.2/p1-0.1.0.0-I5t4il6dN7vIqsT1XgYsM3/Foo.hi
Declaration for Just'
Pattern synonym Just':
Iface type variable out of scope: k
Cannot continue after interface file error
```
The error only occurred when Showable was polykinded and we used synonym in a different package . Using the synonym in the same package works fine.
This problem did not happen with the following definition of (non polykinded ) Showable
```
type family Showable a :: Constraint where
Showable a = (Show a)
```7.10.3https://gitlab.haskell.org/ghc/ghc/-/issues/10934Iface type variable out of scope2019-07-07T18:32:59ZmjmrotekIface type variable out of scopeI'm sorry for spamming code and not providing a distilled example, but honestly I have no idea how to even begin pinpointing this.
I'm writing a library and hosting it on Github: https://github.com/marcinmrotek/pipes-key-value-csv which...I'm sorry for spamming code and not providing a distilled example, but honestly I have no idea how to even begin pinpointing this.
I'm writing a library and hosting it on Github: https://github.com/marcinmrotek/pipes-key-value-csv which compiles fine, but when I try to compile the test suite, GHC crashes with this error message:
```
/home/marcin/haskell/pipes-key-value-csv/.stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Pipes/KeyValueCsv/Internal/KeyValue.hi
Declaration for $fFromKeyValuesf:3:
Iface type variable out of scope: k
Cannot continue after interface file error
```
when I uncomment the
```hs
. KV.foldHeader
```
line in https://github.com/marcinmrotek/pipes-key-value-csv/blob/master/test/Test/KeyValue.hs
The thing is, this function does not even use the "FromKeyValues" type class mentioned - https://github.com/marcinmrotek/pipes-key-value-csv/blob/master/src/Pipes/KeyValueCsv/Internal/KeyValue.hs
KV.parseLine, which does, compiles fine (the test suite runs and fails with "Prelude: undefined". They're both defined here: https://github.com/marcinmrotek/pipes-key-value-csv/blob/master/src/Pipes/KeyValueCsv/KeyValue.hs
I've tried "stack clean", reinstalling both GHC and stack, installing my package globally with cabal-install (although I had to fix the validation-0.5.1 package by removing the Safe pragma; I've tried to use stack again, pointing it to the exact same code for validation-0.5.1, to no avail), the result is always the same - the library compiles, the test suite doesn't.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.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":"Iface type variable out of scope","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":["interface"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I'm sorry for spamming code and not providing a distilled example, but honestly I have no idea how to even begin pinpointing this.\r\n\r\nI'm writing a library and hosting it on Github: https://github.com/marcinmrotek/pipes-key-value-csv which compiles fine, but when I try to compile the test suite, GHC crashes with this error message:\r\n{{{\r\n/home/marcin/haskell/pipes-key-value-csv/.stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Pipes/KeyValueCsv/Internal/KeyValue.hi\r\nDeclaration for $fFromKeyValuesf:3:\r\n Iface type variable out of scope: k\r\nCannot continue after interface file error\r\n}}}\r\nwhen I uncomment the\r\n{{{#!hs\r\n. KV.foldHeader\r\n}}}\r\nline in https://github.com/marcinmrotek/pipes-key-value-csv/blob/master/test/Test/KeyValue.hs\r\n\r\nThe thing is, this function does not even use the \"FromKeyValues\" type class mentioned - https://github.com/marcinmrotek/pipes-key-value-csv/blob/master/src/Pipes/KeyValueCsv/Internal/KeyValue.hs\r\n\r\nKV.parseLine, which does, compiles fine (the test suite runs and fails with \"Prelude: undefined\". They're both defined here: https://github.com/marcinmrotek/pipes-key-value-csv/blob/master/src/Pipes/KeyValueCsv/KeyValue.hs\r\n\r\nI've tried \"stack clean\", reinstalling both GHC and stack, installing my package globally with cabal-install (although I had to fix the validation-0.5.1 package by removing the Safe pragma; I've tried to use stack again, pointing it to the exact same code for validation-0.5.1, to no avail), the result is always the same - the library compiles, the test suite doesn't.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.3https://gitlab.haskell.org/ghc/ghc/-/issues/10924Template variable unbound in rewrite rule2019-07-07T18:33:02ZEric CrockettTemplate variable unbound in rewrite ruleThe only ticket I see with this issues that \*isn't\* resolved in 7.10.2 is #10689. Might be a dup.
Compiling with -O1 succeeds, but `ghc -O2` fails:
```
{-# LANGUAGE DataKinds, GADTs, PolyKinds, ScopedTypeVariables,
Temp...The only ticket I see with this issues that \*isn't\* resolved in 7.10.2 is #10689. Might be a dup.
Compiling with -O1 succeeds, but `ghc -O2` fails:
```
{-# LANGUAGE DataKinds, GADTs, PolyKinds, ScopedTypeVariables,
TemplateHaskell, TypeFamilies, UndecidableInstances #-}
module Bug where
-- needed to use Nat's Num instance for +
import qualified GHC.Num as Num
import Data.Singletons.Prelude
import Data.Singletons.TH
import Data.Type.Natural
import Data.Typeable
-- | Copied from Data.Type.Natural because the data-level version
-- is not exported there.
(<<=) :: Nat -> Nat -> Bool
Z <<= _ = True
S _ <<= Z = False
S n <<= S m = n <<= m
singletons [d|
newtype PrimePower = PP (Nat,Nat) deriving (Eq,Show,Typeable)
|]
singletons [d|
ppMul :: PrimePower -> [PrimePower] -> [PrimePower]
ppMul x [] = [x]
ppMul x@(PP(p,e)) pps@(PP (p',e'):pps')
| p == p' = PP(p,e Num.+ e'):pps'
| p <<= p' = x:pps
| otherwise = (PP(p',e')):ppMul x pps'
|]
```
```
ghc: panic! (the 'impossible' happened)
(GHC version 7.10.2 for x86_64-unknown-linux):
Template variable unbound in rewrite rule
t_XexU
[t_aev4, t_aev5, n0_aeyH, n1_aeyI, n0_aeyV, n1_aeyW, ipv_sfxT,
sc_sg53, sc_sg54, sg_sg55, sg_sg56, sc_sg57]
[t_XexU, t_XexW, n0_XeBz, n1_XeBB, n0_XeBP, n1_XeBR, ipv_XfAP,
sc_Xg80, sc_Xg82, sg_Xg84, sg_Xg86, sc_Xg88]
[TYPE Let1627437970XSym7
n0_aeyH n1_aeyI n0_aeyV n1_aeyW ipv_sfxT t_aev4 t_aev5,
TYPE ipv_sfxT,
(SPP
@ ('PP ((Tuple2Sym0 @@ n0_aeyH) @@ n1_aeyI))
@ ((Tuple2Sym0 @@ n0_aeyH) @@ n1_aeyI)
@~ <'PP ((Tuple2Sym0 @@ n0_aeyH) @@ n1_aeyI)>_N
((STuple2
@ Nat
@ Nat
@ '(n0_aeyH, n1_aeyI)
@ n0_aeyH
@ n1_aeyI
@~ <'(n0_aeyH, n1_aeyI)>_N
sc_sg53
sc_sg54)
`cast` (sg_sg55
:: R:Sing(,)z '(n0_aeyH, n1_aeyI)
~R# Sing (Apply (Apply Tuple2Sym0 n0_aeyH) n1_aeyI))))
`cast` (sg_sg56
:: R:SingPrimePowerz
('PP (Apply (Apply Tuple2Sym0 n0_aeyH) n1_aeyI))
~R# Sing
(Apply PPSym0 (Apply (Apply Tuple2Sym0 n0_aeyH) n1_aeyI))),
sc_sg57]
[TYPE Let1627437970XSym7
n0_aeyH
n1_aeyI
n0_XeB0
n1_XeB2
ipv_XfzF
(Let1627437970XSym7
n0_aeyH n1_aeyI n0_aeyV n1_aeyW ipv_sfxT t_aev4 t_aev5)
ipv_sfxT,
TYPE ipv_XfzF,
(SPP
@ ('PP ((Tuple2Sym0 @@ n0_aeyH) @@ n1_aeyI))
@ ((Tuple2Sym0 @@ n0_aeyH) @@ n1_aeyI)
@~ <'PP ((Tuple2Sym0 @@ n0_aeyH) @@ n1_aeyI)>_N
((STuple2
@ Nat
@ Nat
@ '(n0_aeyH, n1_aeyI)
@ n0_aeyH
@ n1_aeyI
@~ <'(n0_aeyH, n1_aeyI)>_N
sc_sg53
sc_sg54)
`cast` (Sub (Sym (TFCo:R:Sing(,)z[0] <Nat>_N <Nat>_N)) (Sym
(TFCo:R:Apply(,)kTuple2Sym1l0[0]
<Nat>_N
<Nat>_N
<n1_aeyI>_N
<n0_aeyH>_N)
; (Apply
(Sym
(TFCo:R:Apply(->)kTuple2Sym0l0[0]
<Nat>_N
<Nat>_N
<n0_aeyH>_N))
<n1_aeyI>_N)_N)
:: R:Sing(,)z (Tuple2Sym2 n0_aeyH n1_aeyI)
~R# Sing (Apply (Apply Tuple2Sym0 n0_aeyH) n1_aeyI))))
`cast` (Sub (Sym TFCo:R:SingPrimePowerz[0]) (Sym
(TFCo:R:ApplyPrimePower(,)PPSym0l0[0]
<(Tuple2Sym0 @@ n0_aeyH) @@ n1_aeyI>_N))
:: R:SingPrimePowerz (PPSym1 ((Tuple2Sym0 @@ n0_aeyH) @@ n1_aeyI))
~R# Sing (Apply PPSym0 ((Tuple2Sym0 @@ n0_aeyH) @@ n1_aeyI))),
ipv_sfxW]
```
I'd love a workaround if possible; I've been unable to find one.7.10.3https://gitlab.haskell.org/ghc/ghc/-/issues/10904C finalizer may be called on re-used memory2019-07-07T18:33:07ZbherzogC finalizer may be called on re-used memoryIt seems that the runtime system sometimes reuses memory referred to by
`ForeignPtr` values before the associated C finalizers have been run. At
that's what it looks like to me. Maybe I'm interpreting the behavior of
GHC's runtime system...It seems that the runtime system sometimes reuses memory referred to by
`ForeignPtr` values before the associated C finalizers have been run. At
that's what it looks like to me. Maybe I'm interpreting the behavior of
GHC's runtime system incorrectly, or it's a defect in my test program.
To reproduce the defect, compile `finalizertest.hs` and `finalizerlib.c`,
e.g. with
```
ghc finalizertest.hs finalizerlib.c -threaded
```
Run the resulting program as
```
./finalizertest +RTS -N2
```
After a while it prints a message like
```
finalize_value: 80f69dc != 11223344 after 47393 calls
Aborted
```
The C code prints this if the pointer passed to the finalizer does not
point to the expected value.
It's not necessary to link with the threaded runtime, nor is it
necessary to run with more than one CPU. Doing so increases the
likelihood of the defect to occur substantially, though.
I've observed this with several different combinations of GHC and host-systems:
- GHC 7.10.2 on a 64 bit Linux (Debian jessie)
- GHC 7.10.1 on a 32 bit Linux (Debian wheezy)
- GHC 7.4.1 on a 32 bit Linux (Debian wheezy)
This GHC is the one packaged by Debian
It's crucial for the defect that the memory is allocated with
`mallocForeignPtrBytes`. Using `mallocBytes` instead and building a
`ForeignPtr` with `finalizerFree` avoids the defect.
I came across this defect while trying to debug a segmentation fault in
the `zlib` package. This defect was reported on the libraries mailing list
https://mail.haskell.org/pipermail/libraries/2015-June/025829.html
(corresponding Agda ticket: https://github.com/agda/agda/issues/1518). I came across it in one of my own projects last week.
My test program basically does what `zlib` does when allocating
and initializing the `z_stream` value: it allocates memory with
`mallocForeignPtrBytes` and later adds a finalizer with
`addForeignPtrFinalizer`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"C finalizer may be called on re-used memory","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonmar"],"type":"Bug","description":"It seems that the runtime system sometimes reuses memory referred to by\r\n`ForeignPtr` values before the associated C finalizers have been run. At\r\nthat's what it looks like to me. Maybe I'm interpreting the behavior of\r\nGHC's runtime system incorrectly, or it's a defect in my test program.\r\n\r\nTo reproduce the defect, compile `finalizertest.hs` and `finalizerlib.c`,\r\ne.g. with\r\n\r\n{{{\r\nghc finalizertest.hs finalizerlib.c -threaded\r\n}}}\r\n\r\nRun the resulting program as\r\n{{{\r\n./finalizertest +RTS -N2\r\n}}}\r\n\r\nAfter a while it prints a message like\r\n{{{\r\nfinalize_value: 80f69dc != 11223344 after 47393 calls\r\nAborted\r\n}}}\r\n\r\nThe C code prints this if the pointer passed to the finalizer does not\r\npoint to the expected value.\r\n\r\nIt's not necessary to link with the threaded runtime, nor is it\r\nnecessary to run with more than one CPU. Doing so increases the\r\nlikelihood of the defect to occur substantially, though.\r\n\r\nI've observed this with several different combinations of GHC and host-systems:\r\n* GHC 7.10.2 on a 64 bit Linux (Debian jessie)\r\n* GHC 7.10.1 on a 32 bit Linux (Debian wheezy)\r\n* GHC 7.4.1 on a 32 bit Linux (Debian wheezy)\r\n This GHC is the one packaged by Debian\r\n\r\nIt's crucial for the defect that the memory is allocated with\r\n`mallocForeignPtrBytes`. Using `mallocBytes` instead and building a\r\n`ForeignPtr` with `finalizerFree` avoids the defect.\r\n\r\nI came across this defect while trying to debug a segmentation fault in\r\nthe `zlib` package. This defect was reported on the libraries mailing list\r\nhttps://mail.haskell.org/pipermail/libraries/2015-June/025829.html\r\n(corresponding Agda ticket: https://github.com/agda/agda/issues/1518). I came across it in one of my own projects last week.\r\n\r\nMy test program basically does what `zlib` does when allocating\r\nand initializing the `z_stream` value: it allocates memory with\r\n`mallocForeignPtrBytes` and later adds a finalizer with\r\n`addForeignPtrFinalizer`.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.10.3https://gitlab.haskell.org/ghc/ghc/-/issues/10899Polytype accepted in RHS of default associated type2019-07-07T18:33:08ZRichard Eisenbergrae@richarde.devPolytype accepted in RHS of default associated typeThis hogwash is accepted:
```
class C a where
type F a
type F a = forall m. m a
```
I will fix.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Versi...This hogwash is accepted:
```
class C a where
type F a
type F a = forall m. m a
```
I will fix.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.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":"Polytype accepted in RHS of default associated type","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"7.10.3","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"goldfire"},"version":"7.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This hogwash is accepted:\r\n\r\n{{{\r\nclass C a where\r\n type F a\r\n type F a = forall m. m a\r\n}}}\r\n\r\nI will fix.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.3Richard Eisenbergrae@richarde.devRichard Eisenbergrae@richarde.devhttps://gitlab.haskell.org/ghc/ghc/-/issues/10882Fix target triple for Arm2019-07-07T18:33:13ZerikdFix target triple for ArmLLVM IR code generated by GHC on Arm (Debian) uses a target triple of "arm-linux-gnueabi" which according the LLVM people is something like ARMv4 with software float.
Clang on the other hand generates IR code with a target triple of "ar...LLVM IR code generated by GHC on Arm (Debian) uses a target triple of "arm-linux-gnueabi" which according the LLVM people is something like ARMv4 with software float.
Clang on the other hand generates IR code with a target triple of "armv6-linux-gnueablhf" which is ARMv6 and hardware float so it works on the original Raspberry Pi.
GHC should either use the same target triple as Clang or at least make it configurable.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | bgamari |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Fix target tripe for Arm","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"7.10.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["bgamari"],"type":"Bug","description":"LLVM IR code generated by GHC on Arm (Debian) uses a target triple of \"arm-linux-gnueabi\" which according the LLVM people is something like ARMv4 with software float.\r\n\r\nClang on the other hand generates IR code with a target triple of \"armv6-linux-gnueablhf\" which is ARMv6 and hardware float so it works on the original Raspberry Pi.\r\n\r\nGHC should either use the same target triple as Clang or at least make it configurable.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.10.3https://gitlab.haskell.org/ghc/ghc/-/issues/10879base is not included in the haddock index2019-07-07T18:33:15ZFeuerbachbase is not included in the haddock indexIt appears that starting from ghc 7.10 base is no longer present in the haddock html index distributed with ghc.
```
% grep -c base ~/.stack/programs/x86_64-linux/ghc-7.8.4/share/doc/ghc/html/libraries/index.html
1
% grep -c base ~/.st...It appears that starting from ghc 7.10 base is no longer present in the haddock html index distributed with ghc.
```
% grep -c base ~/.stack/programs/x86_64-linux/ghc-7.8.4/share/doc/ghc/html/libraries/index.html
1
% grep -c base ~/.stack/programs/x86_64-linux/ghc-7.10.2/share/doc/ghc/html/libraries/index.html
0
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.2 |
| 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":"base is not included in the haddock index","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"It appears that starting from ghc 7.10 base is no longer present in the haddock html index distributed with ghc.\r\n\r\n{{{\r\n% grep -c base ~/.stack/programs/x86_64-linux/ghc-7.8.4/share/doc/ghc/html/libraries/index.html\r\n1\r\n\r\n% grep -c base ~/.stack/programs/x86_64-linux/ghc-7.10.2/share/doc/ghc/html/libraries/index.html\r\n0\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->7.10.3https://gitlab.haskell.org/ghc/ghc/-/issues/10870PPC.Ppr: Shift by 32 bits is not allowed.2019-07-07T18:33:24ZJoachim Breitnermail@joachim-breitner.dePPC.Ppr: Shift by 32 bits is not allowed.Hi,
when compiling `vector-algorithms` on powerpc, I get
```
[ 7 of 10] Compiling Data.Vector.Algorithms.Tim ( src/Data/Vector/Algorithms/Tim.hs, dist-ghc/build/Data/Vector/Algorithms/Tim.o )
ghc: panic! (the 'impossible' happened)
(...Hi,
when compiling `vector-algorithms` on powerpc, I get
```
[ 7 of 10] Compiling Data.Vector.Algorithms.Tim ( src/Data/Vector/Algorithms/Tim.hs, dist-ghc/build/Data/Vector/Algorithms/Tim.o )
ghc: panic! (the 'impossible' happened)
(GHC version 7.10.2 for powerpc-unknown-linux):
PPC.Ppr: Shift by 32 bits is not allowed.
```
I do not get this error on other 32bit architectures.
The offending code seems to be
```
minrun :: Int -> Int
minrun n0 = (n0 `unsafeShiftR` extra) + if (lowMask .&. n0) > 0 then 1 else 0
where
-- smear the bits down from the most significant bit
!n1 = n0 .|. unsafeShiftR n0 1
!n2 = n1 .|. unsafeShiftR n1 2
!n3 = n2 .|. unsafeShiftR n2 4
!n4 = n3 .|. unsafeShiftR n3 8
!n5 = n4 .|. unsafeShiftR n4 16
!n6 = n5 .|. unsafeShiftR n5 32
```
The call to panic was introduced by Erik in the fix for #5900.
Is the code at fault, or the compiler?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------ |
| Version | 7.10.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (CodeGen) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | erikd |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"PPC.Ppr: Shift by 32 bits is not allowed.","status":"New","operating_system":"","component":"Compiler (CodeGen)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["erikd"],"type":"Bug","description":"Hi,\r\n\r\nwhen compiling `vector-algorithms` on powerpc, I get\r\n{{{\r\n[ 7 of 10] Compiling Data.Vector.Algorithms.Tim ( src/Data/Vector/Algorithms/Tim.hs, dist-ghc/build/Data/Vector/Algorithms/Tim.o )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 7.10.2 for powerpc-unknown-linux):\r\n\tPPC.Ppr: Shift by 32 bits is not allowed.\r\n}}}\r\n\r\nI do not get this error on other 32bit architectures.\r\n\r\nThe offending code seems to be\r\n{{{\r\nminrun :: Int -> Int\r\nminrun n0 = (n0 `unsafeShiftR` extra) + if (lowMask .&. n0) > 0 then 1 else 0\r\n where\r\n -- smear the bits down from the most significant bit\r\n !n1 = n0 .|. unsafeShiftR n0 1\r\n !n2 = n1 .|. unsafeShiftR n1 2\r\n !n3 = n2 .|. unsafeShiftR n2 4\r\n !n4 = n3 .|. unsafeShiftR n3 8\r\n !n5 = n4 .|. unsafeShiftR n4 16\r\n !n6 = n5 .|. unsafeShiftR n5 32\r\n}}}\r\n\r\nThe call to panic was introduced by Erik in the fix for #5900.\r\n\r\nIs the code at fault, or the compiler?","type_of_failure":"OtherFailure","blocking":[]} -->7.10.3https://gitlab.haskell.org/ghc/ghc/-/issues/10855GHC rejects code that Haskell 2010 report accepts2019-07-07T18:33:28ZRichard Eisenbergrae@richarde.devGHC rejects code that Haskell 2010 report acceptsAccording to [The Haskell 2010 Report](https://www.haskell.org/onlinereport/haskell2010/haskellch3.html#x8-220003), the following two modules should compile. But they don't, failing with parse errors:
```
{-# LANGUAGE Haskell2010 #-}
m...According to [The Haskell 2010 Report](https://www.haskell.org/onlinereport/haskell2010/haskellch3.html#x8-220003), the following two modules should compile. But they don't, failing with parse errors:
```
{-# LANGUAGE Haskell2010 #-}
module Bug where
bool = - case b of False -> 0; True -> (-1)
```
```
{-# LANGUAGE Haskell2010 #-}
instance Num (IO a) where
negate = id
main = - do putStrLn "hi!"
```
Note the unary `-` signs.
I'm not sure whether we should complicate the parser to fix these, but we should document the compliance-failure in the manual.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.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":"GHC rejects code that Haskell 2010 report accepts","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"According to [https://www.haskell.org/onlinereport/haskell2010/haskellch3.html#x8-220003 The Haskell 2010 Report], the following two modules should compile. But they don't, failing with parse errors:\r\n\r\n{{{\r\n{-# LANGUAGE Haskell2010 #-}\r\n\r\nmodule Bug where\r\n\r\nbool = - case b of False -> 0; True -> (-1)\r\n}}}\r\n\r\n{{{\r\n{-# LANGUAGE Haskell2010 #-}\r\n\r\ninstance Num (IO a) where\r\n negate = id\r\n\r\nmain = - do putStrLn \"hi!\"\r\n}}}\r\n\r\nNote the unary `-` signs.\r\n\r\nI'm not sure whether we should complicate the parser to fix these, but we should document the compliance-failure in the manual.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.3https://gitlab.haskell.org/ghc/ghc/-/issues/10829Simplification in the RHS of rules2019-07-07T18:33:40ZafarmerSimplification in the RHS of rulesHERMIT users depend on RULES to specify equational properties.
1. 10.2 performed both inlining and simplification in both sides of the rules, meaning they can't really be used for this. This breaks most HERMIT use cases. Note that this ...HERMIT users depend on RULES to specify equational properties.
1. 10.2 performed both inlining and simplification in both sides of the rules, meaning they can't really be used for this. This breaks most HERMIT use cases. Note that this behavior was a change from 7.8 and prior, due to this commit:
https://git.haskell.org/ghc.git/commitdiff/8af219adb914b292d0f8c737fe0a1e3f7fb19cf3
The following commit disables the inlining/simplification in the LHS of rules, which fixes half the problem, but it has yet to be merged and released (attached to ticket #10528):
https://git.haskell.org/ghc.git/commitdiff/bc4b64ca5b99bff6b3d5051b57cb2bc52bd4c841
This ticket is to ask that inlining/simplification also be disabled in the RHS of rules.
As an example of what is happening, we are seeing rules like this:
```
repH :: [a] -> [a] -> [a]
{-# RULES "repH ++" [~] forall xs ys. repH (xs ++ ys) = repH xs . repH ys #-}
```
get to HERMIT as:
```
"repH ++" forall xs ys. repH (xs ++ ys) = let f = repH xs
g = repH ys
in \ z -> f (g z)
```
In this case it is just an unfolding of composition, but some rules get rather gross on the RHS. The extra junk makes equational reasoning with these rules very fiddly and breaks the correspondence with the source-level code. For instance, it is almost impossible to apply these right-to-left, which is a common thing to do when performing equational reasoning.
Some possible solutions:
1. Don't inline/apply rules in the RHS at all (just like the LHS).
1. Don't inline/apply rules in the RHS of rules marked with the NeverActive notation (rules intended for HERMIT use are generally marked NeverActive). Since NeverActive rules are not applied by GHC anyway, this should actually save compile-time work and not affect real programs/rules.
Would either of those be acceptable/possible? Option 1 would be ideal, because it would match the behavior of 7.8 (AFAICT). Option 2 would be sufficient, however.7.10.3https://gitlab.haskell.org/ghc/ghc/-/issues/10826[Security] Safe Haskell can be bypassed via annotations2019-07-07T18:33:42Zspinda[Security] Safe Haskell can be bypassed via annotations```
module Test (hook) where
import System.IO.Unsafe
{-# ANN hook (unsafePerformIO (putStrLn "Woops.")) #-}
hook = undefined
```
```
➜ Test ghc -fpackage-trust -XSafe Test_simple.hs
[1 of 1] Compiling Test_simple ( Test_simple....```
module Test (hook) where
import System.IO.Unsafe
{-# ANN hook (unsafePerformIO (putStrLn "Woops.")) #-}
hook = undefined
```
```
➜ Test ghc -fpackage-trust -XSafe Test_simple.hs
[1 of 1] Compiling Test_simple ( Test_simple.hs, Test_simple.o ) [flags changed]
Woops.
Test_simple.hs:4:1:
System.IO.Unsafe: Can't be safely imported!
The module itself isn't safe.
```
GHC ultimately rejects the program due to the `System.IO.Unsafe` import, but this check doesn't occur until GHC has compiled and run the annotation expression, allowing arbitrary IO operations via `unsafePerformIO`.
The solution is probably to move the import check from the end of renaming/typechecking to the start.7.10.3kanetwkanetwhttps://gitlab.haskell.org/ghc/ghc/-/issues/10817Looping default associated type family without UndecidableInstances2019-07-07T18:33:45ZRichard Eisenbergrae@richarde.devLooping default associated type family without UndecidableInstancesWhen I say
```
{-# LANGUAGE TypeFamilies #-}
module Bug where
import Data.Proxy
class C a where
type F a
type F a = F a
instance C Bool
x :: Proxy (F Bool)
x = Proxy
```
GHC just loops. Setting a low `-ftype-function-depth` do...When I say
```
{-# LANGUAGE TypeFamilies #-}
module Bug where
import Data.Proxy
class C a where
type F a
type F a = F a
instance C Bool
x :: Proxy (F Bool)
x = Proxy
```
GHC just loops. Setting a low `-ftype-function-depth` doesn't help. I actually don't terribly mind the looping (although aborting with an overflow would be better). But I don't like that it's possible without `UndecidableInstances` in sight.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.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":"Looping default associated type family without UndecidableInstances","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When I say\r\n\r\n{{{\r\n{-# LANGUAGE TypeFamilies #-}\r\n\r\nmodule Bug where\r\n\r\nimport Data.Proxy\r\n\r\nclass C a where\r\n type F a\r\n type F a = F a\r\n\r\ninstance C Bool\r\n\r\nx :: Proxy (F Bool)\r\nx = Proxy\r\n}}}\r\n\r\nGHC just loops. Setting a low `-ftype-function-depth` doesn't help. I actually don't terribly mind the looping (although aborting with an overflow would be better). But I don't like that it's possible without `UndecidableInstances` in sight.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.3https://gitlab.haskell.org/ghc/ghc/-/issues/10810Data constructor operators mis-printed in Template Haskell2019-07-07T18:33:46ZRichard Eisenbergrae@richarde.devData constructor operators mis-printed in Template HaskellWhen I say
```
{-# LANGUAGE TemplateHaskell #-}
{-# OPTIONS_GHC -ddump-splices -dsuppress-uniques #-}
module Bug where
$([d| data Foo = (:!) |])
```
I get
```
Bug.hs:6:3-24: Splicing declarations
[d| data Foo = :! |] ======> dat...When I say
```
{-# LANGUAGE TemplateHaskell #-}
{-# OPTIONS_GHC -ddump-splices -dsuppress-uniques #-}
module Bug where
$([d| data Foo = (:!) |])
```
I get
```
Bug.hs:6:3-24: Splicing declarations
[d| data Foo = :! |] ======> data Foo = :!
```
There are missing parentheses in that output.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 7.10.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Template Haskell |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Data constructor operators mis-printed in Template Haskell","status":"New","operating_system":"","component":"Template Haskell","related":[],"milestone":"7.12.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":["newcomer"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When I say\r\n\r\n{{{\r\n{-# LANGUAGE TemplateHaskell #-}\r\n{-# OPTIONS_GHC -ddump-splices -dsuppress-uniques #-}\r\n\r\nmodule Bug where\r\n\r\n$([d| data Foo = (:!) |])\r\n}}}\r\n\r\nI get\r\n\r\n{{{\r\nBug.hs:6:3-24: Splicing declarations\r\n [d| data Foo = :! |] ======> data Foo = :!\r\n}}}\r\n\r\nThere are missing parentheses in that output.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.3https://gitlab.haskell.org/ghc/ghc/-/issues/10795Upgrade gcc in 7.102019-07-07T18:33:50Zjoozek78Upgrade gcc in 7.10See #10777. The patch submitted by snoyberg won't work unless gcc is upgraded (at least to 4.7.0 I think - take a look at [this mail thread](http://sourceforge.net/p/mingw-w64/mailman/message/29339395/)). That's because response files ar...See #10777. The patch submitted by snoyberg won't work unless gcc is upgraded (at least to 4.7.0 I think - take a look at [this mail thread](http://sourceforge.net/p/mingw-w64/mailman/message/29339395/)). That's because response files are not used properly by older gcc.
**gcc was upgraded for 7.12 in #10726 so this just needs to be backported**
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.2 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Upgrade gcc in 7.10","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"7.10.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"See #10777. The patch submitted by snoyberg won't work unless gcc is upgraded (at least to 4.7.0 I think - take a look at [[http://sourceforge.net/p/mingw-w64/mailman/message/29339395/|this mail thread]]). That's because response files are not used properly by older gcc.\r\n\r\n'''gcc was upgraded for 7.12 in #10726 so this just needs to be backported'''","type_of_failure":"OtherFailure","blocking":[]} -->7.10.3