GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:30:45Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/11358GHC generics has differing conFixity behavior between 7.10.3 and 8.12019-07-07T18:30:45ZRyan ScottGHC generics has differing conFixity behavior between 7.10.3 and 8.1Compile the following program with GHC 7.10.3 and 8.1:
```hs
{-# LANGUAGE DefaultSignatures #-}
{-# LANGUAGE DeriveGeneric #-}
{-# LANGUAGE FlexibleContexts #-}
{-# LANGUAGE FlexibleInstances #-}
module Main (main) where
import GHC.Gen...Compile the following program with GHC 7.10.3 and 8.1:
```hs
{-# LANGUAGE DefaultSignatures #-}
{-# LANGUAGE DeriveGeneric #-}
{-# LANGUAGE FlexibleContexts #-}
{-# LANGUAGE FlexibleInstances #-}
module Main (main) where
import GHC.Generics
infixr 1 `T`
data T a = T a a deriving Generic
instance HasFixity (T a)
data I a = a `I` a deriving Generic
instance HasFixity (I a)
class HasFixity a where
fixity :: a -> Fixity
default fixity :: (Generic a, GHasFixity (Rep a)) => a -> Fixity
fixity = gfixity . from
class GHasFixity f where
gfixity :: f a -> Fixity
instance GHasFixity f => GHasFixity (D1 d f) where
gfixity (M1 x) = gfixity x
instance Constructor c => GHasFixity (C1 c f) where
gfixity c = conFixity c
main :: IO ()
main = do
putStrLn $ show (fixity (T "a" "b")) ++ ", " ++ show (fixity ("a" `I` "b"))
```
On GHC 7.10.3, it yields `Prefix, Infix LeftAssociative 9`, but on GHC 8.1, it yields `Infix RightAssociative 1, Prefix`. Why? The implementation of `deriving Generic(1)` changed slightly in GHC 8.1. Before, it would only assign a fixity of `Infix` if a constructor was *declared* infix. But GHC 8.1 no longer checks for this—it first checks if there is a user-supplied fixity declaration, and if so, uses that as the `Fixity`. Otherwise, it defaults to `Prefix`, even if the datatype was declared infix!
The design of `Fixity` perhaps leaves something to be desired, but at the very least, we should ensure nothing `Fixity`-related breaks for now.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------ |
| Version | 8.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler (CodeGen) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | kosmikus |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC generics has differing conFixity behavior between 7.10.3 and 8.1","status":"New","operating_system":"","component":"Compiler (CodeGen)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"RyanGlScott"},"version":"8.1","keywords":["Generics"],"differentials":[],"test_case":"","architecture":"","cc":["kosmikus"],"type":"Bug","description":"Compile the following program with GHC 7.10.3 and 8.1:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE DefaultSignatures #-}\r\n{-# LANGUAGE DeriveGeneric #-}\r\n{-# LANGUAGE FlexibleContexts #-}\r\n{-# LANGUAGE FlexibleInstances #-}\r\nmodule Main (main) where\r\n\r\nimport GHC.Generics\r\n\r\ninfixr 1 `T`\r\ndata T a = T a a deriving Generic\r\ninstance HasFixity (T a)\r\n\r\ndata I a = a `I` a deriving Generic\r\ninstance HasFixity (I a)\r\n\r\nclass HasFixity a where\r\n fixity :: a -> Fixity\r\n default fixity :: (Generic a, GHasFixity (Rep a)) => a -> Fixity\r\n fixity = gfixity . from\r\n\r\nclass GHasFixity f where\r\n gfixity :: f a -> Fixity\r\n\r\ninstance GHasFixity f => GHasFixity (D1 d f) where\r\n gfixity (M1 x) = gfixity x\r\n\r\ninstance Constructor c => GHasFixity (C1 c f) where\r\n gfixity c = conFixity c\r\n\r\nmain :: IO ()\r\nmain = do\r\n putStrLn $ show (fixity (T \"a\" \"b\")) ++ \", \" ++ show (fixity (\"a\" `I` \"b\"))\r\n}}}\r\n\r\nOn GHC 7.10.3, it yields `Prefix, Infix LeftAssociative 9`, but on GHC 8.1, it yields `Infix RightAssociative 1, Prefix`. Why? The implementation of `deriving Generic(1)` changed slightly in GHC 8.1. Before, it would only assign a fixity of `Infix` if a constructor was ''declared'' infix. But GHC 8.1 no longer checks for this—it first checks if there is a user-supplied fixity declaration, and if so, uses that as the `Fixity`. Otherwise, it defaults to `Prefix`, even if the datatype was declared infix!\r\n\r\nThe design of `Fixity` perhaps leaves something to be desired, but at the very least, we should ensure nothing `Fixity`-related breaks for now.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Ryan ScottRyan Scotthttps://gitlab.haskell.org/ghc/ghc/-/issues/11345Template Haskell's handling of infix GADT constructors is broken2019-07-07T18:30:50ZRyan ScottTemplate Haskell's handling of infix GADT constructors is brokenThere are several infelicities in the way that Template Haskell treats GADT constructors that are declared to be infix. To illustrate:
```hs
{-# LANGUAGE GADTs #-}
{-# LANGUAGE TemplateHaskell #-}
module Main (main) where
import Langua...There are several infelicities in the way that Template Haskell treats GADT constructors that are declared to be infix. To illustrate:
```hs
{-# LANGUAGE GADTs #-}
{-# LANGUAGE TemplateHaskell #-}
module Main (main) where
import Language.Haskell.TH
infixr 7 :***:
data GADT a where
Prefix :: Int -> Int -> GADT Int
(:***:) :: Int -> Int -> GADT Int
$(return [])
main :: IO ()
main = do
putStrLn $(reify ''GADT >>= stringE . pprint)
putStrLn ""
putStrLn $(reify ''GADT >>= stringE . show)
```
This doesn't print out quite what you'd expect:
```
data Main.GADT (a_0 :: *)
= Main.Prefix :: GHC.Types.Int ->
GHC.Types.Int -> Main.GADT GHC.Types.Int
| GHC.Types.Int Main.:***: GHC.Types.Int
TyConI (DataD [] Main.GADT [KindedTV a_1627394505 StarT] Nothing [GadtC [Main.Prefix] [(Bang NoSourceUnpackedness NoSourceStrictness,ConT GHC.Types.Int),(Bang NoSourceUnpackedness NoSourceStrictness,ConT GHC.Types.Int)] Main.GADT [ConT GHC.Types.Int],InfixC (Bang NoSourceUnpackedness NoSourceStrictness,ConT GHC.Types.Int) Main.:***: (Bang NoSourceUnpackedness NoSourceStrictness,ConT GHC.Types.Int)] [])
```
TH thinks that `GADT` is a Haskell98 data declaration when `pprint`-ing it because `(:***:)` is converted to an `InfixC` (see [here](http://git.haskell.org/ghc.git/blob/04f3524f787b2cbd3f460e058c753529d3f2f7ac:/libraries/template-haskell/Language/Haskell/TH/Ppr.hs#l362) for the relevant code). This causes the output to be a strange hodgepodge of Haskell98 and GADT syntax.
Another issue is that even though I can reify `GADT`, I can't splice it back in! Compiling this:
```hs
{-# LANGUAGE GADTs #-}
{-# LANGUAGE TemplateHaskell #-}
module Main (main) where
import Language.Haskell.TH
$(do gadtName <- newName "GADT"
prefixName <- newName "Prefix"
infixName <- newName ":***:"
a <- newName "a"
return [DataD [] gadtName [KindedTV a StarT] Nothing [GadtC [prefixName] [(Bang NoSourceUnpackedness NoSourceStrictness,ConT ''Int),(Bang NoSourceUnpackedness NoSourceStrictness,ConT ''Int)] gadtName [ConT ''Int],InfixC (Bang NoSourceUnpackedness NoSourceStrictness,ConT ''Int) infixName (Bang NoSourceUnpackedness NoSourceStrictness,ConT ''Int)] []])
$(return [])
main :: IO ()
main = do
putStrLn $(reify ''GADT >>= stringE . pprint)
putStrLn ""
putStrLn $(reify ''GADT >>= stringE . show)
```
Results in an error:
```
InfixGADT.hs:12:3: error:
Cannot mix GADT constructors with Haskell 98 constructors
When splicing a TH declaration:
data GADT_0 (a_1 :: *)
= Prefix_2 :: GHC.Types.Int ->
GHC.Types.Int -> GADT_0 GHC.Types.Int
| GHC.Types.Int :***:_3 GHC.Types.Int
```
[This code](http://git.haskell.org/ghc.git/blob/04f3524f787b2cbd3f460e058c753529d3f2f7ac:/compiler/hsSyn/Convert.hs#l191) is responsible. We have an issue where `InfixC` can be either Haskell98 or GADT syntax depending on the context, but in that particular context, there's not a good way to determine it.
I can think of three solutions:
1. Add an `InfixGadtC` constructor. This adds more clutter to `Con`, but is the most straightforward fix.
1. Subsume infix GADT constructors under `GadtC`/`RecGadtC` (depending on if it has records), and treat `InfixC` as always being Haskell98. This wouldn't require any API changes, but it does leave a bit of asymmetry between the Haskell98 and GADT constructors, since there would be three of the former but two of the latter.
1. A radical approach (which subsumes option 2) would be to deprecate `InfixC`, subsume it under `NormalC`/`RecC`, and add an `InfixC` pattern synonym for compatibility. `InfixC` does seem extraneous anyway since you can just use `reifyFixity` to determine if a constructor is infix. That way, you have two Haskell98 and two GADT constructors (but you'd also have to deprecate `InfixC`).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------- |
| Version | 8.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Template Haskell |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | goldfire, jstolarek |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Template Haskell's handling of infix GADT constructors is broken","status":"New","operating_system":"","component":"Template Haskell","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["goldfire","jstolarek"],"type":"Bug","description":"There are several infelicities in the way that Template Haskell treats GADT constructors that are declared to be infix. To illustrate:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE GADTs #-}\r\n{-# LANGUAGE TemplateHaskell #-}\r\nmodule Main (main) where\r\n\r\nimport Language.Haskell.TH\r\n\r\ninfixr 7 :***:\r\ndata GADT a where\r\n Prefix :: Int -> Int -> GADT Int\r\n (:***:) :: Int -> Int -> GADT Int\r\n\r\n$(return [])\r\n\r\nmain :: IO ()\r\nmain = do\r\n putStrLn $(reify ''GADT >>= stringE . pprint)\r\n putStrLn \"\"\r\n putStrLn $(reify ''GADT >>= stringE . show)\r\n}}}\r\n\r\nThis doesn't print out quite what you'd expect:\r\n\r\n{{{\r\ndata Main.GADT (a_0 :: *)\r\n = Main.Prefix :: GHC.Types.Int ->\r\n GHC.Types.Int -> Main.GADT GHC.Types.Int\r\n | GHC.Types.Int Main.:***: GHC.Types.Int\r\n\r\nTyConI (DataD [] Main.GADT [KindedTV a_1627394505 StarT] Nothing [GadtC [Main.Prefix] [(Bang NoSourceUnpackedness NoSourceStrictness,ConT GHC.Types.Int),(Bang NoSourceUnpackedness NoSourceStrictness,ConT GHC.Types.Int)] Main.GADT [ConT GHC.Types.Int],InfixC (Bang NoSourceUnpackedness NoSourceStrictness,ConT GHC.Types.Int) Main.:***: (Bang NoSourceUnpackedness NoSourceStrictness,ConT GHC.Types.Int)] [])\r\n}}}\r\n\r\nTH thinks that `GADT` is a Haskell98 data declaration when `pprint`-ing it because `(:***:)` is converted to an `InfixC` (see [http://git.haskell.org/ghc.git/blob/04f3524f787b2cbd3f460e058c753529d3f2f7ac:/libraries/template-haskell/Language/Haskell/TH/Ppr.hs#l362 here] for the relevant code). This causes the output to be a strange hodgepodge of Haskell98 and GADT syntax.\r\n\r\nAnother issue is that even though I can reify `GADT`, I can't splice it back in! Compiling this:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE GADTs #-}\r\n{-# LANGUAGE TemplateHaskell #-}\r\nmodule Main (main) where\r\n\r\nimport Language.Haskell.TH\r\n\r\n$(do gadtName <- newName \"GADT\"\r\n prefixName <- newName \"Prefix\"\r\n infixName <- newName \":***:\"\r\n a <- newName \"a\"\r\n return [DataD [] gadtName [KindedTV a StarT] Nothing [GadtC [prefixName] [(Bang NoSourceUnpackedness NoSourceStrictness,ConT ''Int),(Bang NoSourceUnpackedness NoSourceStrictness,ConT ''Int)] gadtName [ConT ''Int],InfixC (Bang NoSourceUnpackedness NoSourceStrictness,ConT ''Int) infixName (Bang NoSourceUnpackedness NoSourceStrictness,ConT ''Int)] []])\r\n\r\n$(return [])\r\n\r\nmain :: IO ()\r\nmain = do\r\n putStrLn $(reify ''GADT >>= stringE . pprint)\r\n putStrLn \"\"\r\n putStrLn $(reify ''GADT >>= stringE . show)\r\n}}}\r\n\r\nResults in an error:\r\n\r\n{{{\r\nInfixGADT.hs:12:3: error:\r\n Cannot mix GADT constructors with Haskell 98 constructors\r\n When splicing a TH declaration:\r\n data GADT_0 (a_1 :: *)\r\n = Prefix_2 :: GHC.Types.Int ->\r\n GHC.Types.Int -> GADT_0 GHC.Types.Int\r\n | GHC.Types.Int :***:_3 GHC.Types.Int\r\n}}}\r\n\r\n[http://git.haskell.org/ghc.git/blob/04f3524f787b2cbd3f460e058c753529d3f2f7ac:/compiler/hsSyn/Convert.hs#l191 This code] is responsible. We have an issue where `InfixC` can be either Haskell98 or GADT syntax depending on the context, but in that particular context, there's not a good way to determine it.\r\n\r\nI can think of three solutions:\r\n\r\n1. Add an `InfixGadtC` constructor. This adds more clutter to `Con`, but is the most straightforward fix.\r\n2. Subsume infix GADT constructors under `GadtC`/`RecGadtC` (depending on if it has records), and treat `InfixC` as always being Haskell98. This wouldn't require any API changes, but it does leave a bit of asymmetry between the Haskell98 and GADT constructors, since there would be three of the former but two of the latter.\r\n3. A radical approach (which subsumes option 2) would be to deprecate `InfixC`, subsume it under `NormalC`/`RecC`, and add an `InfixC` pattern synonym for compatibility. `InfixC` does seem extraneous anyway since you can just use `reifyFixity` to determine if a constructor is infix. That way, you have two Haskell98 and two GADT constructors (but you'd also have to deprecate `InfixC`).","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Ryan ScottRyan Scotthttps://gitlab.haskell.org/ghc/ghc/-/issues/11341Reifying a GADT doesn't tell you the correct return type2019-07-07T18:30:51ZRyan ScottReifying a GADT doesn't tell you the correct return typeRunning this example:
```hs
{-# LANGUAGE GADTs, TemplateHaskell #-}
module Main (main) where
import Language.Haskell.TH
type S = T
data T a where
MkT :: S Int
$(return [])
main :: IO ()
main = putStrLn $(reify ''T >>= stringE ....Running this example:
```hs
{-# LANGUAGE GADTs, TemplateHaskell #-}
module Main (main) where
import Language.Haskell.TH
type S = T
data T a where
MkT :: S Int
$(return [])
main :: IO ()
main = putStrLn $(reify ''T >>= stringE . pprint)
```
gives the following result:
```
data Main.T (a_0 :: *) where Main.MkT :: Main.T GHC.Types.Int
```
Shouldn't the return type be `Main.S GHC.Types.Int` instead?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 8.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Template Haskell |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | jstolarek |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Reifying a GADT doesn't tell you the correct return type","status":"New","operating_system":"","component":"Template Haskell","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["jstolarek"],"type":"Bug","description":"Running this example:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE GADTs, TemplateHaskell #-}\r\nmodule Main (main) where\r\n\r\nimport Language.Haskell.TH\r\n\r\ntype S = T\r\n\r\ndata T a where\r\n MkT :: S Int\r\n\r\n$(return [])\r\n\r\nmain :: IO ()\r\nmain = putStrLn $(reify ''T >>= stringE . pprint)\r\n}}}\r\n\r\ngives the following result:\r\n\r\n{{{\r\ndata Main.T (a_0 :: *) where Main.MkT :: Main.T GHC.Types.Int\r\n}}}\r\n\r\nShouldn't the return type be `Main.S GHC.Types.Int` instead?","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Jan Stolarekjan.stolarek@ed.ac.ukJan Stolarekjan.stolarek@ed.ac.ukhttps://gitlab.haskell.org/ghc/ghc/-/issues/11298Implicit call stack empty in instance declarations2019-07-07T18:31:03ZpikajudeImplicit call stack empty in instance declarationsGiven the following code:
```hs
{-# LANGUAGE ImplicitParams #-}
import GHC.Stack
class Foo a where
foo :: a -> String
main = putStrLn $ foo ()
```
In GHC 7.11.20151216, the following instances result in no output:
```hs
instanc...Given the following code:
```hs
{-# LANGUAGE ImplicitParams #-}
import GHC.Stack
class Foo a where
foo :: a -> String
main = putStrLn $ foo ()
```
In GHC 7.11.20151216, the following instances result in no output:
```hs
instance Foo () where
foo () = prettyCallStack ?loc
```
```hs
fooHelper = prettyCallStack ?loc
instance Foo () where
foo () = fooHelper
```
Though this one does:
```hs
fooHelper () = prettyCallStack ?loc
instance Foo () where
foo = fooHelper
{-
CallStack (from ImplicitParams):
fooHelper, called at implicit.hs:11:11 in main:Main
-}
```
Including explicit signatures with `-XInstanceSigs` has no effect.
The aforementioned instances all yield output with GHC 7.10.3 (after replacing `prettyCallStack` with `showCallStack`):
```
?loc, called at implicit.hs:9:28 in main:Main
```8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/11297CmmSwitchTest is broken on 32-bit platforms2019-07-07T18:31:03ZBen GamariCmmSwitchTest is broken on 32-bit platforms```
Actual stdout output differs from expected:
--- /dev/null 2015-12-26 13:34:29.750000000 +0100
+++ ./codeGen/should_run/CmmSwitchTest.run.stdout.normalised 2015-12-26 22:14:17.937137588 +0100
@@ -0,0 +1,57 @@
+ERR: aj (-1) is 133...```
Actual stdout output differs from expected:
--- /dev/null 2015-12-26 13:34:29.750000000 +0100
+++ ./codeGen/should_run/CmmSwitchTest.run.stdout.normalised 2015-12-26 22:14:17.937137588 +0100
@@ -0,0 +1,57 @@
+ERR: aj (-1) is 1337 and not 41.
+ERR: ak (-11) is 1337 and not 36.
+ERR: ak (-10) is 1337 and not 37.
+ERR: ak (-9) is 1337 and not 37.
+ERR: ak (-8) is 1337 and not 38.
+ERR: ak (-7) is 1337 and not 38.
+ERR: ak (-6) is 1337 and not 39.
+ERR: ak (-5) is 1337 and not 39.
+ERR: ak (-4) is 1337 and not 40.
+ERR: ak (-3) is 1337 and not 40.
+ERR: ak (-2) is 1337 and not 41.
+ERR: ak (-1) is 1337 and not 41.
+ERR: al (0) is 1337 and not 42.
+ERR: al (1) is 1337 and not 42.
+ERR: al (2) is 1337 and not 43.
+ERR: al (3) is 1337 and not 43.
+ERR: al (4) is 1337 and not 44.
+ERR: al (5) is 1337 and not 44.
+ERR: al (6) is 1337 and not 45.
+ERR: al (7) is 1337 and not 45.
+ERR: al (8) is 1337 and not 46.
+ERR: al (9) is 1337 and not 46.
+ERR: al (10) is 1337 and not 47.
+ERR: al (-11) is 1337 and not 36.
+ERR: al (-10) is 1337 and not 37.
+ERR: al (-9) is 1337 and not 37.
+ERR: al (-8) is 1337 and not 38.
+ERR: al (-7) is 1337 and not 38.
+ERR: al (-6) is 1337 and not 39.
+ERR: al (-5) is 1337 and not 39.
+ERR: al (-4) is 1337 and not 40.
+ERR: al (-3) is 1337 and not 40.
+ERR: al (-2) is 1337 and not 41.
+ERR: al (-1) is 1337 and not 41.
+ERR: ay (4294967295) is 1337 and not 41.
+ERR: az (4294967285) is 1337 and not 36.
+ERR: az (4294967286) is 1337 and not 37.
+ERR: az (4294967287) is 1337 and not 37.
+ERR: az (4294967288) is 1337 and not 38.
+ERR: az (4294967289) is 1337 and not 38.
+ERR: az (4294967290) is 1337 and not 39.
+ERR: az (4294967291) is 1337 and not 39.
+ERR: az (4294967292) is 1337 and not 40.
+ERR: az (4294967293) is 1337 and not 40.
+ERR: az (4294967294) is 1337 and not 41.
+ERR: az (4294967295) is 1337 and not 41.
+ERR: ba (4294967285) is 1337 and not 36.
+ERR: ba (4294967286) is 1337 and not 37.
+ERR: ba (4294967287) is 1337 and not 37.
+ERR: ba (4294967288) is 1337 and not 38.
+ERR: ba (4294967289) is 1337 and not 38.
+ERR: ba (4294967290) is 1337 and not 39.
+ERR: ba (4294967291) is 1337 and not 39.
+ERR: ba (4294967292) is 1337 and not 40.
+ERR: ba (4294967293) is 1337 and not 40.
+ERR: ba (4294967294) is 1337 and not 41.
+ERR: ba (4294967295) is 1337 and not 41.
\ No newline at end of file
*** unexpected failure for CmmSwitchTest(normal)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.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":"CmmSwitchTest fails on arm","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.0.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"bgamari"},"version":"7.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\nActual stdout output differs from expected:\r\n--- /dev/null 2015-12-26 13:34:29.750000000 +0100\r\n+++ ./codeGen/should_run/CmmSwitchTest.run.stdout.normalised 2015-12-26 22:14:17.937137588 +0100\r\n@@ -0,0 +1,57 @@\r\n+ERR: aj (-1) is 1337 and not 41.\r\n+ERR: ak (-11) is 1337 and not 36.\r\n+ERR: ak (-10) is 1337 and not 37.\r\n+ERR: ak (-9) is 1337 and not 37.\r\n+ERR: ak (-8) is 1337 and not 38.\r\n+ERR: ak (-7) is 1337 and not 38.\r\n+ERR: ak (-6) is 1337 and not 39.\r\n+ERR: ak (-5) is 1337 and not 39.\r\n+ERR: ak (-4) is 1337 and not 40.\r\n+ERR: ak (-3) is 1337 and not 40.\r\n+ERR: ak (-2) is 1337 and not 41.\r\n+ERR: ak (-1) is 1337 and not 41.\r\n+ERR: al (0) is 1337 and not 42.\r\n+ERR: al (1) is 1337 and not 42.\r\n+ERR: al (2) is 1337 and not 43.\r\n+ERR: al (3) is 1337 and not 43.\r\n+ERR: al (4) is 1337 and not 44.\r\n+ERR: al (5) is 1337 and not 44.\r\n+ERR: al (6) is 1337 and not 45.\r\n+ERR: al (7) is 1337 and not 45.\r\n+ERR: al (8) is 1337 and not 46.\r\n+ERR: al (9) is 1337 and not 46.\r\n+ERR: al (10) is 1337 and not 47.\r\n+ERR: al (-11) is 1337 and not 36.\r\n+ERR: al (-10) is 1337 and not 37.\r\n+ERR: al (-9) is 1337 and not 37.\r\n+ERR: al (-8) is 1337 and not 38.\r\n+ERR: al (-7) is 1337 and not 38.\r\n+ERR: al (-6) is 1337 and not 39.\r\n+ERR: al (-5) is 1337 and not 39.\r\n+ERR: al (-4) is 1337 and not 40.\r\n+ERR: al (-3) is 1337 and not 40.\r\n+ERR: al (-2) is 1337 and not 41.\r\n+ERR: al (-1) is 1337 and not 41.\r\n+ERR: ay (4294967295) is 1337 and not 41.\r\n+ERR: az (4294967285) is 1337 and not 36.\r\n+ERR: az (4294967286) is 1337 and not 37.\r\n+ERR: az (4294967287) is 1337 and not 37.\r\n+ERR: az (4294967288) is 1337 and not 38.\r\n+ERR: az (4294967289) is 1337 and not 38.\r\n+ERR: az (4294967290) is 1337 and not 39.\r\n+ERR: az (4294967291) is 1337 and not 39.\r\n+ERR: az (4294967292) is 1337 and not 40.\r\n+ERR: az (4294967293) is 1337 and not 40.\r\n+ERR: az (4294967294) is 1337 and not 41.\r\n+ERR: az (4294967295) is 1337 and not 41.\r\n+ERR: ba (4294967285) is 1337 and not 36.\r\n+ERR: ba (4294967286) is 1337 and not 37.\r\n+ERR: ba (4294967287) is 1337 and not 37.\r\n+ERR: ba (4294967288) is 1337 and not 38.\r\n+ERR: ba (4294967289) is 1337 and not 38.\r\n+ERR: ba (4294967290) is 1337 and not 39.\r\n+ERR: ba (4294967291) is 1337 and not 39.\r\n+ERR: ba (4294967292) is 1337 and not 40.\r\n+ERR: ba (4294967293) is 1337 and not 40.\r\n+ERR: ba (4294967294) is 1337 and not 41.\r\n+ERR: ba (4294967295) is 1337 and not 41.\r\n\\ No newline at end of file\r\n*** unexpected failure for CmmSwitchTest(normal)\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1avdavdhttps://gitlab.haskell.org/ghc/ghc/-/issues/11296T8726 fails on arm2019-07-07T18:31:04ZBen GamariT8726 fails on arm```
cd ./numeric/should_run && ./T8726 </dev/null > T8726.run.stdout 2> T8726.run.stderr
Wrong exit code (expected 0 , actual 1 )
Stdout:
Stderr:
T8726: user error (divMod0 -2 79228162514264337593543950336)
```
<details><summary>Tra...```
cd ./numeric/should_run && ./T8726 </dev/null > T8726.run.stdout 2> T8726.run.stderr
Wrong exit code (expected 0 , actual 1 )
Stdout:
Stderr:
T8726: user error (divMod0 -2 79228162514264337593543950336)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.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":"T8726 fails on arm","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.0.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"bgamari"},"version":"7.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\ncd ./numeric/should_run && ./T8726 </dev/null > T8726.run.stdout 2> T8726.run.stderr\r\nWrong exit code (expected 0 , actual 1 )\r\nStdout:\r\n\r\nStderr:\r\nT8726: user error (divMod0 -2 79228162514264337593543950336)\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/11294T9430 fails on ARM2019-07-07T18:31:04ZBen GamariT9430 fails on ARMThe primops testcase for `timesWord2#` in `T9430` fails on ARM.
```
cd ./primops/should_run && ./T9430 </dev/null > T9430.run.stdout 2> T9430.run.stderr
Wrong exit code (expected 0 , actual 1 )
Stdout:
Stderr:
T9430: Error for times...The primops testcase for `timesWord2#` in `T9430` fails on ARM.
```
cd ./primops/should_run && ./T9430 </dev/null > T9430.run.stdout 2> T9430.run.stderr
Wrong exit code (expected 0 , actual 1 )
Stdout:
Stderr:
T9430: Error for timesWord2# : Expected 1 and 0 but got 0 and 0
CallStack (from ImplicitParams):
error, called at T9430.hs:55:22 in main:Main
```
It looks like this is probably an 32-bit LLVM code generator bug although I have yet to confirm this.8.0.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/11289T8628 fails on ARM2019-07-07T18:31:06ZBen GamariT8628 fails on ARMThe `ghc-api/T8628` testcase fails on ARM with a runtime linker abort,
```
$ ./T8628 /mnt/work/arm/ghc/ghc-nightly/inplace/lib
T8628: internal error: checkProddableBlock: invalid fixup in runtime linker: 0xb6238ce0
(GHC version 7.11...The `ghc-api/T8628` testcase fails on ARM with a runtime linker abort,
```
$ ./T8628 /mnt/work/arm/ghc/ghc-nightly/inplace/lib
T8628: internal error: checkProddableBlock: invalid fixup in runtime linker: 0xb6238ce0
(GHC version 7.11.20151225 for arm_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 7.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown/Multiple |
| Architecture | Unknown/Multiple |
</details>
<!-- {"blocked_by":[],"summary":"T8628 fails on ARM","status":"New","operating_system":"Unknown/Multiple","component":"Compiler","related":[],"milestone":"8.0.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.11","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown/Multiple","cc":[""],"type":"Bug","description":"The `ghc-api/T8628` testcase fails on ARM with a runtime linker abort,\r\n{{{\r\n$ ./T8628 /mnt/work/arm/ghc/ghc-nightly/inplace/lib\r\nT8628: internal error: checkProddableBlock: invalid fixup in runtime linker: 0xb6238ce0\r\n (GHC version 7.11.20151225 for arm_unknown_linux)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/11275:kind! doesn't reduce type families with poly-kinded return kinds2019-07-07T18:31:09ZRyan Scott:kind! doesn't reduce type families with poly-kinded return kindsOriginally discovered [here](https://mail.haskell.org/pipermail/ghc-devs/2015-December/010831.html), here is a simplified example:
```
$ ghci
GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help
λ> :set -XPolyKinds -XTypeFamil...Originally discovered [here](https://mail.haskell.org/pipermail/ghc-devs/2015-December/010831.html), here is a simplified example:
```
$ ghci
GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help
λ> :set -XPolyKinds -XTypeFamilies
λ> type family Hm :: k where Hm = Int
λ> :kind! Hm
Hm :: k
= Hm
```
Giving `Hm` a monomorphic return kind of `*` makes it work with `:kind!`:
```
$ ghci
GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help
λ> :set -XTypeFamilies
λ> type family Hm :: * where Hm = Int
λ> :kind! Hm
Hm :: *
= Int
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":":kind! doesn't reduce type families with poly-kinded return kinds","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Originally discovered [https://mail.haskell.org/pipermail/ghc-devs/2015-December/010831.html here], here is a simplified example:\r\n\r\n{{{\r\n$ ghci\r\nGHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help\r\nλ> :set -XPolyKinds -XTypeFamilies \r\nλ> type family Hm :: k where Hm = Int\r\nλ> :kind! Hm\r\nHm :: k\r\n= Hm\r\n}}}\r\n\r\nGiving `Hm` a monomorphic return kind of `*` makes it work with `:kind!`:\r\n\r\n{{{\r\n$ ghci\r\nGHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help\r\nλ> :set -XTypeFamilies \r\nλ> type family Hm :: * where Hm = Int\r\nλ> :kind! Hm\r\nHm :: *\r\n= Int\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/11262Test print022: wrong stdout on powerpc642019-07-07T18:31:13ZPeter Trommlerptrommler@acm.orgTest print022: wrong stdout on powerpc64GHCi prints a NUL(?) character instead of an 'x'.
```
()
-test = C 1 32 1.2 1.23 'x' 1 1.2 1.23
+test = C 1 32 1.2 1.23 '/NUL' 1 1.2 1.23
Breakpoint 0 activated at print022.hs:11:1-7
Stopped at print022.hs:11:1-7
_result :: r = _
``...GHCi prints a NUL(?) character instead of an 'x'.
```
()
-test = C 1 32 1.2 1.23 'x' 1 1.2 1.23
+test = C 1 32 1.2 1.23 '/NUL' 1 1.2 1.23
Breakpoint 0 activated at print022.hs:11:1-7
Stopped at print022.hs:11:1-7
_result :: r = _
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Test print022: wrong stdout on powerpc64","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"8.2.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"trommler"},"version":"7.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"GHCi prints a NUL(?) character instead of an 'x'.\r\n\r\n{{{\r\n ()\r\n-test = C 1 32 1.2 1.23 'x' 1 1.2 1.23\r\n+test = C 1 32 1.2 1.23 '/NUL' 1 1.2 1.23\r\n Breakpoint 0 activated at print022.hs:11:1-7\r\n Stopped at print022.hs:11:1-7\r\n _result :: r = _\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.4.1Peter Trommlerptrommler@acm.orgPeter Trommlerptrommler@acm.orghttps://gitlab.haskell.org/ghc/ghc/-/issues/11236Illegal instruction on ARMv7 with official build and simple program (IMX53 bo...2019-07-07T18:31:20ZvarosiIllegal instruction on ARMv7 with official build and simple program (IMX53 board)On IMX53 Quick Start board
http://www.nxp.com/products/interface-and-connectivity/interface-and-system-management/switch-monitoring-ics/i.mx53-quick-start-board:IMX53QSB
With Debian Jessie I'm installing:
https://www.haskell.org/ghc/dow...On IMX53 Quick Start board
http://www.nxp.com/products/interface-and-connectivity/interface-and-system-management/switch-monitoring-ics/i.mx53-quick-start-board:IMX53QSB
With Debian Jessie I'm installing:
https://www.haskell.org/ghc/download_ghc_7_10_2\#linux_armv7
ghc-7.10.2-arm-unknown-linux.tar.xz (108 MB)
When I compile simple program as:
import System.IO
main = putStrLn "Hello World in ARM!"
and then compile and run I got:
"Illegal instruction" message
When we debug it it seems that there is missing end of function and going straight into main function without changing to ARM Thumb instructions.
<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":"Illegal instruction on ARMv7 with official build and simple program (IMX53 board)","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":["ARMv7"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"On IMX53 Quick Start board\r\nhttp://www.nxp.com/products/interface-and-connectivity/interface-and-system-management/switch-monitoring-ics/i.mx53-quick-start-board:IMX53QSB\r\n\r\nWith Debian Jessie I'm installing:\r\nhttps://www.haskell.org/ghc/download_ghc_7_10_2#linux_armv7\r\nghc-7.10.2-arm-unknown-linux.tar.xz (108 MB)\r\n\r\nWhen I compile simple program as:\r\nimport System.IO\r\nmain = putStrLn \"Hello World in ARM!\"\r\n\r\nand then compile and run I got:\r\n\"Illegal instruction\" message\r\n\r\nWhen we debug it it seems that there is missing end of function and going straight into main function without changing to ARM Thumb instructions.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/11230No run-time exception for deferred type errors when error is in a phantom rol...2019-07-07T18:31:22ZdarchonNo run-time exception for deferred type errors when error is in a phantom role positionThe following code:
```hs
{-# LANGUAGE RoleAnnotations #-}
{-# OPTIONS_GHC -fdefer-type-errors #-}
import Control.Exception
newtype Representational a = Representational ()
type role Representational representational
newtype Phantom ...The following code:
```hs
{-# LANGUAGE RoleAnnotations #-}
{-# OPTIONS_GHC -fdefer-type-errors #-}
import Control.Exception
newtype Representational a = Representational ()
type role Representational representational
newtype Phantom a = Phantom ()
type role Phantom phantom
testRepresentational :: Representational Char -> Representational Bool
testRepresentational = id
{-# NOINLINE testRepresentational #-}
testPhantom :: Phantom Char -> Phantom Bool
testPhantom = id
{-# NOINLINE testPhantom #-}
throwsException :: String -> a -> IO ()
throwsException c v = do
result <- try (evaluate v)
case result of
Right _ -> error (c ++ " (Failure): No exception!")
-- #if MIN_VERSION_base(4,9,0)
Left (TypeError _) -> putStrLn (c ++ "(Succes): exception found")
-- #else
-- Left (ErrorCall _) -> putStrLn (c ++ " (Succes): exception found")
-- #endif
main = do
throwsException "representational" testRepresentational
throwsException "phantom" testPhantom
```
Produces the following result in HEAD:
```
representational(Succes): exception found
*** Exception: phantom (Failure): No exception!
CallStack (from ImplicitParams):
error, called at Main.hs:24:16 in main:Main
```
In 7.10.2 (after commenting the `TypeError` line, and uncommenting the `ErrorCall` line), we get the following output:
```
representational (Succes): exception found
phantom (Succes): exception found
```
I think the HEAD result is wrong: deferred type errors should always result in a run-time exception when their associated value is evaluated, regardless of whether the error occurred in a phantom role position or not.
Looking at the core (`ghc -O0 -ddump-simpl`) in HEAD is see:
```
-- RHS size: {terms: 3, types: 15, coercions: 0}
testRepresentational_rqP
:: Representational Char -> Representational Bool
[GblId, Str=DmdType b]
testRepresentational_rqP =
case typeError
@ 'Unlifted
@ (Char ~# Bool)
"Main.hs:13:24: error:\n\
\ \\226\\128\\162 Couldn't match type \\226\\128\\152Char\\226\\128\\153 with \\226\\128\\152Bool\\226\\128\\153\n\
\ Expected type: Representational Char -> Representational Bool\n\
\ Actual type: Representational Bool -> Representational Bool\n\
\ \\226\\128\\162 In the expression: id\n\
\ In an equation for \\226\\128\\152testRepresentational\\226\\128\\153:\n\
\ testRepresentational = id\n\
\(deferred type error)"#
of wild0_00 {
}
-- RHS size: {terms: 1, types: 2, coercions: 10}
testPhantom_rqQ :: Phantom Char -> Phantom Bool
[GblId, Str=DmdType]
testPhantom_rqQ =
(id @ (Phantom Bool))
`cast` ((Phantom <Bool, Char>_P{<*>_N})_R -> <Phantom Bool>_R
:: (Phantom Bool -> Phantom Bool)
~R# (Phantom Char -> Phantom Bool))
```
while in 7.10.2 I see:
```
testRepresentational_rnc
:: Representational Char -> Representational Bool
[GblId, Str=DmdType b]
testRepresentational_rnc =
case Control.Exception.Base.runtimeError
@ (Char ~ Bool)
"Main.hs:13:24:\n\
\ Couldn't match type \\226\\128\\152Char\\226\\128\\153 with \\226\\128\\152Bool\\226\\128\\153\n\
\ Expected type: Representational Char -> Representational Bool\n\
\ Actual type: Representational Bool -> Representational Bool\n\
\ In the expression: id\n\
\ In an equation for \\226\\128\\152testRepresentational\\226\\128\\153:\n\
\ testRepresentational = id\n\
\(deferred type error)"#
of wild_00 {
}
testPhantom_rnd :: Phantom Char -> Phantom Bool
[GblId, Str=DmdType b]
testPhantom_rnd =
case Control.Exception.Base.runtimeError
@ (Char ~ Bool)
"Main.hs:17:15:\n\
\ Couldn't match type \\226\\128\\152Char\\226\\128\\153 with \\226\\128\\152Bool\\226\\128\\153\n\
\ Expected type: Phantom Char -> Phantom Bool\n\
\ Actual type: Phantom Bool -> Phantom Bool\n\
\ In the expression: id\n\
\ In an equation for \\226\\128\\152testPhantom\\226\\128\\153: testPhantom = id\n\
\(deferred type error)"#
of wild_00 {
}
```8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/11185runghc can't find ghc-stage2 on a Windows build2019-07-07T18:31:36ZRyan Scottrunghc can't find ghc-stage2 on a Windows build(Originally [reported](https://mail.haskell.org/pipermail/ghc-devs/2015-December/010729.html) on the ghc-devs mailing list.)
After completing a stage-2 GHC build on Windows, `runghc` does not work at all. Calling it on any file will res...(Originally [reported](https://mail.haskell.org/pipermail/ghc-devs/2015-December/010729.html) on the ghc-devs mailing list.)
After completing a stage-2 GHC build on Windows, `runghc` does not work at all. Calling it on any file will result in the following error:
```
$ .\ghc\inplace\bin\runghc.exe Z.hs
runghc.exe: C:\Users\ryanscot\Documents\Software\ghc\inplace\bin\ghc:
rawSystem: does not exist (No such file or directory)
```
A workaround is to make a symlink to `ghc-stage2` with `ln -s ghc-stage2.exe ghc.exe` in MSYS2. This leads me to believe that Windows' `runghc` is always looking for `ghc` even when it *should* be looking for `ghc-stage2` in this particular scenario.
[This code](http://git.haskell.org/ghc.git/blob/1f1c7c610b0ff26dccaef089e27003497fa25beb:/utils/runghc/Main.hs#l56) in `runghc` looks highly suspect:
```hs
let ghc = takeDirectory (normalise path) </> "ghc"
in uncurry (doIt ghc) $ getGhcArgs args'
```
It probably shouldn't be hardcoding the name `"ghc"` here. On Unix-like OSes, this doesn't appear to be an issue since `runghc` invokes a [shell script](http://git.haskell.org/ghc.git/blob/6d17125dccda76b7aafe33181df822045ff5b9bf:/utils/runghc/runghc.wrapper) that detects the proper `ghc` name and invokes the `runghc` *executable*. On the other hand, I believe on Windows calling `runghc` directly invokes the executable, so the proper name detection never happens.
What would be a proper fix for this? I'm tempted to just have `runghc` check for `ghc-stage2`'s existence and fall back on `ghc`, but I'd like to get the opinions of people familiar with the build system so that the fix is robust.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | thomie |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"runghc can't find ghc-stage2 on a Windows build","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["thomie"],"type":"Bug","description":"(Originally [https://mail.haskell.org/pipermail/ghc-devs/2015-December/010729.html reported] on the ghc-devs mailing list.)\r\n\r\nAfter completing a stage-2 GHC build on Windows, `runghc` does not work at all. Calling it on any file will result in the following error:\r\n\r\n{{{\r\n$ .\\ghc\\inplace\\bin\\runghc.exe Z.hs\r\nrunghc.exe: C:\\Users\\ryanscot\\Documents\\Software\\ghc\\inplace\\bin\\ghc:\r\nrawSystem: does not exist (No such file or directory)\r\n}}}\r\n\r\nA workaround is to make a symlink to `ghc-stage2` with `ln -s ghc-stage2.exe ghc.exe` in MSYS2. This leads me to believe that Windows' `runghc` is always looking for `ghc` even when it ''should'' be looking for `ghc-stage2` in this particular scenario.\r\n\r\n[http://git.haskell.org/ghc.git/blob/1f1c7c610b0ff26dccaef089e27003497fa25beb:/utils/runghc/Main.hs#l56 This code] in `runghc` looks highly suspect:\r\n\r\n{{{#!hs\r\nlet ghc = takeDirectory (normalise path) </> \"ghc\"\r\nin uncurry (doIt ghc) $ getGhcArgs args'\r\n}}}\r\n\r\nIt probably shouldn't be hardcoding the name `\"ghc\"` here. On Unix-like OSes, this doesn't appear to be an issue since `runghc` invokes a [http://git.haskell.org/ghc.git/blob/6d17125dccda76b7aafe33181df822045ff5b9bf:/utils/runghc/runghc.wrapper shell script] that detects the proper `ghc` name and invokes the `runghc` ''executable''. On the other hand, I believe on Windows calling `runghc` directly invokes the executable, so the proper name detection never happens.\r\n\r\nWhat would be a proper fix for this? I'm tempted to just have `runghc` check for `ghc-stage2`'s existence and fall back on `ghc`, but I'd like to get the opinions of people familiar with the build system so that the fix is robust.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/11183Numeric.showFFloat outputs decimal point when it should not.2019-07-07T18:31:36ZDobiasdNumeric.showFFloat outputs decimal point when it should not.```hs
showFFloat Nothing 42 ""
```
The expression above should give "42" but actually gives "42.0". Only showFFloatAlt should do this.
Minimal example: http://ideone.com/yYvqrf
<details><summary>Trac metadata</summary>
| Trac field ...```hs
showFFloat Nothing 42 ""
```
The expression above should give "42" but actually gives "42.0". Only showFFloatAlt should do this.
Minimal example: http://ideone.com/yYvqrf
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.10.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Numeric.showFFloat outputs decimal point when it should not.","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":["Numeric,","showFFloat,","showFFloatAlt"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{#!hs\r\nshowFFloat Nothing 42 \"\"\r\n}}}\r\n\r\nThe expression above should give \"42\" but actually gives \"42.0\". Only showFFloatAlt should do this.\r\n\r\nMinimal example: http://ideone.com/yYvqrf","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/11170(read ".9") :: Double unable to parse2019-07-07T18:31:39Zvarosi(read ".9") :: Double unable to parseFor most languages ".9" is a floating point number equal to 0.9, but in GHC this is unparsable. I don't know if it is by design, but it was unexpected by me. I think that it is good this to be valid parsable to Double string.
What do yo...For most languages ".9" is a floating point number equal to 0.9, but in GHC this is unparsable. I don't know if it is by design, but it was unexpected by me. I think that it is good this to be valid parsable to Double string.
What do you think of?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.10.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Prelude |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Windows |
| Architecture | x86_64 (amd64) |
</details>
<!-- {"blocked_by":[],"summary":"(read \".9\") :: Double unable to parse","status":"New","operating_system":"Windows","component":"Prelude","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":["Read"],"differentials":[],"test_case":"","architecture":"x86_64 (amd64)","cc":[""],"type":"Bug","description":"For most languages \".9\" is a floating point number equal to 0.9, but in GHC this is unparsable. I don't know if it is by design, but it was unexpected by me. I think that it is good this to be valid parsable to Double string.\r\n\r\nWhat do you think of?","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/11051GHCi with +t option set shows type representations2019-07-07T18:32:24ZBen GamariGHCi with +t option set shows type representationshvr reported this morning that defining a data type in GHCi with the show types (`:set +t`) option set results in additional unexpected output. For instance,
```
$ inplace/bin/ghc-stage2 --interactive
GHCi, version 7.11.20151101: http:/...hvr reported this morning that defining a data type in GHCi with the show types (`:set +t`) option set results in additional unexpected output. For instance,
```
$ inplace/bin/ghc-stage2 --interactive
GHCi, version 7.11.20151101: http://www.haskell.org/ghc/ :? for help
Prelude> :set +t
Prelude> data Hi
$tcHi :: TyCon
$trModule :: Module
data Hi
Prelude>
```
The `$tcHi` and `$trModule` bindings are details of the Typeable implementation introduced in [D1404](https://phabricator.haskell.org/D1404) and should likely be hidden from the user.
This would be trivial to fix in `InteractiveUI.printTypeOfNames` except for the fact that we currently have no way to identify this sort of `Name`. In fact any knowledge that the name was generated appears to have been thrown away as early as `OccName.mkTyConRepSysOcc`.8.0.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/11041EventLog write fails if entire buffer is not written2019-07-07T18:32:27ZsseveranceEventLog write fails if entire buffer is not writtenRecently I was trying to use ThreadScope to run down a performance issue. I ran into what I believe is a corner case with flushing the eventlog data to disk. The program was generating hundreds of millions of events every few minutes.
T...Recently I was trying to use ThreadScope to run down a performance issue. I ran into what I believe is a corner case with flushing the eventlog data to disk. The program was generating hundreds of millions of events every few minutes.
The function `printAndClearEventBuf` uses `fwrite` to flush the buffer to disk. What I observed is that with larger buffers it would only succeed in writing the first 4096 bytes. After it would print out its `debugBelch` message a number of times the program would crash. It does not crash if not run with the eventlog `-l` flag.
My understanding is that `fwrite` might need to be called in a loop to ensure that all data is written. `fwrite` is not guaranteed to always write the entire requested buffer.
I don't have a good test case for this, but if there is agreement about potential issues with flushing the buffer I am more than happy to provide a patch.8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/11001BlockedIndefinitelyOnMVar thrown with live reference in unrelated finalizer2019-07-07T18:32:43ZexFalsoBlockedIndefinitelyOnMVar thrown with live reference in unrelated finalizerI am not sure whether this is a bug, but it is certainly unexpected behaviour. The following code throws a BlockedIndefinitelyOnMVar in the forked thread even though the MVar would be eventually written to by an unrelated finalizer:
```...I am not sure whether this is a bug, but it is certainly unexpected behaviour. The following code throws a BlockedIndefinitelyOnMVar in the forked thread even though the MVar would be eventually written to by an unrelated finalizer:
```hs
import Control.Concurrent
import Data.IORef
main :: IO ()
main = do
mvar <- newEmptyMVar
-- _ <- forkIO $ threadDelay 9999999999999 >> isEmptyMVar mvar >> return ()
ref <- newIORef () -- unrelated IORef
_ <- mkWeakIORef ref (putMVar mvar ()) -- register finalizer
_ <- forkFinally (takeMVar mvar :: IO ()) print
threadDelay 1000000
```
And indeed, if the forkIO line is uncommented no exception is thrown, as the new thread keeps another live reference to the MVar. Is this intended behaviour? Why does the MVar reference in the finalizer not count for BlockedIndefinitelyOnMVar?
(A similar thing happens with STM primitives.)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.10.2 |
| 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":"BlockedIndefinitelyOnMVar thrown with live reference in unrelated finalizer","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":["BlockedIndefinitelyOnMVar","finalize"],"differentials":[],"test_case":"","architecture":"","cc":["simonmar"],"type":"Bug","description":"I am not sure whether this is a bug, but it is certainly unexpected behaviour. The following code throws a BlockedIndefinitelyOnMVar in the forked thread even though the MVar would be eventually written to by an unrelated finalizer:\r\n\r\n{{{#!hs\r\nimport Control.Concurrent\r\nimport Data.IORef\r\n\r\nmain :: IO ()\r\nmain = do\r\n mvar <- newEmptyMVar\r\n -- _ <- forkIO $ threadDelay 9999999999999 >> isEmptyMVar mvar >> return ()\r\n ref <- newIORef () -- unrelated IORef\r\n _ <- mkWeakIORef ref (putMVar mvar ()) -- register finalizer\r\n _ <- forkFinally (takeMVar mvar :: IO ()) print\r\n threadDelay 1000000\r\n}}}\r\n\r\nAnd indeed, if the forkIO line is uncommented no exception is thrown, as the new thread keeps another live reference to the MVar. Is this intended behaviour? Why does the MVar reference in the finalizer not count for BlockedIndefinitelyOnMVar?\r\n\r\n(A similar thing happens with STM primitives.)","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/10940Random number chosen by openTempFile is always 18042893838469308862019-07-07T18:32:58ZAnders KaseorgRandom number chosen by openTempFile is always 1804289383846930886```hs
import System.Directory
import System.IO
main = do
(p, _) <- openTempFile "/tmp" ""
print p
removeFile p
```
```console
$ runghc temp.hs
"/tmp/1804289383846930886"
$ runghc temp.hs
"/tmp/1804289383846930886"
$ runghc temp.hs...```hs
import System.Directory
import System.IO
main = do
(p, _) <- openTempFile "/tmp" ""
print p
removeFile p
```
```console
$ runghc temp.hs
"/tmp/1804289383846930886"
$ runghc temp.hs
"/tmp/1804289383846930886"
$ runghc temp.hs
"/tmp/1804289383846930886"
$ runghc temp.hs
"/tmp/1804289383846930886"
```
This “random” number is the concatenation of the first two numbers 1804289383, 846930886 returned by glibc’s `rand()` when not seeded (or seeded with 1).
This is not immediately a library security bug, I think: the file is created with `O_EXCL`, and if it already exists, `openTempFile` will move onto the next value 16816927771714636915, and so on. However, the predictable filenames make a potential application security bug that much more likely.
(For your amusement, [Google 1804289383846930886](https://www.google.com/search?q=1804289383846930886).)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.10.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Random number chosen by openTempFile is always 1804289383846930886","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{#!hs\r\nimport System.Directory\r\nimport System.IO\r\nmain = do\r\n (p, _) <- openTempFile \"/tmp\" \"\"\r\n print p\r\n removeFile p\r\n}}}\r\n\r\n{{{#!console\r\n$ runghc temp.hs\r\n\"/tmp/1804289383846930886\"\r\n$ runghc temp.hs\r\n\"/tmp/1804289383846930886\"\r\n$ runghc temp.hs\r\n\"/tmp/1804289383846930886\"\r\n$ runghc temp.hs\r\n\"/tmp/1804289383846930886\"\r\n}}}\r\n\r\nThis “random” number is the concatenation of the first two numbers 1804289383, 846930886 returned by glibc’s `rand()` when not seeded (or seeded with 1).\r\n\r\nThis is not immediately a library security bug, I think: the file is created with `O_EXCL`, and if it already exists, `openTempFile` will move onto the next value 16816927771714636915, and so on. However, the predictable filenames make a potential application security bug that much more likely.\r\n\r\n(For your amusement, [https://www.google.com/search?q=1804289383846930886 Google 1804289383846930886].)","type_of_failure":"OtherFailure","blocking":[]} -->Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/10891`reify` doesn't find associated type families2019-07-07T18:33:11Zantalsz`reify` doesn't find associated type familiesTemplate Haskell's `reify` doesn't find the the associated type families of a type class. Consider the following two classes:
```hs
class C a where
f :: a -> Int
class C' a where
type F a :: *
f' :: a -> Int
```
These produce id...Template Haskell's `reify` doesn't find the the associated type families of a type class. Consider the following two classes:
```hs
class C a where
f :: a -> Int
class C' a where
type F a :: *
f' :: a -> Int
```
These produce identical, up to renaming, output when passed to `reify`:
```hs
-- putStrLn $(stringE . show =<< reify ''C)
ClassI (ClassD [] Ghci1.C [PlainTV a_1627398388] []
[SigD Ghci1.f
(ForallT [PlainTV a_1627398388]
[ClassP Ghci1.C [VarT a_1627398388]]
(AppT (AppT ArrowT (VarT a_1627398388))
(ConT GHC.Types.Int)))])
[]
-- putStrLn $(stringE . show =<< reify ''C')
ClassI (ClassD [] Ghci3.C' [PlainTV a_1627405973] []
[SigD Ghci3.f'
(ForallT [PlainTV a_1627405973]
[ClassP Ghci3.C' [VarT a_1627405973]]
(AppT (AppT ArrowT (VarT a_1627405973))
(ConT GHC.Types.Int)))])
[]
```
If I know the name of `F`, I can look up information about it:
```hs
-- putStrLn $(stringE . show =<< reify ''F)
FamilyI (FamilyD TypeFam
Ghci3.F
[PlainTV a_1627405973]
(Just StarT))
[]
```
But I can't find the name of `F` in the first place. Even if I add an instance of the type class, the `InstanceD` has none of the information about the definition. Given
```hs
instance C' [a] where
type F [a] = a
f' = length
```
we get
```hs
-- putStrLn $(stringE . show =<< reify ''C')
ClassI (ClassD [] Ghci3.C' [PlainTV a_1627405973] []
[SigD Ghci3.f'
(ForallT [PlainTV a_1627405973]
[ClassP Ghci3.C' [VarT a_1627405973]]
(AppT (AppT ArrowT (VarT a_1627405973))
(ConT GHC.Types.Int)))])
[InstanceD []
(AppT (ConT Ghci3.C')
(AppT ListT (VarT a_1627406161)))
[]]
```
This problem was confirmed to exist in the following configurations:
- GHC 7.10.2 with version 2.10.0.0 of the template-haskell package.
- GHC 7.8.3 with version 2.9.0.0 of the template-haskell package.
- GHC 7.4.2 with version 2.7.0.0 of the template-haskell package.
(I also posted this on Stack Overflow in //2013//, where it has been languishing ever since: http://stackoverflow.com/q/17247880/237428.)8.0.1Ömer Sinan AğacanÖmer Sinan Ağacan