GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:15:40Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/14775GHC 8.4.1-alpha3 regression: Build error when `build-type: Custom` and `licen...2019-07-07T18:15:40ZAndrés Sicard-RamírezGHC 8.4.1-alpha3 regression: Build error when `build-type: Custom` and `license: OtherLicense` are in the .cabal fileI got an error installing Agda upstream. I could reduce the error when `build-type: Custom` and `license: OtherLicense` are in the .cabal file:
`Foo.cabal`:
```
name: Foo
version: 0.1.0.0
license: ...I got an error installing Agda upstream. I could reduce the error when `build-type: Custom` and `license: OtherLicense` are in the .cabal file:
`Foo.cabal`:
```
name: Foo
version: 0.1.0.0
license: OtherLicense
build-type: Custom
cabal-version: >=1.10
library
exposed-modules: Foo
build-depends: base
default-language: Haskell2010
```
`Foo.hs`:
```hs
module Foo where
foo :: Int -> Int
foo n = n
```
`Setup.hs`:
```hs
import Distribution.Simple
main = defaultMain
```
The error:
```
$ cabal install
Failed to install Foo-0.1.0.0
cabal: Error: some packages failed to install:
Foo-0.1.0.0-33ReQaKfqaD7MoDL7J5kFM failed during the final install step. The
exception was:
dieVerbatim: user error (cabal: Couldn't parse the output of 'setup register
--gen-pkg-config':NoParse
"license" 5
)
```
`cabal-install` version:
```
$ cabal --version
cabal-install version 2.0.0.1
compiled using version 2.0.1.0 of the Cabal library
```
If I change the `license` field *or* the `build` field, the error disappeared. I didn't get the above error using GHC 8.4.1-alpha2.https://gitlab.haskell.org/ghc/ghc/-/issues/14776Add equality rule for `eqString`2019-07-07T18:15:40ZMatthew PickeringAdd equality rule for `eqString`Locally I sometimes have to define a rule
```
{-# RULES "eqStringEQ" forall x . eqString x x = True #-}
```
in order for "stuck" expressions to evaluate to `True` and for a case expression to be eliminated.
Is there is a reason not to...Locally I sometimes have to define a rule
```
{-# RULES "eqStringEQ" forall x . eqString x x = True #-}
```
in order for "stuck" expressions to evaluate to `True` and for a case expression to be eliminated.
Is there is a reason not to include this RULE directly in GHC.Base?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.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":"Add equality rule for `eqString`","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Locally I sometimes have to define a rule\r\n\r\n{{{\r\n{-# RULES \"eqStringEQ\" forall x . eqString x x = True #-}\r\n}}}\r\n\r\nin order for \"stuck\" expressions to evaluate to `True` and for a case expression to be eliminated. \r\n\r\nIs there is a reason not to include this RULE directly in GHC.Base?","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14777panic when using a function defined in terms of `error`2021-07-05T13:30:54ZZilin Chenzilin.chen@data61.csiro.aupanic when using a function defined in terms of `error`The error message I got from GHC was:
```
<no location info>: error:
ghc: panic! (the 'impossible' happened)
(GHC version 8.2.2 for x86_64-unknown-linux):
idInfo
t_XG0J
Call stack:
CallStack (from HasCallStack):
...The error message I got from GHC was:
```
<no location info>: error:
ghc: panic! (the 'impossible' happened)
(GHC version 8.2.2 for x86_64-unknown-linux):
idInfo
t_XG0J
Call stack:
CallStack (from HasCallStack):
prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable
callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable
pprPanic, called at compiler/basicTypes/Var.hs:526:34 in ghc:Var
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
How was it triggerred (in short):
There's function definition, `f x = undefined`. If I change it to `f x = __impossible "Oops!"`, ghc crashes. If I change it to `f x = error "Oops!"`, it's OK. The definition of `__impossible` is simply `__impossible s = error $ s ++ "some text"`.
The code can be found here: https://github.com/NICTA/cogent/blob/9420861128a8c445138aa6a48c62140d8c5f72eb/cogent/src/Cogent/Desugar.hs\#L482 and https://github.com/NICTA/cogent/blob/9420861128a8c445138aa6a48c62140d8c5f72eb/cogent/src/Cogent/Compiler.hs\#L30
It seems that this bug is not limited to 8.2.2; it also happened in 8.2.1.
I'm happy to provide more information, if someone can advice me what is needed. I'll also try to shrink it to a small test case.8.6.1Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/14778FunDep origin not correctly attributed2019-07-07T18:15:39ZSimon Peyton JonesFunDep origin not correctly attributedIn `TcInteract.improveTopFunEqs` we do not give the derived constraints an origin of `FunDepOrigin`. As a result, `dropDerivedSimples` will discard even an insoluble constraint arising from a fundep. In contrast class instance fundeps do...In `TcInteract.improveTopFunEqs` we do not give the derived constraints an origin of `FunDepOrigin`. As a result, `dropDerivedSimples` will discard even an insoluble constraint arising from a fundep. In contrast class instance fundeps do have `FunDepOrigin` and are kept.
This is at least inconsistent. And we get less good error messages.
Shows up in tests `T13651, `TR8450`, `T13506`, `T14325\`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.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":"FunDep origin not correctly attributed","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":["FunDeps"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In `TcInteract.improveTopFunEqs` we do not give the derived constraints an origin of `FunDepOrigin`. As a result, `dropDerivedSimples` will discard even an insoluble constraint arising from a fundep. In contrast class instance fundeps do have `FunDepOrigin` and are kept.\r\n\r\nThis is at least inconsistent. And we get less good error messages.\r\n\r\nShows up in tests `T13651, `TR8450`, `T13506`, `T14325`.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14779Compiling with -g fails -lint-core checks2019-07-07T18:15:39ZniteriaCompiling with -g fails -lint-core checksCompiling the attached file produces:
```
$ inplace/bin/ghc-stage2 -O -dcore-lint -g -c Data.Fixed.hs
*** Core Lint errors : in result of Simplifier ***
<no location info>: warning:
[RHS of str_s2UI :: Addr#]
The type of this bi...Compiling the attached file produces:
```
$ inplace/bin/ghc-stage2 -O -dcore-lint -g -c Data.Fixed.hs
*** Core Lint errors : in result of Simplifier ***
<no location info>: warning:
[RHS of str_s2UI :: Addr#]
The type of this binder is unlifted: str_s2UI
Binder's type: Addr#
*** Offending Program ***
...
str_s2UI :: Addr#
[LclId,
Unf=Unf{Src=<vanilla>, TopLvl=False, Value=True, ConLike=True,
WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 30 0}]
str_s2UI = src<Data.Fixed.hs:78:31-39> "MkFixed"#
str_a2j4 :: String
[LclId,
Unf=Unf{Src=<vanilla>, TopLvl=False, Value=False, ConLike=True,
WorkFree=False, Expandable=True, Guidance=IF_ARGS [] 20 0}]
str_a2j4 = src<Data.Fixed.hs:78:31-39> unpackCString# str_s2UI
...
```
This came up when I wanted to compile GHC HEAD with `-g`.
There are a couple of related tickets, but some of them didn't reproduce. This is a small, self-contained example.
I'm hoping that it would be possible to solve this without fully solving #14123 which seems to have bigger scope.
My HEAD is d2511e3b61563ed3fc2c9aec2c90a4156373a24c.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------------------- |
| Version | |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Debugging) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | bgamari, simonmar, simonpj |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Compiling with -g fails -lint-core checks","status":"New","operating_system":"","component":"Compiler (Debugging)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["bgamari","simonmar","simonpj"],"type":"Bug","description":"Compiling the attached file produces:\r\n{{{\r\n$ inplace/bin/ghc-stage2 -O -dcore-lint -g -c Data.Fixed.hs\r\n*** Core Lint errors : in result of Simplifier ***\r\n<no location info>: warning:\r\n [RHS of str_s2UI :: Addr#]\r\n The type of this binder is unlifted: str_s2UI\r\n Binder's type: Addr#\r\n*** Offending Program ***\r\n...\r\nstr_s2UI :: Addr#\r\n[LclId,\r\n Unf=Unf{Src=<vanilla>, TopLvl=False, Value=True, ConLike=True,\r\n WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 30 0}]\r\nstr_s2UI = src<Data.Fixed.hs:78:31-39> \"MkFixed\"#\r\n\r\nstr_a2j4 :: String\r\n[LclId,\r\n Unf=Unf{Src=<vanilla>, TopLvl=False, Value=False, ConLike=True,\r\n WorkFree=False, Expandable=True, Guidance=IF_ARGS [] 20 0}]\r\nstr_a2j4 = src<Data.Fixed.hs:78:31-39> unpackCString# str_s2UI\r\n...\r\n}}}\r\n\r\n\r\nThis came up when I wanted to compile GHC HEAD with `-g`. \r\nThere are a couple of related tickets, but some of them didn't reproduce. This is a small, self-contained example.\r\nI'm hoping that it would be possible to solve this without fully solving #14123 which seems to have bigger scope.\r\n\r\nMy HEAD is d2511e3b61563ed3fc2c9aec2c90a4156373a24c.","type_of_failure":"OtherFailure","blocking":[]} -->8.4.2https://gitlab.haskell.org/ghc/ghc/-/issues/14780:type-at doesn't work when :load-ing with module name instead of file path2019-07-07T18:15:39Zjol:type-at doesn't work when :load-ing with module name instead of file pathAfter running
```sh
stack new something
cd something
```
we have a file in src/Lib.hs with the contents:
```hs
module Lib
( someFunc
) where
someFunc :: IO ()
someFunc = putStrLn "someFunc"
```
If we start `stack ghci`, we c...After running
```sh
stack new something
cd something
```
we have a file in src/Lib.hs with the contents:
```hs
module Lib
( someFunc
) where
someFunc :: IO ()
someFunc = putStrLn "someFunc"
```
If we start `stack ghci`, we can have the following session showing the errors:
```
> :set +c
> :l Lib
[1 of 1] Compiling Lib ( /home/jol/work-for/me/something/src/Lib.hs, interpreted )
Ok, one module loaded.
Collecting type info for 1 module(s) ...
> :type-at Lib 6 12 6 20
<no location info>: error: not an expression: ‘’
> :type-at src/Lib.hs 6 12 6 20
Couldn't guess that module name. Does it exist?
```
If we had done `:l src/Lib.hs` instead, then we can use the filepath like the following, but still not the module name:
```
> :set +c
> :l src/Lib.hs
[1 of 1] Compiling Lib ( src/Lib.hs, interpreted )
Ok, one module loaded.
Collecting type info for 1 module(s) ...
> :type-at Lib 6 12 6 20
<no location info>: error: not an expression: ‘’
> :type-at src/Lib.hs 6 12 6 20
:: String -> IO ()
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.2 |
| 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":":type-at doesn't work when :load-ing with module name instead of file path","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"After running\r\n\r\n{{{#!sh\r\nstack new something\r\ncd something\r\n}}}\r\n\r\nwe have a file in src/Lib.hs with the contents:\r\n\r\n{{{#!hs\r\nmodule Lib\r\n ( someFunc\r\n ) where\r\n\r\nsomeFunc :: IO ()\r\nsomeFunc = putStrLn \"someFunc\"\r\n}}}\r\n\r\nIf we start `stack ghci`, we can have the following session showing the errors:\r\n\r\n{{{\r\n> :set +c\r\n> :l Lib\r\n[1 of 1] Compiling Lib ( /home/jol/work-for/me/something/src/Lib.hs, interpreted )\r\nOk, one module loaded.\r\nCollecting type info for 1 module(s) ... \r\n> :type-at Lib 6 12 6 20\r\n\r\n<no location info>: error: not an expression: ‘’\r\n> :type-at src/Lib.hs 6 12 6 20\r\nCouldn't guess that module name. Does it exist?\r\n}}}\r\n\r\nIf we had done `:l src/Lib.hs` instead, then we can use the filepath like the following, but still not the module name:\r\n\r\n{{{\r\n> :set +c\r\n> :l src/Lib.hs\r\n[1 of 1] Compiling Lib ( src/Lib.hs, interpreted )\r\nOk, one module loaded.\r\nCollecting type info for 1 module(s) ... \r\n> :type-at Lib 6 12 6 20\r\n\r\n<no location info>: error: not an expression: ‘’\r\n> :type-at src/Lib.hs 6 12 6 20\r\n :: String -> IO ()\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.10.1Roland SennRoland Sennhttps://gitlab.haskell.org/ghc/ghc/-/issues/14781getNumCapabilities produces incorrect CPU counts2020-09-28T07:11:38ZrtfeldmangetNumCapabilities produces incorrect CPU countsTo reproduce this bug, use the following `main.hs`:
```haskell
import Control.Concurrent
main =
print =<< getNumCapabilities
```
Compile it with `ghc -O2 -threaded --make main.hs -o reproduce` and run `./reproduce` in a virtualized ...To reproduce this bug, use the following `main.hs`:
```haskell
import Control.Concurrent
main =
print =<< getNumCapabilities
```
Compile it with `ghc -O2 -threaded --make main.hs -o reproduce` and run `./reproduce` in a virtualized environment such as Travis CI.
- \*Expected output:\*\* it prints the number of CPU cores available to the process, which in the case of Travis's virtualized environment is 2.
- \*Actual output:\*\* it prints the number of \*physical\* cores on the machine, which in the case of Travis's servers is 32.
## Example of Failure on Travis
Here is an example build on Travis which demonstrates this failing: (scroll to the end of the console log to see the failure) https://travis-ci.org/rtfeldman/repro-ghc-bug/builds/340268785
Here is the repository which was used to reproduce this failure on Travis: https://github.com/rtfeldman/repro-ghc-bug
## Real-World Consequences
The real-world consequences of this bug manifest for the compiler for the Elm programming language, which is written in Haskell and compiled with GHC. By default, `elm-make` runs extremely slowly on Travis and Circle CI because it's trying to parallelize across 32 cores when only 2 are actually available to it.
## How to Fix
For an example implementation which correctly detects the number of available cores (as opposed to physical), here is the source code to a Rust library which does so correctly: https://github.com/seanmonstar/num_cpus/blob/master/src/lib.rs - the library distinguishes between "number of CPUs" and "number of physical CPUs," and on Travis it correctly reports 2 for CPUs and 32 for physical.https://gitlab.haskell.org/ghc/ghc/-/issues/14782typeclass polymorphism defeats bang patterns2019-07-07T18:15:38Zdmwittypeclass polymorphism defeats bang patternsI think the following program should crash, but it doesn't:
```
{-# LANGUAGE BangPatterns #-}
main = let n :: Num a => a; !n = undefined in return ()
```
Interestingly, my attempt to translate this out of BangPatterns into standard Has...I think the following program should crash, but it doesn't:
```
{-# LANGUAGE BangPatterns #-}
main = let n :: Num a => a; !n = undefined in return ()
```
Interestingly, my attempt to translate this out of BangPatterns into standard Haskell according to the translation on the wiki page led to a compile-time error:
```
main = let n :: Num a => a; x@n = undefined in x `seq` return ()
```
Produces the error:
```
test.hs:1:12: error:
• Overloaded signature conflicts with monomorphism restriction
n :: forall a. Num a => a
• In the expression:
let
n :: Num a => a
x@n = undefined
in x `seq` return ()
In an equation for ‘main’:
main
= let
n :: Num a => a
x@n = undefined
in x `seq` return ()
|
1 | main = let n :: Num a => a; x@n = undefined in x `seq` return ()
| ^^^^^^^^^^^^^^^
```
Even giving `x` its own explicitly polymorphic type signature -- what I thought was the standard way to prevent the monomorphism restriction from being a problem -- doesn't help. I'm uncertain what to make of that, but it certainly seems related: earlier versions of the compiler both do not give that error and do produce a crashing program, as I expected.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"typeclass polymorphism defeats bang patterns","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I think the following program should crash, but it doesn't:\r\n\r\n{{{\r\n{-# LANGUAGE BangPatterns #-}\r\nmain = let n :: Num a => a; !n = undefined in return ()\r\n}}}\r\n\r\nInterestingly, my attempt to translate this out of BangPatterns into standard Haskell according to the translation on the wiki page led to a compile-time error:\r\n\r\n{{{\r\nmain = let n :: Num a => a; x@n = undefined in x `seq` return ()\r\n}}}\r\n\r\nProduces the error:\r\n\r\n{{{\r\ntest.hs:1:12: error:\r\n • Overloaded signature conflicts with monomorphism restriction\r\n n :: forall a. Num a => a\r\n • In the expression:\r\n let\r\n n :: Num a => a\r\n x@n = undefined\r\n in x `seq` return ()\r\n In an equation for ‘main’:\r\n main\r\n = let\r\n n :: Num a => a\r\n x@n = undefined\r\n in x `seq` return ()\r\n |\r\n1 | main = let n :: Num a => a; x@n = undefined in x `seq` return ()\r\n | ^^^^^^^^^^^^^^^\r\n}}}\r\n\r\nEven giving `x` its own explicitly polymorphic type signature -- what I thought was the standard way to prevent the monomorphism restriction from being a problem -- doesn't help. I'm uncertain what to make of that, but it certainly seems related: earlier versions of the compiler both do not give that error and do produce a crashing program, as I expected.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14783Initializing record with similarly named field from a different record result...2019-07-07T18:15:38ZulrikrasmussenInitializing record with similarly named field from a different record results in warning rather than errorWhen a record is initialized using a similarly named field from another record, the compiler ignores the initialization and generates a warning instead of throwing an error. I believe this is a bug introduced in GHC 8.0.1 (and probably r...When a record is initialized using a similarly named field from another record, the compiler ignores the initialization and generates a warning instead of throwing an error. I believe this is a bug introduced in GHC 8.0.1 (and probably related to `DuplicateRecordFields`), since earlier versions of GHC would refuse to compile the code.
Consider the following example:
```
-- A.hs
module A where
data A = A { a :: (), b :: () }
-- B.hs
module B where
data B = B { a :: (), b :: () }
-- Main.hs
module Main where
import A hiding (a)
import B
x = A { a = (), b = () }
main = case x of
A () () -> return ()
```
On GHC 8.0.1, this compiles (with a warning), and the program throws an exception when run:
```
$ stack ghc --compiler ghc-8.0.1 -- --make Main.hs
[1 of 3] Compiling B ( B.hs, B.o )
[2 of 3] Compiling A ( A.hs, A.o )
[3 of 3] Compiling Main ( Main.hs, Main.o )
Main.hs:5:7: warning: [-Wmissing-fields]
• Fields of ‘A’ not initialised: a
• In the expression: A {a = (), b = ()}
In an equation for ‘x’: x = A {a = (), b = ()}
Linking Main ...
$ ./Main
Main: Main.hs:5:7-26: Missing field in record construction a
```
On GHC 7.10.3, the program will not compile:
```
$ stack ghc --compiler ghc-7.10.3 -- --make Main.hs
[1 of 3] Compiling B ( B.hs, B.o )
[2 of 3] Compiling A ( A.hs, A.o )
[3 of 3] Compiling Main ( Main.hs, Main.o )
Main.hs:5:7:
Constructor ‘A’ does not have field ‘a’
In the expression: A {a = (), b = ()}
In an equation for ‘x’: x = A {a = (), b = ()}
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Initializing record with similarly named field from a different record results in warning rather than error","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":["DuplicateRecordFields","records"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When a record is initialized using a similarly named field from another record, the compiler ignores the initialization and generates a warning instead of throwing an error. I believe this is a bug introduced in GHC 8.0.1 (and probably related to `DuplicateRecordFields`), since earlier versions of GHC would refuse to compile the code.\r\n\r\nConsider the following example:\r\n\r\n{{{\r\n-- A.hs\r\nmodule A where\r\n data A = A { a :: (), b :: () }\r\n\r\n-- B.hs\r\nmodule B where\r\n data B = B { a :: (), b :: () }\r\n\r\n-- Main.hs\r\nmodule Main where\r\n import A hiding (a)\r\n import B\r\n\r\n x = A { a = (), b = () }\r\n\r\n main = case x of\r\n A () () -> return ()\r\n}}}\r\n\r\nOn GHC 8.0.1, this compiles (with a warning), and the program throws an exception when run:\r\n\r\n{{{\r\n$ stack ghc --compiler ghc-8.0.1 -- --make Main.hs\r\n[1 of 3] Compiling B ( B.hs, B.o )\r\n[2 of 3] Compiling A ( A.hs, A.o )\r\n[3 of 3] Compiling Main ( Main.hs, Main.o )\r\n\r\nMain.hs:5:7: warning: [-Wmissing-fields]\r\n • Fields of ‘A’ not initialised: a\r\n • In the expression: A {a = (), b = ()}\r\n In an equation for ‘x’: x = A {a = (), b = ()}\r\nLinking Main ...\r\n\r\n$ ./Main \r\nMain: Main.hs:5:7-26: Missing field in record construction a\r\n}}}\r\n\r\nOn GHC 7.10.3, the program will not compile:\r\n{{{\r\n$ stack ghc --compiler ghc-7.10.3 -- --make Main.hs\r\n[1 of 3] Compiling B ( B.hs, B.o )\r\n[2 of 3] Compiling A ( A.hs, A.o )\r\n[3 of 3] Compiling Main ( Main.hs, Main.o )\r\n\r\nMain.hs:5:7:\r\n Constructor ‘A’ does not have field ‘a’\r\n In the expression: A {a = (), b = ()}\r\n In an equation for ‘x’: x = A {a = (), b = ()}\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.2.3https://gitlab.haskell.org/ghc/ghc/-/issues/14784RTS header files can't be used with a C++ compiler2021-08-03T19:21:09ZniteriaRTS header files can't be used with a C++ compilerIf you compile `m1.cpp`:
```
#include "Rts.h"
int main(int argc, char** argv) {
}
```
with:
```
g++ -g m1.cpp -std=c++11 -I includes/ -c
```
you get:
```
In file included from includes/Rts.h:29:0,
from m1.cpp:1:
inc...If you compile `m1.cpp`:
```
#include "Rts.h"
int main(int argc, char** argv) {
}
```
with:
```
g++ -g m1.cpp -std=c++11 -I includes/ -c
```
you get:
```
In file included from includes/Rts.h:29:0,
from m1.cpp:1:
includes/Stg.h:29:3: error: #error __STDC_VERSION__ does not advertise C99 or later
# error __STDC_VERSION__ does not advertise C99 or later
^
```
It's not advertised anywhere that it should work, but it used to work.
https://phabricator.haskell.org/D2045 is what introduced this check.
Judging by https://stackoverflow.com/questions/48045243/ghc-gcc-compiler-issue-stdc-version-w-c99-from-stg-h-fails-for-every-packa, it affects GHC 8.2 and later.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | hvr, simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"RTS header files can't be used with a C++ compiler","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["hvr","simonmar"],"type":"Bug","description":"If you compile `m1.cpp`:\r\n\r\n{{{\r\n#include \"Rts.h\"\r\nint main(int argc, char** argv) {\r\n}\r\n}}}\r\n\r\nwith:\r\n{{{\r\ng++ -g m1.cpp -std=c++11 -I includes/ -c\r\n}}}\r\n\r\nyou get:\r\n\r\n{{{\r\nIn file included from includes/Rts.h:29:0,\r\n from m1.cpp:1:\r\nincludes/Stg.h:29:3: error: #error __STDC_VERSION__ does not advertise C99 or later\r\n # error __STDC_VERSION__ does not advertise C99 or later\r\n ^\r\n}}}\r\n\r\nIt's not advertised anywhere that it should work, but it used to work. \r\nhttps://phabricator.haskell.org/D2045 is what introduced this check.\r\n\r\nJudging by https://stackoverflow.com/questions/48045243/ghc-gcc-compiler-issue-stdc-version-w-c99-from-stg-h-fails-for-every-packa, it affects GHC 8.2 and later.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Herbert Valerio Riedelhvr@gnu.orgHerbert Valerio Riedelhvr@gnu.orghttps://gitlab.haskell.org/ghc/ghc/-/issues/14785accumArray is too lazy2022-12-14T17:20:56ZDavid FeueraccumArray is too lazyAccording to the documentation,
```hs
-- If the accumulating function is strict, then 'accumArray' is strict in
-- the values, as well as the indices, in the association list. Thus,
-- unlike ordinary arrays built with 'array', accumul...According to the documentation,
```hs
-- If the accumulating function is strict, then 'accumArray' is strict in
-- the values, as well as the indices, in the association list. Thus,
-- unlike ordinary arrays built with 'array', accumulated arrays should
-- not in general be recursive.
```
I believe that strictness is desirable, because it prevents thunks from accumulating when we use the passed function. But the strictness isn't actually there! We never force the result of the function.
I believe we should fix the code (and documentation) to maintain the invariant that all elements in the result of `accumArray` are in WHNF.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Core Libraries |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"accumArray is too lazy","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"According to the documentation,\r\n\r\n{{{#!hs\r\n-- If the accumulating function is strict, then 'accumArray' is strict in\r\n-- the values, as well as the indices, in the association list. Thus,\r\n-- unlike ordinary arrays built with 'array', accumulated arrays should\r\n-- not in general be recursive.\r\n}}}\r\n\r\nI believe that strictness is desirable, because it prevents thunks from accumulating when we use the passed function. But the strictness isn't actually there! We never force the result of the function.\r\n\r\nI believe we should fix the code (and documentation) to maintain the invariant that all elements in the result of `accumArray` are in WHNF.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/14786Compile-time panic with kind-level application in type famiy decl2019-07-07T18:15:36ZlyxiaCompile-time panic with kind-level application in type famiy declMinimal example:
```
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE TypeInType #-}
type family E e (a :: k) (orn :: e a) :: ()
```
Error message:
```
ghc: panic! (the 'impossible' happened)
(GHC version 8.2.2 for x86_64-unknown-linux):...Minimal example:
```
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE TypeInType #-}
type family E e (a :: k) (orn :: e a) :: ()
```
Error message:
```
ghc: panic! (the 'impossible' happened)
(GHC version 8.2.2 for x86_64-unknown-linux):
getRuntimeRep
k_anW[sk:1] :: k0_aRs[tau:1]
Call stack:
CallStack (from HasCallStack):
prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable
callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable
pprPanic, called at compiler/types/Type.hs:1967:18 in ghc:Type
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.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":"Compile-time panic with kind-level application in type famiy decl","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Minimal example:\r\n\r\n{{{\r\n{-# LANGUAGE TypeFamilies #-}\r\n{-# LANGUAGE TypeInType #-}\r\n\r\ntype family E e (a :: k) (orn :: e a) :: ()\r\n}}}\r\n\r\nError message:\r\n\r\n{{{\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.2.2 for x86_64-unknown-linux):\r\n\tgetRuntimeRep\r\n k_anW[sk:1] :: k0_aRs[tau:1]\r\n Call stack:\r\n CallStack (from HasCallStack):\r\n prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable\r\n callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable\r\n pprPanic, called at compiler/types/Type.hs:1967:18 in ghc:Type\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14787Remove StgLint type checks2019-07-07T18:15:35ZÖmer Sinan AğacanRemove StgLint type checksCopying from the mailing list thread:
----
https://mail.haskell.org/pipermail/ghc-devs/2018-February/015371.html
I've been looking into some StgLint-related tickets:
- #13994: Found a StgLint problem and fixed, there's another proble...Copying from the mailing list thread:
----
https://mail.haskell.org/pipermail/ghc-devs/2018-February/015371.html
I've been looking into some StgLint-related tickets:
- #13994: Found a StgLint problem and fixed, there's another problem
waiting to be fixed. Both related with the fact that after
unarisation we lose even more typing information and type
> checks needs to be relaxed.
- #14116: StgLint failed to look through newtypes, and because coercions
are removed at that point it failed to type check. Solution
> was to relax type checks.
- #5345: Because `unsafeCoerce# is operationally no-op, and we don't
have coercions in STG, StgLint can't type check at all. The
commit message notes:
> Fundamentally STG Lint is impossible, because unsafeCoerce#
> can randomise all the types.
> This patch does a bit of fiddle faddling in StgLint which
> makes it a bit better, but it's a losing battle.
- #14117: Related with StgLint not keeping up with recent changes (join
points), because it's not enabled by default in
tests/validate.
- #14118: Related with the fact that pre- and post-unarise we have
different invariants in STG. Solution was to add a "unarise"
parameter and do different checks based on that.
- #14120: Again type checking errors. Commit for #14116 also fixes this.
The commits compares `typePrimRep`s of types instead of
comparing actual types (even this is not enough, see #13994).
All this of course took time to debug.
In addition, the new `StgCSE` pass makes transformations that trigger
case alternative checks (and probably some other checks) because
scrutinee and result won't have same types after the transformation
described in `Note \[Case 2: CSEing case binders\]\`.
There's also this comment in StgLint.hs
WARNING:
> \~\~\~\~\~\~\~\~
This module has suffered bit-rot; it is likely to yield lint errors
for Stg code that is currently perfectly acceptable for code
> generation. Solution: don't use it! (KSW 2000-05).
It seems like it hasn't been used since 2000.
All this suggests that
- Checks related to types are impossible in StgLint. (see e.g. commit
> messages in #5345, #1420, transformations done by unariser and
> StgCSE)
- It's not enabled since 2000, which I think means that it's not
> needed.
This makes me question whether it's worth maintaining. Maybe we should
just remove it.
If we still want to keep we should decide on what it's supposed to do.
Only invariants I can think of are:
- After unarise there should be no unboxed tuple and sum binders.
> unarise is a simple pass and does same thing to all binders, there are
> no tricky cases so I'm not sure if we need to check this.
- Variables should be defined before use. I again don't know if this
> should be checked, could this be useful for StgCSE?
So I think we should do one of these:
1. Remove StgLint.
1. Rewrite it to only check these two and nothing else, enable it in
validate (and in other build flavours that enable CoreLint).
What do you think? If you think we should keep StgLint, can you think of
any other checks? If we could reach a consensus I'm hoping to update
StgLint (or remove it).
----
Simon suggested creating a ticket and keeping StgLint. This is the tracking ticket.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Remove StgLint type checks","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"Copying from the mailing list thread: \r\n\r\n----\r\n\r\nhttps://mail.haskell.org/pipermail/ghc-devs/2018-February/015371.html\r\n\r\nI've been looking into some StgLint-related tickets:\r\n\r\n- #13994: Found a StgLint problem and fixed, there's another problem\r\n waiting to be fixed. Both related with the fact that after\r\n unarisation we lose even more typing information and type\r\n checks needs to be relaxed.\r\n\r\n- #14116: StgLint failed to look through newtypes, and because coercions\r\n are removed at that point it failed to type check. Solution\r\n was to relax type checks.\r\n\r\n- #5345: Because `unsafeCoerce# is operationally no-op, and we don't\r\n have coercions in STG, StgLint can't type check at all. The\r\n commit message notes:\r\n\r\n > Fundamentally STG Lint is impossible, because unsafeCoerce#\r\n > can randomise all the types.\r\n\r\n > This patch does a bit of fiddle faddling in StgLint which\r\n > makes it a bit better, but it's a losing battle.\r\n\r\n- #14117: Related with StgLint not keeping up with recent changes (join\r\n points), because it's not enabled by default in\r\n tests/validate.\r\n\r\n- #14118: Related with the fact that pre- and post-unarise we have\r\n different invariants in STG. Solution was to add a \"unarise\"\r\n parameter and do different checks based on that.\r\n\r\n- #14120: Again type checking errors. Commit for #14116 also fixes this.\r\n The commits compares `typePrimRep`s of types instead of\r\n comparing actual types (even this is not enough, see #13994).\r\n\r\nAll this of course took time to debug.\r\n\r\nIn addition, the new `StgCSE` pass makes transformations that trigger\r\ncase alternative checks (and probably some other checks) because\r\nscrutinee and result won't have same types after the transformation\r\ndescribed in `Note [Case 2: CSEing case binders]`.\r\n\r\nThere's also this comment in StgLint.hs\r\n\r\n WARNING:\r\n ~~~~~~~~\r\n\r\n This module has suffered bit-rot; it is likely to yield lint errors\r\n for Stg code that is currently perfectly acceptable for code\r\n generation. Solution: don't use it! (KSW 2000-05).\r\n\r\nIt seems like it hasn't been used since 2000.\r\n\r\nAll this suggests that\r\n\r\n- Checks related to types are impossible in StgLint. (see e.g. commit\r\n messages in #5345, #1420, transformations done by unariser and\r\n StgCSE)\r\n\r\n- It's not enabled since 2000, which I think means that it's not\r\n needed.\r\n\r\nThis makes me question whether it's worth maintaining. Maybe we should\r\njust remove it.\r\n\r\nIf we still want to keep we should decide on what it's supposed to do.\r\nOnly invariants I can think of are:\r\n\r\n- After unarise there should be no unboxed tuple and sum binders.\r\n\r\n unarise is a simple pass and does same thing to all binders, there are\r\n no tricky cases so I'm not sure if we need to check this.\r\n\r\n- Variables should be defined before use. I again don't know if this\r\n should be checked, could this be useful for StgCSE?\r\n\r\nSo I think we should do one of these:\r\n\r\n1. Remove StgLint.\r\n\r\n2. Rewrite it to only check these two and nothing else, enable it in\r\n validate (and in other build flavours that enable CoreLint).\r\n\r\nWhat do you think? If you think we should keep StgLint, can you think of\r\nany other checks? If we could reach a consensus I'm hoping to update\r\nStgLint (or remove it).\r\n\r\n----\r\n\r\nSimon suggested creating a ticket and keeping StgLint. This is the tracking ticket.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/14788`error` in GHC internals can disappear by rerunning ghc again2019-07-07T18:15:35ZNiklas Hambüchenmail@nh2.me`error` in GHC internals can disappear by rerunning ghc againI was messing around with GHC's source code and thus triggered a bug, manifesting in my case as the `pprPanic "applyTypeToArgs" panic_msg` in `applyTypeToArgs` in GHC 8.2.1.
Expectedly, ghc died with `the 'impossible' happened` while co...I was messing around with GHC's source code and thus triggered a bug, manifesting in my case as the `pprPanic "applyTypeToArgs" panic_msg` in `applyTypeToArgs` in GHC 8.2.1.
Expectedly, ghc died with `the 'impossible' happened` while compiling a package (in my case `vector`).
With output like this (it's not important to read the output in detail, only to see the `.o` file involved):
```
[17 of 21] Compiling Data.Vector.Storable.Mutable ( Data/Vector/Storable/Mutable.hs, .stack-work/dist/x86_64-linux/Cabal-2.0.0.2/build/Data/Vector/Storable/Mutable.o )
Data/Vector/Storable/Mutable.hs:77:1: warning: [-Wunused-imports]
The import of ‘Foreign.Ptr’ is redundant
except perhaps to import instances from ‘Foreign.Ptr’
To import instances alone, use: import Foreign.Ptr()
|
77 | import Foreign.Ptr
| ^^^^^^^^^^^^^^^^^^
ghc: panic! (the 'impossible' happened)
(GHC version 8.2.1 for x86_64-unknown-linux):
applyTypeToArgs
Expression: n#_aKi p_a3X ds5_XM4 ds7_aKj x#_aKa eta_X1H
Type: Int#
Args: [p_a3X, ds5_XM4, ds7_aKj, x#_aKa, eta_X1H]
Call stack:
CallStack (from HasCallStack):
prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable
callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable
pprPanic, called at compiler/coreSyn/CoreUtils.hs:226:14 in ghc:CoreUtils
```
What I did not expect was that by rerunning my `ghc --make` invocation again, the error would disappear!
This is because after the error, the `.o` file is corrupt, just cut off in the middle.
The reason is probably that GHC writes the `.o` file contents from an expression that can contain `error` thunks deep in, so the error only surfaces in the middle of the writing.
As a result, the `.o` file is touched and `ghc --make` build pipeline, when resumnig the build next time, thinks that the `.o` file was completed all fine.
I think `ghc --make` should not write the `.o` file when there's an obvious error.
I suggest that ghc either `deepseq` the string to be written to the `.o` file before calling `writeFile` or equivalent, or write the file to an `.o.tmp` file and rename the temp file upon completion. The latter approach would also help against corrupted files due to power loss, see #14533.
Fixing this would make developing GHC easier, as right now you can accidentally continue from a completely broken state (corrupt `.o` file) and only notice the error much later and then have to backtrack.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | nh2 |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"`error` in GHC internals can disappear by rerunning ghc again","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["nh2"],"type":"Bug","description":"I was messing around with GHC's source code and thus triggered a bug, manifesting in my case as the `pprPanic \"applyTypeToArgs\" panic_msg` in `applyTypeToArgs` in GHC 8.2.1.\r\n\r\nExpectedly, ghc died with `the 'impossible' happened` while compiling a package (in my case `vector`).\r\n\r\nWith output like this (it's not important to read the output in detail, only to see the `.o` file involved):\r\n\r\n{{{\r\n[17 of 21] Compiling Data.Vector.Storable.Mutable ( Data/Vector/Storable/Mutable.hs, .stack-work/dist/x86_64-linux/Cabal-2.0.0.2/build/Data/Vector/Storable/Mutable.o )\r\n\r\nData/Vector/Storable/Mutable.hs:77:1: warning: [-Wunused-imports]\r\n The import of ‘Foreign.Ptr’ is redundant\r\n except perhaps to import instances from ‘Foreign.Ptr’\r\n To import instances alone, use: import Foreign.Ptr()\r\n |\r\n77 | import Foreign.Ptr\r\n | ^^^^^^^^^^^^^^^^^^\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.2.1 for x86_64-unknown-linux):\r\n\tapplyTypeToArgs\r\n Expression: n#_aKi p_a3X ds5_XM4 ds7_aKj x#_aKa eta_X1H\r\n Type: Int#\r\n Args: [p_a3X, ds5_XM4, ds7_aKj, x#_aKa, eta_X1H]\r\n Call stack:\r\n CallStack (from HasCallStack):\r\n prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable\r\n callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable\r\n pprPanic, called at compiler/coreSyn/CoreUtils.hs:226:14 in ghc:CoreUtils\r\n}}}\r\n\r\nWhat I did not expect was that by rerunning my `ghc --make` invocation again, the error would disappear!\r\n\r\nThis is because after the error, the `.o` file is corrupt, just cut off in the middle.\r\n\r\nThe reason is probably that GHC writes the `.o` file contents from an expression that can contain `error` thunks deep in, so the error only surfaces in the middle of the writing.\r\n\r\nAs a result, the `.o` file is touched and `ghc --make` build pipeline, when resumnig the build next time, thinks that the `.o` file was completed all fine.\r\n\r\nI think `ghc --make` should not write the `.o` file when there's an obvious error.\r\n\r\nI suggest that ghc either `deepseq` the string to be written to the `.o` file before calling `writeFile` or equivalent, or write the file to an `.o.tmp` file and rename the temp file upon completion. The latter approach would also help against corrupted files due to power loss, see #14533.\r\n\r\nFixing this would make developing GHC easier, as right now you can accidentally continue from a completely broken state (corrupt `.o` file) and only notice the error much later and then have to backtrack.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14789GHCi fails to garbage collect declaration `l = length [1..10^8]` entered at p...2021-09-16T10:04:36ZKevinBuhrGHCi fails to garbage collect declaration `l = length [1..10^8]` entered at promptThis was recently reported on Stack Overflow (https://stackoverflow.com/questions/48723119/binding-len-length-xs-and-then-calculating-len-causes-ghc-to-consume-lots).
With GHC 8.2.2, assigning the length of a large list as a top-level d...This was recently reported on Stack Overflow (https://stackoverflow.com/questions/48723119/binding-len-length-xs-and-then-calculating-len-causes-ghc-to-consume-lots).
With GHC 8.2.2, assigning the length of a large list as a top-level declaration at the GHCi prompt and evaluating it:
```
Prelude> l = length [1..10^8]
Prelude> l
10000000
Prelude>
```
allocates about 7 gigs of memory before displaying a result, and then memory continues to grow over the next few seconds (at the idle GHCi prompt) until 10 gigs of memory has been allocated. None of it is freed until the interpreter session ends.
In contrast, directly evaluating the expression or assigning it with a let-statement does \*\*not\*\* exhibit this behavior:
```
Prelude> length [1..10^8]
10000000
Prelude> let l = length [1..10^8]
Prelude> l
10000000
Prelude>
```
Also, loading the top-level declaration from a file and then evaluating it at the prompt does \*\*not\*\* exhibit the problem.
I took a look at Ticket [14336](ticket:) and applied the `-fno-it` patch referenced there. This slightly changed the pattern of memory usage: it grew to about 4 gigs before displaying the result, but then continued to grow for several seconds at the GHCi prompt before landing at about 10 gigs.
I verified that the bug still exists on the current "master" branch (though I didn't check the "ghc-8.4" branch).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHCi fails to garbage collect declaration `l = length [1..10^8]` entered at prompt","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This was recently reported on Stack Overflow (https://stackoverflow.com/questions/48723119/binding-len-length-xs-and-then-calculating-len-causes-ghc-to-consume-lots).\r\n\r\nWith GHC 8.2.2, assigning the length of a large list as a top-level declaration at the GHCi prompt and evaluating it:\r\n\r\n{{{\r\nPrelude> l = length [1..10^8]\r\nPrelude> l\r\n10000000\r\nPrelude>\r\n}}}\r\n\r\nallocates about 7 gigs of memory before displaying a result, and then memory continues to grow over the next few seconds (at the idle GHCi prompt) until 10 gigs of memory has been allocated. None of it is freed until the interpreter session ends.\r\n\r\nIn contrast, directly evaluating the expression or assigning it with a let-statement does **not** exhibit this behavior:\r\n\r\n{{{\r\nPrelude> length [1..10^8]\r\n10000000\r\nPrelude> let l = length [1..10^8]\r\nPrelude> l\r\n10000000\r\nPrelude>\r\n}}}\r\n\r\nAlso, loading the top-level declaration from a file and then evaluating it at the prompt does **not** exhibit the problem.\r\n\r\nI took a look at Ticket [ticket: 14336] and applied the `-fno-it` patch referenced there. This slightly changed the pattern of memory usage: it grew to about 4 gigs before displaying the result, but then continued to grow for several seconds at the GHCi prompt before landing at about 10 gigs.\r\n\r\nI verified that the bug still exists on the current \"master\" branch (though I didn't check the \"ghc-8.4\" branch).","type_of_failure":"OtherFailure","blocking":[]} -->9.2.1ZubinZubinhttps://gitlab.haskell.org/ghc/ghc/-/issues/14790eqTypeRep does not inline2019-07-07T18:15:34ZDavid FeuereqTypeRep does not inlineGHC never seems to inline `eqTypeRep`. That's no good! It produces a `Maybe`, which users will almost certainly want to match on immediately.
I really don't understand *why* it doesn't inline. It's a tiny function, none of the functions...GHC never seems to inline `eqTypeRep`. That's no good! It produces a `Maybe`, which users will almost certainly want to match on immediately.
I really don't understand *why* it doesn't inline. It's a tiny function, none of the functions it calls are themselves marked `INLINE`, and the advantage to inlining seems obvious. Does the `unsafeCoerce` get in the way somehow? If so, how can we fix it?
Example:
```hs
{-# language GADTs, ScopedTypeVariables, TypeApplications,
AllowAmbiguousTypes #-}
module Foo where
import Type.Reflection
foo :: forall a. Typeable a => Bool
foo = case eqTypeRep (typeRep @a) (typeRep @Int) of
Just _ -> True
Nothing -> False
```
compiles (with `-O2`) to
```
foo [InlPrag=NOINLINE] :: forall a. Typeable a => Bool
[GblId, Arity=1, Str=<S,1*U>]
foo
= \ (@ a_a5un) ($dTypeable_a5up :: Typeable a_a5un) ->
case eqTypeRep
@ *
@ *
@ a_a5un
@ Int
($dTypeable_a5up
`cast` (base-4.10.1.0:Data.Typeable.Internal.N:Typeable[0] <*>_N <a_a5un>_N
:: (Typeable a_a5un :: Constraint) ~R# (TypeRep a_a5un :: *)))
lvl4_r69g
of {
Nothing -> GHC.Types.False;
Just ds_d5CQ -> GHC.Types.True
}
```
For reference, `eqTypeRep` is defined like this:
```hs
eqTypeRep :: forall k1 k2 (a :: k1) (b :: k2).
TypeRep a -> TypeRep b -> Maybe (a :~~: b)
eqTypeRep a b
| typeRepFingerprint a == typeRepFingerprint b = Just (unsafeCoerce HRefl)
| otherwise = Nothing
```8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/14791Move stack checks out of code paths that don't use the stack.2023-10-13T15:05:47ZAndreas KlebingerMove stack checks out of code paths that don't use the stack.Given the simple function:
```
func :: Int -> Int
func 11 = 11111
func 41 = 4444
```
We produce this cmm code:
```
[section ""data" . T.func_closure" {
T.func_closure:
const T.func_info;
const 0;
},
T.func_ent...Given the simple function:
```
func :: Int -> Int
func 11 = 11111
func 41 = 4444
```
We produce this cmm code:
```
[section ""data" . T.func_closure" {
T.func_closure:
const T.func_info;
const 0;
},
T.func_entry() // [R2]
{ info_tbl: [(c2lk,
label: block_c2lk_info
rep:StackRep []),
(c2ln,
label: T.func_info
rep:HeapRep static { Fun {arity: 1 fun_type: ArgSpec 5} })]
stack_info: arg_space: 8 updfr_space: Just 8
}
{offset
c2ln: // global
if ((Sp + -8) < SpLim) (likely: False) goto c2lo; else goto c2lp;
c2lo: // global
R2 = R2;
R1 = T.func_closure;
call (stg_gc_fun)(R2, R1) args: 8, res: 0, upd: 8;
c2lp: // global
I64[Sp - 8] = c2lk;
R1 = R2;
Sp = Sp - 8;
if (R1 & 7 != 0) goto c2lk; else goto c2ll;
c2ll: // global
call (I64[R1])(R1) returns to c2lk, args: 8, res: 8, upd: 8;
c2lk: // global
_s2kY::I64 = I64[R1 + 7];
if (_s2kY::I64 != 11) goto u2ly; else goto c2lw;
u2ly: // global
if (_s2kY::I64 == 41) (likely: False) goto c2lx; else goto c2lv;
c2lx: // global
R1 = T.func1_closure+1;
Sp = Sp + 8;
call (P64[Sp])(R1) args: 8, res: 0, upd: 8;
c2lv: // global
R1 = T.func3_closure;
Sp = Sp + 8;
call (I64[R1])(R1) args: 8, res: 0, upd: 8;
c2lw: // global
R1 = T.func2_closure+1;
Sp = Sp + 8;
call (P64[Sp])(R1) args: 8, res: 0, upd: 8;
}
}]
```
However the code path if the argument is already evaluated never uses the stack:
```
T.func_entry() // [R2]
{ info_tbl: [(c2lk,
label: block_c2lk_info
rep:StackRep []),
(c2ln,
label: T.func_info
rep:HeapRep static { Fun {arity: 1 fun_type: ArgSpec 5} })]
stack_info: arg_space: 8 updfr_space: Just 8
}
{offset
c2ln: // global
if ((Sp + -8) < SpLim) (likely: False) goto c2lo; else goto c2lp;
c2lp: // global
I64[Sp - 8] = c2lk;
R1 = R2;
Sp = Sp - 8;
if (R1 & 7 != 0) goto c2lk; else goto <..>;
c2lk: // global
_s2kY::I64 = I64[R1 + 7];
if (_s2kY::I64 != 11) goto u2ly; else goto c2lw;
u2ly: // global
if (_s2kY::I64 == 41) (likely: False) goto c2lx; else goto c2lv;
c2lx: // global
R1 = T.func1_closure+1;
Sp = Sp + 8;
call (P64[Sp])(R1) args: 8, res: 0, upd: 8;
c2lv: // global
R1 = T.func3_closure;
Sp = Sp + 8;
call (I64[R1])(R1) args: 8, res: 0, upd: 8;
c2lw: // global
R1 = T.func2_closure+1;
Sp = Sp + 8;
call (P64[Sp])(R1) args: 8, res: 0, upd: 8;
}
}]
```
This means if we have a tagged argument we
- Perform a stack check
- Decrement the stack
- Move the continuation onto the stack.
- Increment the stack
Without any of it being necessary.
If I'm not mistaken all of that could be done after we know we need to evaluate the argument.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.2 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Move stack checks out of code paths that don't use the stack.","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"Given the simple function:\r\n\r\n\r\n{{{\r\nfunc :: Int -> Int\r\nfunc 11 = 11111\r\nfunc 41 = 4444\r\n}}}\r\n\r\nWe produce this cmm code:\r\n\r\n{{{\r\n[section \"\"data\" . T.func_closure\" {\r\n T.func_closure:\r\n const T.func_info;\r\n const 0;\r\n },\r\n T.func_entry() // [R2]\r\n { info_tbl: [(c2lk,\r\n label: block_c2lk_info\r\n rep:StackRep []),\r\n (c2ln,\r\n label: T.func_info\r\n rep:HeapRep static { Fun {arity: 1 fun_type: ArgSpec 5} })]\r\n stack_info: arg_space: 8 updfr_space: Just 8\r\n }\r\n {offset\r\n c2ln: // global\r\n if ((Sp + -8) < SpLim) (likely: False) goto c2lo; else goto c2lp;\r\n c2lo: // global\r\n R2 = R2;\r\n R1 = T.func_closure;\r\n call (stg_gc_fun)(R2, R1) args: 8, res: 0, upd: 8;\r\n c2lp: // global\r\n I64[Sp - 8] = c2lk;\r\n R1 = R2;\r\n Sp = Sp - 8;\r\n if (R1 & 7 != 0) goto c2lk; else goto c2ll;\r\n c2ll: // global\r\n call (I64[R1])(R1) returns to c2lk, args: 8, res: 8, upd: 8;\r\n c2lk: // global\r\n _s2kY::I64 = I64[R1 + 7];\r\n if (_s2kY::I64 != 11) goto u2ly; else goto c2lw;\r\n u2ly: // global\r\n if (_s2kY::I64 == 41) (likely: False) goto c2lx; else goto c2lv;\r\n c2lx: // global\r\n R1 = T.func1_closure+1;\r\n Sp = Sp + 8;\r\n call (P64[Sp])(R1) args: 8, res: 0, upd: 8;\r\n c2lv: // global\r\n R1 = T.func3_closure;\r\n Sp = Sp + 8;\r\n call (I64[R1])(R1) args: 8, res: 0, upd: 8;\r\n c2lw: // global\r\n R1 = T.func2_closure+1;\r\n Sp = Sp + 8;\r\n call (P64[Sp])(R1) args: 8, res: 0, upd: 8;\r\n }\r\n }]\r\n}}}\r\n\r\n\r\nHowever the code path if the argument is already evaluated never uses the stack:\r\n\r\n{{{\r\n T.func_entry() // [R2]\r\n { info_tbl: [(c2lk,\r\n label: block_c2lk_info\r\n rep:StackRep []),\r\n (c2ln,\r\n label: T.func_info\r\n rep:HeapRep static { Fun {arity: 1 fun_type: ArgSpec 5} })]\r\n stack_info: arg_space: 8 updfr_space: Just 8\r\n }\r\n {offset\r\n c2ln: // global\r\n if ((Sp + -8) < SpLim) (likely: False) goto c2lo; else goto c2lp;\r\n c2lp: // global\r\n I64[Sp - 8] = c2lk;\r\n R1 = R2;\r\n Sp = Sp - 8;\r\n if (R1 & 7 != 0) goto c2lk; else goto <..>;\r\n c2lk: // global\r\n _s2kY::I64 = I64[R1 + 7];\r\n if (_s2kY::I64 != 11) goto u2ly; else goto c2lw;\r\n u2ly: // global\r\n if (_s2kY::I64 == 41) (likely: False) goto c2lx; else goto c2lv;\r\n c2lx: // global\r\n R1 = T.func1_closure+1;\r\n Sp = Sp + 8;\r\n call (P64[Sp])(R1) args: 8, res: 0, upd: 8;\r\n c2lv: // global\r\n R1 = T.func3_closure;\r\n Sp = Sp + 8;\r\n call (I64[R1])(R1) args: 8, res: 0, upd: 8;\r\n c2lw: // global\r\n R1 = T.func2_closure+1;\r\n Sp = Sp + 8;\r\n call (P64[Sp])(R1) args: 8, res: 0, upd: 8;\r\n }\r\n }]\r\n}}}\r\n\r\nThis means if we have a tagged argument we\r\n* Perform a stack check\r\n* Decrement the stack\r\n* Move the continuation onto the stack.\r\n* Increment the stack\r\n\r\nWithout any of it being necessary.\r\n\r\nIf I'm not mistaken all of that could be done after we know we need to evaluate the argument.\r\n\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14792compiling cabal-1.24.2.0 requires almost 3 GB of memory2021-10-21T09:02:12Zbfrkcompiling cabal-1.24.2.0 requires almost 3 GB of memoryNot sure if this is really a bug, but I noticed that ghc-8.2.2 requires a whole lot more memory than ghc-7-10.3. This is how I found out about it:
```
ben@yuiitsu[1]:.../src/Cabal-1.24.2.0>ulimit -v 2600000
ben@yuiitsu[1]:.../src/Cabal-...Not sure if this is really a bug, but I noticed that ghc-8.2.2 requires a whole lot more memory than ghc-7-10.3. This is how I found out about it:
```
ben@yuiitsu[1]:.../src/Cabal-1.24.2.0>ulimit -v 2600000
ben@yuiitsu[1]:.../src/Cabal-1.24.2.0>cabal new-build
Resolving dependencies...
Build profile: -w ghc-8.2.2 -O1
In order, the following will be built (use -v for more details):
- Cabal-1.24.2.0 (lib) (first run)
Configuring library for Cabal-1.24.2.0..
Preprocessing library for Cabal-1.24.2.0..
Building library for Cabal-1.24.2.0..
[ 1 of 86] Compiling Distribution.Compat.Binary ( Distribution/Compat/Binary.hs, /home/ben/src/Cabal-1.24.2.0/dist-newstyle/build/x86_64-linux/ghc-8.2.2/Cabal-1.24.2.0/build/Distribution/Compat/Binary.o )
[...]
[30 of 86] Compiling Distribution.PackageDescription (
Distribution/PackageDescription.hs,
dist/build/Distribution/PackageDescription.o )
ghc: out of memory
cabal: Failed to build Cabal-1.24.2.0 (which is required by
darcs-2.13.0). The
build process terminated with exit code 251
```
It works when I ulimit -v 3000000.
I previously had the limit at 2200000 and it worked just fine with ghc-7.10.3. The reason i limit the memory available to ghc is to avoid my machine freezing up due to thrashing (I only have 4GB physical RAM).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.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":"compiling cabal-1.24.2.0 requires almost 3 GB of memory","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Not sure if this is really a bug, but I noticed that ghc-8.2.2 requires a whole lot more memory than ghc-7-10.3. This is how I found out about it:\r\n\r\n{{{\r\nben@yuiitsu[1]:.../src/Cabal-1.24.2.0>ulimit -v 2600000\r\nben@yuiitsu[1]:.../src/Cabal-1.24.2.0>cabal new-build\r\nResolving dependencies...\r\nBuild profile: -w ghc-8.2.2 -O1\r\nIn order, the following will be built (use -v for more details):\r\n - Cabal-1.24.2.0 (lib) (first run)\r\nConfiguring library for Cabal-1.24.2.0..\r\nPreprocessing library for Cabal-1.24.2.0..\r\nBuilding library for Cabal-1.24.2.0..\r\n[ 1 of 86] Compiling Distribution.Compat.Binary ( Distribution/Compat/Binary.hs, /home/ben/src/Cabal-1.24.2.0/dist-newstyle/build/x86_64-linux/ghc-8.2.2/Cabal-1.24.2.0/build/Distribution/Compat/Binary.o )\r\n[...]\r\n[30 of 86] Compiling Distribution.PackageDescription (\r\nDistribution/PackageDescription.hs,\r\ndist/build/Distribution/PackageDescription.o )\r\nghc: out of memory\r\ncabal: Failed to build Cabal-1.24.2.0 (which is required by\r\ndarcs-2.13.0). The\r\nbuild process terminated with exit code 251\r\n}}}\r\n\r\nIt works when I ulimit -v 3000000.\r\n\r\nI previously had the limit at 2200000 and it worked just fine with ghc-7.10.3. The reason i limit the memory available to ghc is to avoid my machine freezing up due to thrashing (I only have 4GB physical RAM).","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14793some executables in the binary distribution are not versioned2021-08-15T21:32:56Zdmwitsome executables in the binary distribution are not versionedGHC is generally quite careful to play nicely when you install multiple versions, in particular by putting a version number somewhere in the filepath for almost every installed file. Then a few top-level non-versioned symlinks are made t...GHC is generally quite careful to play nicely when you install multiple versions, in particular by putting a version number somewhere in the filepath for almost every installed file. Then a few top-level non-versioned symlinks are made to (versioned) executables. Consequently, build tools with enough knowledge of the GHC versioning infrastructure can select an older or newer GHC to build things with by ignoring the top-level symlinks and explicitly selecting the versioned executable names.
There are a few exceptions where this is not possible: hsc2hs, hp2ps, and hpc. These executables are \*overwritten\* on each installation, so it is not possible to select "the one that goes with the currently chosen compiler".
I'd like to request that these begin being installed with the same scheme as other GHC executables: with an appended dash and version number, together with a non-versioned symlink.
I don't know to what extent this matters for hp2ps and hpc; perhaps these change infrequently enough that it doesn't matter too much. But hsc2hs at least bakes some GHC version knowledge in; it has at least a default template that it \#include's that defines some C macros, and this template changes occasionally. There is a command-line option to specify a template filepath explicitly, but it would be nice if build tools could reliably choose a version of hsc2hs that has the right defaults, so that using the command-line flag is a special case for special circumstances.
(For some context: I have just finished hunting down an issue related to exactly this. I installed an older GHC to test that some code was backwards-compatible. All of a sudden, existing builds, still using the new compiler, started failing, because hsc2hs was now using an outdated template that did not define all the necessary macros.)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"some executables in the binary distribution are not versioned","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"GHC is generally quite careful to play nicely when you install multiple versions, in particular by putting a version number somewhere in the filepath for almost every installed file. Then a few top-level non-versioned symlinks are made to (versioned) executables. Consequently, build tools with enough knowledge of the GHC versioning infrastructure can select an older or newer GHC to build things with by ignoring the top-level symlinks and explicitly selecting the versioned executable names.\r\n\r\nThere are a few exceptions where this is not possible: hsc2hs, hp2ps, and hpc. These executables are *overwritten* on each installation, so it is not possible to select \"the one that goes with the currently chosen compiler\".\r\n\r\nI'd like to request that these begin being installed with the same scheme as other GHC executables: with an appended dash and version number, together with a non-versioned symlink.\r\n\r\nI don't know to what extent this matters for hp2ps and hpc; perhaps these change infrequently enough that it doesn't matter too much. But hsc2hs at least bakes some GHC version knowledge in; it has at least a default template that it #include's that defines some C macros, and this template changes occasionally. There is a command-line option to specify a template filepath explicitly, but it would be nice if build tools could reliably choose a version of hsc2hs that has the right defaults, so that using the command-line flag is a special case for special circumstances.\r\n\r\n(For some context: I have just finished hunting down an issue related to exactly this. I installed an older GHC to test that some code was backwards-compatible. All of a sudden, existing builds, still using the new compiler, started failing, because hsc2hs was now using an outdated template that did not define all the necessary macros.)","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14794-Weverything should not enable -Wmissing-exported-signatures2023-01-14T20:54:00ZMaxGabriel-Weverything should not enable -Wmissing-exported-signaturesThe `-Weverything` compiler flag enables every compiler warning. That includes `-Wmissing-exported-signatures`, which disables `-Wmissing-signatures` (With `-Wmissing-signatures`, every top-level binding without a signature generates a w...The `-Weverything` compiler flag enables every compiler warning. That includes `-Wmissing-exported-signatures`, which disables `-Wmissing-signatures` (With `-Wmissing-signatures`, every top-level binding without a signature generates a warning, with `-Wmissing-exported-signatures`, only exported bindings generate a warning).
While technically "every warning" includes `-Wmissing-exported-signatures`, I don't think this matches how people use `-Weverything`. At least personally I think of it as "`-Wall` isn't enough, give me the strictest possible warning settings", but actually `-Weverything` can have *fewer* warnings than `-Wall` because of `-Wmissing-exported-signatures`.
Example reproduction case:
```
-- Main.hs
{-# LANGUAGE Safe #-}
module Main (main) where
import Prelude (IO, putStrLn, show, ($))
import Foo (foo)
main :: IO ()
main = putStrLn $ show foo
```
```
-- Foo.hs
{-# LANGUAGE Safe #-}
module Foo (foo) where
import Prelude (Integer)
foo :: Integer
foo = bar
bar = (1 :: Integer)
```
Expected: when compiling with `-Weverything`, I get a superset of `-Wall`'s warnings. Actual:
Actual `-Wall`:
```
maximiliantagher@Maximilians-MacBook-Pro ~/D/C/H/ghc-warning> ghc -Wall Main.hs Foo.hs
[1 of 2] Compiling Foo ( Foo.hs, Foo.o )
Foo.hs:10:1: warning: [-Wmissing-signatures]
Top-level binding with no type signature: bar :: Integer
|
10 | bar = (1 :: Integer)
| ^^^
[2 of 2] Compiling Main ( Main.hs, Main.o )
Linking Main ...
```
Actual `-Weverything` (note: you should remove run `rm main.o main.hi main Foo.o Foo.hi` in between invocations of the ghc to avoid it using something pre-built):
```
maximiliantagher@Maximilians-MacBook-Pro ~/D/C/H/ghc-warning> ghc -Weverything Main.hs Foo.hs
[1 of 2] Compiling Foo ( Foo.hs, Foo.o )
<no location info>: warning: [-Wsafe]
‘Foo’ has been inferred as safe!
[2 of 2] Compiling Main ( Main.hs, Main.o )
<no location info>: warning: [-Wsafe]
‘Main’ has been inferred as safe!
Linking Main ...
```
(I'm not familiar enough with Safe Haskell to get those warnings to go away—I tried the SafeHaskell pragma but that didn't seem to work. In any case, unrelated to this issue)
I tested with these versions:
- GHC: The Glorious Glasgow Haskell Compilation System, version 8.2.1
- OS Version: Mac OS 10.13.3 (17D47) (High Sierra)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"-Weverything should not enable -Wmissing-exported-signatures","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The `-Weverything` compiler flag enables every compiler warning. That includes `-Wmissing-exported-signatures`, which disables `-Wmissing-signatures` (With `-Wmissing-signatures`, every top-level binding without a signature generates a warning, with `-Wmissing-exported-signatures`, only exported bindings generate a warning).\r\n\r\nWhile technically \"every warning\" includes `-Wmissing-exported-signatures`, I don't think this matches how people use `-Weverything`. At least personally I think of it as \"`-Wall` isn't enough, give me the strictest possible warning settings\", but actually `-Weverything` can have ''fewer'' warnings than `-Wall` because of `-Wmissing-exported-signatures`. \r\n\r\nExample reproduction case:\r\n\r\n{{{\r\n-- Main.hs\r\n{-# LANGUAGE Safe #-}\r\n\r\nmodule Main (main) where\r\n\r\nimport Prelude (IO, putStrLn, show, ($))\r\nimport Foo (foo)\r\n\r\nmain :: IO ()\r\nmain = putStrLn $ show foo\r\n\r\n}}}\r\n\r\n{{{\r\n-- Foo.hs\r\n{-# LANGUAGE Safe #-}\r\n\r\nmodule Foo (foo) where\r\n\r\nimport Prelude (Integer)\r\n\r\nfoo :: Integer\r\nfoo = bar\r\n\r\nbar = (1 :: Integer)\r\n}}}\r\n\r\nExpected: when compiling with `-Weverything`, I get a superset of `-Wall`'s warnings. Actual:\r\n\r\nActual `-Wall`:\r\n\r\n{{{\r\nmaximiliantagher@Maximilians-MacBook-Pro ~/D/C/H/ghc-warning> ghc -Wall Main.hs Foo.hs\r\n[1 of 2] Compiling Foo ( Foo.hs, Foo.o )\r\n\r\nFoo.hs:10:1: warning: [-Wmissing-signatures]\r\n Top-level binding with no type signature: bar :: Integer\r\n |\r\n10 | bar = (1 :: Integer)\r\n | ^^^\r\n[2 of 2] Compiling Main ( Main.hs, Main.o )\r\nLinking Main ...\r\n}}}\r\n\r\nActual `-Weverything` (note: you should remove run `rm main.o main.hi main Foo.o Foo.hi` in between invocations of the ghc to avoid it using something pre-built):\r\n\r\n{{{\r\nmaximiliantagher@Maximilians-MacBook-Pro ~/D/C/H/ghc-warning> ghc -Weverything Main.hs Foo.hs\r\n[1 of 2] Compiling Foo ( Foo.hs, Foo.o )\r\n\r\n<no location info>: warning: [-Wsafe]\r\n ‘Foo’ has been inferred as safe!\r\n[2 of 2] Compiling Main ( Main.hs, Main.o )\r\n\r\n<no location info>: warning: [-Wsafe]\r\n ‘Main’ has been inferred as safe!\r\nLinking Main ...\r\n}}}\r\n\r\n(I'm not familiar enough with Safe Haskell to get those warnings to go away—I tried the SafeHaskell pragma but that didn't seem to work. In any case, unrelated to this issue)\r\n\r\nI tested with these versions:\r\n\r\n* GHC: The Glorious Glasgow Haskell Compilation System, version 8.2.1\r\n* OS Version: Mac OS 10.13.3 (17D47) (High Sierra)","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14795Data type return kinds don't obey the forall-or-nothing rule2022-07-13T16:54:51ZRyan ScottData type return kinds don't obey the forall-or-nothing ruleOriginally noticed [here](https://github.com/ghc-proposals/ghc-proposals/pull/103#issuecomment-364562974). GHC accepts this:
```hs
{-# LANGUAGE GADTs #-}
{-# LANGUAGE RankNTypes #-}
{-# LANGUAGE TypeInType #-}
import Data.Kind
data Fo...Originally noticed [here](https://github.com/ghc-proposals/ghc-proposals/pull/103#issuecomment-364562974). GHC accepts this:
```hs
{-# LANGUAGE GADTs #-}
{-# LANGUAGE RankNTypes #-}
{-# LANGUAGE TypeInType #-}
import Data.Kind
data Foo :: forall a. a -> b -> Type where
MkFoo :: a -> Foo a b
```
Despite the fact that `Foo`'s return kind is headed by an explicit `forall` which does not quantify `b`.
The users' guide doesn't explicitly indicate that the `forall`-or-nothing rule should apply to data type return kinds, but goldfirere believes that not doing so is an [inconsistent design](https://github.com/ghc-proposals/ghc-proposals/pull/103#issuecomment-364670215), so I'm opening this ticket to track this.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Data type return kinds don't obey the forall-or-nothing rule","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":["TypeInType"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Originally noticed [https://github.com/ghc-proposals/ghc-proposals/pull/103#issuecomment-364562974 here]. GHC accepts this:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE GADTs #-}\r\n{-# LANGUAGE RankNTypes #-}\r\n{-# LANGUAGE TypeInType #-}\r\n\r\nimport Data.Kind\r\n\r\ndata Foo :: forall a. a -> b -> Type where\r\n MkFoo :: a -> Foo a b\r\n}}}\r\n\r\nDespite the fact that `Foo`'s return kind is headed by an explicit `forall` which does not quantify `b`.\r\n\r\nThe users' guide doesn't explicitly indicate that the `forall`-or-nothing rule should apply to data type return kinds, but goldfirere believes that not doing so is an [https://github.com/ghc-proposals/ghc-proposals/pull/103#issuecomment-364670215 inconsistent design], so I'm opening this ticket to track this.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14796Pretty Printing: GHC doesn't parenthesise (() :: Constraint)2019-07-07T18:15:32ZIcelandjackPretty Printing: GHC doesn't parenthesise (() :: Constraint)From Ryan's [How to derive Generic for (some) GADTs using QuantifiedConstraints](https://ryanglscott.github.io/2018/02/11/how-to-derive-generic-for-some-gadts/):
```hs
data ECC ctx f a where
ECC :: ctx => f a -> ECC ctx f a
```
When ...From Ryan's [How to derive Generic for (some) GADTs using QuantifiedConstraints](https://ryanglscott.github.io/2018/02/11/how-to-derive-generic-for-some-gadts/):
```hs
data ECC ctx f a where
ECC :: ctx => f a -> ECC ctx f a
```
When instantiating the `Constraint` using `-XTypeApplications` with the empty constraint, GHC doesn't add parentheses (it should look like `... -> ECC (() :: Constraint) [] ()`)
```
$ ~/code/qc-ghc/inplace/bin/ghc-stage2 --interactive -ignore-dot-ghci
GHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help
Prelude> :set -XGADTs -XConstraintKinds -XTypeApplications
Prelude> data ECC ctx f a where ECC :: ctx => f a -> ECC ctx f a
Prelude> :t ECC @[] @() @()
ECC @[] @() @() :: [()] -> ECC () :: Constraint [] ()
```
Doesn't seem to happen in other cases:
```
Prelude> :t ECC @[] @() @((), ())
ECC @[] @() @((), ())
:: [()] -> ECC (() :: Constraint, () :: Constraint) [] ()
Prelude> :t ECC @[] @() @(Eq Int)
ECC @[] @() @(Eq Int) :: [()] -> ECC (Eq Int) [] ()
```8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/14797High-residency modules during GHC build2019-07-07T18:15:32ZTobias Dammerstdammers@gmail.comHigh-residency modules during GHC buildWhile trying to figure out memory allocation failures on the CI server, I tracked allocations and residency on a per-module basis, and noticed that some modules require a lot more memory to compile than others.
I've compiled a digest of...While trying to figure out memory allocation failures on the CI server, I tracked allocations and residency on a per-module basis, and noticed that some modules require a lot more memory to compile than others.
I've compiled a digest of the most memory-hungry compilation steps:
```
"/usr/local/bin/ghc" ... compiler/stage1/build/OptCoercion.o: Max. residency: 991356584 / In use: 2094M
"inplace/bin/ghc-stage1" ... compiler/stage2/build/OptCoercion.dyn_o: Max. residency: 714940528 / In use: 1471M
"/usr/local/bin/ghc" ... compiler/stage1/build/X86/CodeGen.o: Max. residency: 679947656 / In use: 1497M
"inplace/bin/ghc-stage1" ... libraries/Cabal/Cabal/dist-install/build/Distribution/SPDX/LicenseId.dyn_o: Max. residency: 653177496 / In use: 1355M
"inplace/bin/ghc-stage1" ... compiler/stage2/build/X86/CodeGen.dyn_o: Max. residency: 641515344 / In use: 1425M
"/usr/local/bin/ghc" ... -ilibraries/parsec: Max. residency: 593335568 / In use: 1355M
"/usr/local/bin/ghc" ... libraries/Cabal/Cabal/dist-boot/build/Distribution/SPDX/LicenseId.o: Max. residency: 575034968 / In use: 1137M
"inplace/bin/ghc-stage1" ... compiler/stage2/build/DynFlags.dyn_o: Max. residency: 402734408 / In use: 1059M
"/usr/local/bin/ghc" ... compiler/stage1/build/DynFlags.o: Max. residency: 343154784 / In use: 892M
"inplace/bin/ghc-stage1" ... libraries/template-haskell/dist-install/build/Language/Haskell/TH/Syntax.dyn_o: Max. residency: 266744312 / In use: 720M
"/usr/local/bin/ghc" ... compiler/stage1/build/Parser.o: Max. residency: 258613584 / In use: 679M
"inplace/bin/ghc-stage1" ... compiler/stage2/build/CmmOpt.dyn_o: Max. residency: 254639624 / In use: 568M
"inplace/bin/ghc-stage1" ... compiler/stage2/build/Parser.dyn_o: Max. residency: 236774592 / In use: 635M
"inplace/bin/ghc-stage1" ... ghc/stage2/build/GHCi/UI.dyn_o: Max. residency: 234055792 / In use: 609M
"/usr/local/bin/ghc" ... compiler/stage1/build/HsExpr.o: Max. residency: 233724400 / In use: 657M
"/usr/local/bin/ghc" ... compiler/stage1/build/CmmOpt.o: Max. residency: 208378888 / In use: 436M
"/usr/local/bin/ghc" ... compiler/stage1/build/HscMain.o: Max. residency: 197177248 / In use: 500M
"inplace/bin/ghc-stage1" ... compiler/stage2/build/HsExpr.dyn_o: Max. residency: 192780496 / In use: 521M
"inplace/bin/ghc-stage1" ... libraries/Cabal/Cabal/dist-install/build/Distribution/Simple/Setup.dyn_o: Max. residency: 191649952 / In use: 521M
"/usr/local/bin/ghc" ... compiler/stage1/build/HsDecls.o: Max. residency: 183441120 / In use: 508M
"inplace/bin/ghc-stage1" ... compiler/stage2/build/TcSplice.dyn_o: Max. residency: 176802000 / In use: 445M
"inplace/bin/ghc-stage1" ... compiler/stage2/build/TcRnDriver.dyn_o: Max. residency: 172892128 / In use: 458M
"inplace/bin/ghc-stage1" ... compiler/stage2/build/HscMain.dyn_o: Max. residency: 172802688 / In use: 470M
"inplace/bin/ghc-stage1" ... libraries/ghci/dist-install/build/GHCi/TH/Binary.dyn_o: Max. residency: 169775368 / In use: 455M
"inplace/bin/ghc-stage1" ... compiler/stage2/build/GhcMake.dyn_o: Max. residency: 167305408 / In use: 431M
"inplace/bin/ghc-stage1" ... compiler/stage2/build/PrimOp.dyn_o: Max. residency: 162532408 / In use: 455M
"/usr/local/bin/ghc" ... compiler/stage1/build/HscTypes.o: Max. residency: 160814736 / In use: 421M
"inplace/bin/ghc-stage1" ... compiler/stage2/build/HsDecls.dyn_o: Max. residency: 160445552 / In use: 426M
"inplace/bin/ghc-stage1" ... libraries/Cabal/Cabal/dist-install/build/Language/Haskell/Extension.dyn_o: Max. residency: 159817712 / In use: 363M
"/usr/local/bin/ghc" ... compiler/stage1/build/TcSplice.o: Max. residency: 156738656 / In use: 375M
"/usr/local/bin/ghc" ... compiler/stage1/build/TcRnDriver.o: Max. residency: 153910768 / In use: 421M
"inplace/bin/ghc-stage1" ... libraries/containers/dist-install/build/Data/Sequence/Internal.dyn_o: Max. residency: 151318224 / In use: 405M
"inplace/bin/ghc-stage1" ... compiler/stage2/build/MatchLit.dyn_o: Max. residency: 150681176 / In use: 382M
"/usr/local/bin/ghc" ... compiler/stage1/build/ByteCodeGen.o: Max. residency: 144579176 / In use: 389M
"/usr/local/bin/ghc" ... compiler/stage1/build/GhcMake.o: Max. residency: 144411312 / In use: 379M
"/usr/local/bin/ghc" ... compiler/stage1/build/MatchLit.o: Max. residency: 142596736 / In use: 382M
"inplace/bin/ghc-stage1" ... compiler/stage2/build/StgCmmPrim.dyn_o: Max. residency: 141484616 / In use: 340M
"inplace/bin/ghc-stage1" ... libraries/ghci/dist-install/build/GHCi/Message.dyn_o: Max. residency: 139224136 / In use: 363M
"/usr/local/bin/ghc" ... compiler/stage1/build/StgCmmPrim.o: Max. residency: 137390744 / In use: 346M
"inplace/bin/ghc-stage1" ... compiler/stage2/build/TcExpr.dyn_o: Max. residency: 136387128 / In use: 370M
"inplace/bin/ghc-stage1" ... compiler/stage2/build/Lexer.dyn_o: Max. residency: 135228120 / In use: 337M
"inplace/bin/ghc-stage1" ... compiler/stage2/build/TcTyClsDecls.dyn_o: Max. residency: 134817024 / In use: 369M
"/usr/local/bin/ghc" ... compiler/stage1/build/MkIface.o: Max. residency: 134039144 / In use: 339M
"inplace/bin/ghc-stage1" ... compiler/stage2/build/RnExpr.dyn_o: Max. residency: 133947600 / In use: 345M
"inplace/bin/ghc-stage1" ... compiler/stage2/build/HscTypes.dyn_o: Max. residency: 133938840 / In use: 366M
"inplace/bin/ghc-stage1" ... compiler/stage2/build/TcGenDeriv.dyn_o: Max. residency: 133744056 / In use: 320M
"/usr/local/bin/ghc" ... compiler/stage1/build/TcExpr.o: Max. residency: 131766896 / In use: 336M
"inplace/bin/ghc-stage1" ... compiler/stage2/build/GHC.dyn_o: Max. residency: 130998912 / In use: 277M
"inplace/bin/ghc-stage1" ... compiler/stage2/build/ByteCodeGen.dyn_o: Max. residency: 129499464 / In use: 348M
"inplace/bin/ghc-stage1" ... compiler/stage2/build/InteractiveEval.dyn_o: Max. residency: 128902944 / In use: 286M
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"High-residency modules during GHC build","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"While trying to figure out memory allocation failures on the CI server, I tracked allocations and residency on a per-module basis, and noticed that some modules require a lot more memory to compile than others.\r\n\r\nI've compiled a digest of the most memory-hungry compilation steps:\r\n\r\n{{{\r\n\"/usr/local/bin/ghc\" ... compiler/stage1/build/OptCoercion.o: Max. residency: 991356584 / In use: 2094M\r\n\"inplace/bin/ghc-stage1\" ... compiler/stage2/build/OptCoercion.dyn_o: Max. residency: 714940528 / In use: 1471M\r\n\"/usr/local/bin/ghc\" ... compiler/stage1/build/X86/CodeGen.o: Max. residency: 679947656 / In use: 1497M\r\n\"inplace/bin/ghc-stage1\" ... libraries/Cabal/Cabal/dist-install/build/Distribution/SPDX/LicenseId.dyn_o: Max. residency: 653177496 / In use: 1355M\r\n\"inplace/bin/ghc-stage1\" ... compiler/stage2/build/X86/CodeGen.dyn_o: Max. residency: 641515344 / In use: 1425M\r\n\"/usr/local/bin/ghc\" ... -ilibraries/parsec: Max. residency: 593335568 / In use: 1355M\r\n\"/usr/local/bin/ghc\" ... libraries/Cabal/Cabal/dist-boot/build/Distribution/SPDX/LicenseId.o: Max. residency: 575034968 / In use: 1137M\r\n\"inplace/bin/ghc-stage1\" ... compiler/stage2/build/DynFlags.dyn_o: Max. residency: 402734408 / In use: 1059M\r\n\"/usr/local/bin/ghc\" ... compiler/stage1/build/DynFlags.o: Max. residency: 343154784 / In use: 892M\r\n\"inplace/bin/ghc-stage1\" ... libraries/template-haskell/dist-install/build/Language/Haskell/TH/Syntax.dyn_o: Max. residency: 266744312 / In use: 720M\r\n\"/usr/local/bin/ghc\" ... compiler/stage1/build/Parser.o: Max. residency: 258613584 / In use: 679M\r\n\"inplace/bin/ghc-stage1\" ... compiler/stage2/build/CmmOpt.dyn_o: Max. residency: 254639624 / In use: 568M\r\n\"inplace/bin/ghc-stage1\" ... compiler/stage2/build/Parser.dyn_o: Max. residency: 236774592 / In use: 635M\r\n\"inplace/bin/ghc-stage1\" ... ghc/stage2/build/GHCi/UI.dyn_o: Max. residency: 234055792 / In use: 609M\r\n\"/usr/local/bin/ghc\" ... compiler/stage1/build/HsExpr.o: Max. residency: 233724400 / In use: 657M\r\n\"/usr/local/bin/ghc\" ... compiler/stage1/build/CmmOpt.o: Max. residency: 208378888 / In use: 436M\r\n\"/usr/local/bin/ghc\" ... compiler/stage1/build/HscMain.o: Max. residency: 197177248 / In use: 500M\r\n\"inplace/bin/ghc-stage1\" ... compiler/stage2/build/HsExpr.dyn_o: Max. residency: 192780496 / In use: 521M\r\n\"inplace/bin/ghc-stage1\" ... libraries/Cabal/Cabal/dist-install/build/Distribution/Simple/Setup.dyn_o: Max. residency: 191649952 / In use: 521M\r\n\"/usr/local/bin/ghc\" ... compiler/stage1/build/HsDecls.o: Max. residency: 183441120 / In use: 508M\r\n\"inplace/bin/ghc-stage1\" ... compiler/stage2/build/TcSplice.dyn_o: Max. residency: 176802000 / In use: 445M\r\n\"inplace/bin/ghc-stage1\" ... compiler/stage2/build/TcRnDriver.dyn_o: Max. residency: 172892128 / In use: 458M\r\n\"inplace/bin/ghc-stage1\" ... compiler/stage2/build/HscMain.dyn_o: Max. residency: 172802688 / In use: 470M\r\n\"inplace/bin/ghc-stage1\" ... libraries/ghci/dist-install/build/GHCi/TH/Binary.dyn_o: Max. residency: 169775368 / In use: 455M\r\n\"inplace/bin/ghc-stage1\" ... compiler/stage2/build/GhcMake.dyn_o: Max. residency: 167305408 / In use: 431M\r\n\"inplace/bin/ghc-stage1\" ... compiler/stage2/build/PrimOp.dyn_o: Max. residency: 162532408 / In use: 455M\r\n\"/usr/local/bin/ghc\" ... compiler/stage1/build/HscTypes.o: Max. residency: 160814736 / In use: 421M\r\n\"inplace/bin/ghc-stage1\" ... compiler/stage2/build/HsDecls.dyn_o: Max. residency: 160445552 / In use: 426M\r\n\"inplace/bin/ghc-stage1\" ... libraries/Cabal/Cabal/dist-install/build/Language/Haskell/Extension.dyn_o: Max. residency: 159817712 / In use: 363M\r\n\"/usr/local/bin/ghc\" ... compiler/stage1/build/TcSplice.o: Max. residency: 156738656 / In use: 375M\r\n\"/usr/local/bin/ghc\" ... compiler/stage1/build/TcRnDriver.o: Max. residency: 153910768 / In use: 421M\r\n\"inplace/bin/ghc-stage1\" ... libraries/containers/dist-install/build/Data/Sequence/Internal.dyn_o: Max. residency: 151318224 / In use: 405M\r\n\"inplace/bin/ghc-stage1\" ... compiler/stage2/build/MatchLit.dyn_o: Max. residency: 150681176 / In use: 382M\r\n\"/usr/local/bin/ghc\" ... compiler/stage1/build/ByteCodeGen.o: Max. residency: 144579176 / In use: 389M\r\n\"/usr/local/bin/ghc\" ... compiler/stage1/build/GhcMake.o: Max. residency: 144411312 / In use: 379M\r\n\"/usr/local/bin/ghc\" ... compiler/stage1/build/MatchLit.o: Max. residency: 142596736 / In use: 382M\r\n\"inplace/bin/ghc-stage1\" ... compiler/stage2/build/StgCmmPrim.dyn_o: Max. residency: 141484616 / In use: 340M\r\n\"inplace/bin/ghc-stage1\" ... libraries/ghci/dist-install/build/GHCi/Message.dyn_o: Max. residency: 139224136 / In use: 363M\r\n\"/usr/local/bin/ghc\" ... compiler/stage1/build/StgCmmPrim.o: Max. residency: 137390744 / In use: 346M\r\n\"inplace/bin/ghc-stage1\" ... compiler/stage2/build/TcExpr.dyn_o: Max. residency: 136387128 / In use: 370M\r\n\"inplace/bin/ghc-stage1\" ... compiler/stage2/build/Lexer.dyn_o: Max. residency: 135228120 / In use: 337M\r\n\"inplace/bin/ghc-stage1\" ... compiler/stage2/build/TcTyClsDecls.dyn_o: Max. residency: 134817024 / In use: 369M\r\n\"/usr/local/bin/ghc\" ... compiler/stage1/build/MkIface.o: Max. residency: 134039144 / In use: 339M\r\n\"inplace/bin/ghc-stage1\" ... compiler/stage2/build/RnExpr.dyn_o: Max. residency: 133947600 / In use: 345M\r\n\"inplace/bin/ghc-stage1\" ... compiler/stage2/build/HscTypes.dyn_o: Max. residency: 133938840 / In use: 366M\r\n\"inplace/bin/ghc-stage1\" ... compiler/stage2/build/TcGenDeriv.dyn_o: Max. residency: 133744056 / In use: 320M\r\n\"/usr/local/bin/ghc\" ... compiler/stage1/build/TcExpr.o: Max. residency: 131766896 / In use: 336M\r\n\"inplace/bin/ghc-stage1\" ... compiler/stage2/build/GHC.dyn_o: Max. residency: 130998912 / In use: 277M\r\n\"inplace/bin/ghc-stage1\" ... compiler/stage2/build/ByteCodeGen.dyn_o: Max. residency: 129499464 / In use: 348M\r\n\"inplace/bin/ghc-stage1\" ... compiler/stage2/build/InteractiveEval.dyn_o: Max. residency: 128902944 / In use: 286M\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14798Error message suggests applying (non-existant) function to more arguments2019-07-07T18:15:32ZIcelandjackError message suggests applying (non-existant) function to more argumentsApplying a constraint that doesn't hold fails, this is expected
```
$ ~/code/qc-ghc/inplace/bin/ghc-stage2 --interactive -ignore-dot-ghci
GHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help
Prelude> :set -XGADTs -XConst...Applying a constraint that doesn't hold fails, this is expected
```
$ ~/code/qc-ghc/inplace/bin/ghc-stage2 --interactive -ignore-dot-ghci
GHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help
Prelude> :set -XGADTs -XConstraintKinds -XTypeApplications
Prelude> data Dict c where Dict :: c => Dict c
Prelude> data A
Prelude> :t Dict @(Eq A)
<interactive>:1:1: error:
No instance for (Eq A) arising from a use of ‘Dict’
```
but for `(Eq (Int -> Int))` GHC additionally suggests maybe applying a function (what function?) to more arguments
```
Prelude> :t Dict @(Eq (Int -> Int))
<interactive>:1:1: error:
No instance for (Eq (Int -> Int)) arising from a use of ‘Dict’
(maybe you haven't applied a function to enough arguments?)
Prelude>
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Error message suggests applying (non-existant) function to more arguments","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Applying a constraint that doesn't hold fails, this is expected\r\n\r\n{{{\r\n$ ~/code/qc-ghc/inplace/bin/ghc-stage2 --interactive -ignore-dot-ghci\r\nGHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help\r\nPrelude> :set -XGADTs -XConstraintKinds -XTypeApplications \r\nPrelude> data Dict c where Dict :: c => Dict c\r\nPrelude> data A\r\nPrelude> :t Dict @(Eq A)\r\n\r\n<interactive>:1:1: error:\r\n No instance for (Eq A) arising from a use of ‘Dict’\r\n}}}\r\n\r\nbut for `(Eq (Int -> Int))` GHC additionally suggests maybe applying a function (what function?) to more arguments\r\n\r\n{{{\r\nPrelude> :t Dict @(Eq (Int -> Int))\r\n\r\n<interactive>:1:1: error:\r\n No instance for (Eq (Int -> Int)) arising from a use of ‘Dict’\r\n (maybe you haven't applied a function to enough arguments?)\r\nPrelude> \r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14799QuantifiedConstraints: Problems with Typeable2019-07-07T18:15:32ZIcelandjackQuantifiedConstraints: Problems with TypeableThis compiles
```hs
{-# Language GADTs, ConstraintKinds, ScopedTypeVariables, QuantifiedConstraints #-}
import Data.Typeable
data Ex cls where
MkEx :: cls xx => xx -> Ex cls
a :: Ex Typeable -> TypeRep
a (MkEx (_::xx)) = typeRep @_...This compiles
```hs
{-# Language GADTs, ConstraintKinds, ScopedTypeVariables, QuantifiedConstraints #-}
import Data.Typeable
data Ex cls where
MkEx :: cls xx => xx -> Ex cls
a :: Ex Typeable -> TypeRep
a (MkEx (_::xx)) = typeRep @_ @xx Proxy
-- b :: (forall xx. cls xx => Typeable xx) => Ex cls -> TypeRep
-- b (MkEx (_::xx)) = typeRep @_ @xx Proxy
c :: (forall xx. cls xx => Show xx) => Ex cls -> String
c (MkEx xx) = show xx
```
but uncommenting `b` is too much:
```
$ qc hs/189-bug.hs
GHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling Main ( hs/189-bug.hs, interpreted )
hs/189-bug.hs:12:20: error:
• Could not deduce (Typeable xx) arising from a use of ‘typeRep’
from the context: forall xx. cls xx => Typeable xx
bound by the type signature for:
b :: forall (cls :: * -> Constraint).
(forall xx. cls xx => Typeable xx) =>
Ex cls -> TypeRep
at hs/189-bug.hs:11:1-60
or from: cls xx
bound by a pattern with constructor:
MkEx :: forall xx (cls :: * -> Constraint). cls xx => xx -> Ex cls,
in an equation for ‘b’
at hs/189-bug.hs:12:4-15
• In the expression: typeRep @_ @xx Proxy
In an equation for ‘b’: b (MkEx (_ :: xx)) = typeRep @_ @xx Proxy
|
12 | b (MkEx (_::xx)) = typeRep @_ @xx Proxy
| ^^^^^^^^^^^^^^^^^^^^
Failed, no modules loaded.
Prelude>
```
This is maybe because of the `Typeable` solver.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"QuantifiedConstraints: Problems with Typeable","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":["QuantifiedConstraints,","wipT2893"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This compiles\r\n\r\n{{{#!hs\r\n{-# Language GADTs, ConstraintKinds, ScopedTypeVariables, QuantifiedConstraints #-}\r\n\r\nimport Data.Typeable\r\n\r\ndata Ex cls where\r\n MkEx :: cls xx => xx -> Ex cls\r\n\r\na :: Ex Typeable -> TypeRep\r\na (MkEx (_::xx)) = typeRep @_ @xx Proxy\r\n\r\n-- b :: (forall xx. cls xx => Typeable xx) => Ex cls -> TypeRep\r\n-- b (MkEx (_::xx)) = typeRep @_ @xx Proxy\r\n\r\nc :: (forall xx. cls xx => Show xx) => Ex cls -> String\r\nc (MkEx xx) = show xx\r\n}}}\r\n\r\nbut uncommenting `b` is too much:\r\n\r\n{{{\r\n$ qc hs/189-bug.hs\r\nGHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help\r\n[1 of 1] Compiling Main ( hs/189-bug.hs, interpreted )\r\n\r\nhs/189-bug.hs:12:20: error:\r\n • Could not deduce (Typeable xx) arising from a use of ‘typeRep’\r\n from the context: forall xx. cls xx => Typeable xx\r\n bound by the type signature for:\r\n b :: forall (cls :: * -> Constraint).\r\n (forall xx. cls xx => Typeable xx) =>\r\n Ex cls -> TypeRep\r\n at hs/189-bug.hs:11:1-60\r\n or from: cls xx\r\n bound by a pattern with constructor:\r\n MkEx :: forall xx (cls :: * -> Constraint). cls xx => xx -> Ex cls,\r\n in an equation for ‘b’\r\n at hs/189-bug.hs:12:4-15\r\n • In the expression: typeRep @_ @xx Proxy\r\n In an equation for ‘b’: b (MkEx (_ :: xx)) = typeRep @_ @xx Proxy\r\n |\r\n12 | b (MkEx (_::xx)) = typeRep @_ @xx Proxy\r\n | ^^^^^^^^^^^^^^^^^^^^\r\nFailed, no modules loaded.\r\nPrelude> \r\n}}}\r\n\r\nThis is maybe because of the `Typeable` solver.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14800-Wincomplete-uni-patterns should not warn about explicitly-marked irrefutable...2021-11-24T17:10:18ZEyalLotem-Wincomplete-uni-patterns should not warn about explicitly-marked irrefutable patternsIt is very useful to catch accidentally partial uni-pattern matches:
> Cons x = someVal
However, we explicitly want an irrefutable pattern match:
> Vector2 0 y = Vector2 0 a `op` Vector2 0 b
In this case, it would be really useful to...It is very useful to catch accidentally partial uni-pattern matches:
> Cons x = someVal
However, we explicitly want an irrefutable pattern match:
> Vector2 0 y = Vector2 0 a `op` Vector2 0 b
In this case, it would be really useful to opt out of the warning via:
> \~(Vector2 0 y) = ...
The fact the match is partial is explicit and visible with the \~ syntax, so the warning shouldn't tell us about it.
Right now this warning rules out this useful way of opting in to partiality.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"-Wincomplete-uni-patterns should not warn about explicitly-marked irrefutable patterns","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"It is very useful to catch accidentally partial uni-pattern matches:\r\n\r\n Cons x = someVal\r\n\r\nHowever, we explicitly want an irrefutable pattern match:\r\n\r\n Vector2 0 y = Vector2 0 a `op` Vector2 0 b\r\n\r\nIn this case, it would be really useful to opt out of the warning via:\r\n\r\n ~(Vector2 0 y) = ...\r\n\r\nThe fact the match is partial is explicit and visible with the ~ syntax, so the warning shouldn't tell us about it.\r\n\r\nRight now this warning rules out this useful way of opting in to partiality.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14801Multiple error messages confusing.2019-07-07T18:15:31Zlennart@augustsson.netMultiple error messages confusing.More often than not, ghc reports very confusing errors when you use an undefined (lens) variable. The problem is that an undefined identifier generates subsequent type errors, and some of these type errors might be reported before the un...More often than not, ghc reports very confusing errors when you use an undefined (lens) variable. The problem is that an undefined identifier generates subsequent type errors, and some of these type errors might be reported before the undefined message. When the error list has hundreds of messages it can be very time consuming to find the real error.
Please add an error reporting mode that does not report type errors when there are undefined variables.https://gitlab.haskell.org/ghc/ghc/-/issues/14802panic! (the 'impossible' happened)2022-01-25T18:21:39ZEbanflopanic! (the 'impossible' happened)I was debugging and tried to print a matrix but got the following error message:
\<interactive\>:34:21: error:\<interactive\>: panic! (the 'impossible' happened)
(GHC version 8.0.2 for x86_64-unknown-linux):
> No skolem info: a1_IhX...I was debugging and tried to print a matrix but got the following error message:
\<interactive\>:34:21: error:\<interactive\>: panic! (the 'impossible' happened)
(GHC version 8.0.2 for x86_64-unknown-linux):
> No skolem info: a1_IhXR\[rt\]
UPDATE:
I downloaded ghc 8.2.2, extracted, ran `./config` and then `make install`. Now when I run `ghc -v` it says
> Glasgow Haskell Compiler, Version 8.2.2, stage 2 booted by GHC version 8.0.2
But when I run `ghci` it says that it is version 8.0.2 and it gives the same 'impossible' error as I did before.
I put the function I was debugging in a small file with the other functions that it depends on (sorry, I accidentally attached the same file twice). It would be very difficult to replicate the test cases I was working with without copying a lot more code. I tried running the function on a simple test case (some 3x4 matrix) and when I tried to print the helper variable desired (mat1) it said that the runtime type of mat1 could not be determined. This was fixed by giving the function `calc` a type signature. Indeed, when I put this type signature in my actual code, I was able to debug it without a problem.
My biggest concern at this point is how to boot ghci 8.2.2 instead of 8.0.2, and because of this I'm not sure whether or not what I've described here is a problem with 8.2.2 or just 8.0.2.https://gitlab.haskell.org/ghc/ghc/-/issues/14803Panic during desugaring I think2019-07-07T18:15:30ZjustusPanic during desugaring I thinkThis is the panic message itself
```
ghc: panic! (the 'impossible' happened)
(GHC version 8.2.2 for x86_64-apple-darwin):
mkOneConFull: Not TyConApp:
bndType_aeGK
Call stack:
CallStack (from HasCallStack):
prettyCur...This is the panic message itself
```
ghc: panic! (the 'impossible' happened)
(GHC version 8.2.2 for x86_64-apple-darwin):
mkOneConFull: Not TyConApp:
bndType_aeGK
Call stack:
CallStack (from HasCallStack):
prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable
callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable
pprPanic, called at compiler/deSugar/Check.hs:976:30 in ghc:Check
```
And these are the options I use to compile:
- `-Wall`
- `-Wall`
- `-Wcompat`
- `-Wincomplete-record-updates`
- `-Wincomplete-uni-patterns`
- `-Wredundant-constraints`
This is the file I am trying to compile [https://github.com/ohua-dev/ohua-core/blob/master/src/Ohua/ALang/Passes.hs](https://github.com/ohua-dev/ohua-core/blob/master/src/Ohua/ALang/Passes.hs).
Unfortunately the error message tells me very little about where the error actually occurs, but the `bndType` variables are generally used in the family of `AExpr` types defined here [https://github.com/ohua-dev/ohua-core/blob/master/src/Ohua/ALang/Lang.hs\#L141](https://github.com/ohua-dev/ohua-core/blob/master/src/Ohua/ALang/Lang.hs#L141).
To get the power of `recursion-schemes` all expression types are implemented on a variation of the base functor `AExprF` and then `newtype`s are used to create individual expression types.
If anyone has an idea as to how I could create a minimal example for you guys feel free to tell me and I'll see what I can do.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Panic during desugaring I think","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This is the panic message itself \r\n\r\n{{{\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.2.2 for x86_64-apple-darwin):\r\n\tmkOneConFull: Not TyConApp:\r\n bndType_aeGK\r\n Call stack:\r\n CallStack (from HasCallStack):\r\n prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable\r\n callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable\r\n pprPanic, called at compiler/deSugar/Check.hs:976:30 in ghc:Check\r\n}}}\r\n\r\nAnd these are the options I use to compile:\r\n\r\n- {{{-Wall}}}\r\n- {{{-Wall}}}\r\n- {{{-Wcompat}}}\r\n- {{{-Wincomplete-record-updates}}}\r\n- {{{-Wincomplete-uni-patterns}}}\r\n- {{{-Wredundant-constraints}}}\r\n\r\nThis is the file I am trying to compile [https://github.com/ohua-dev/ohua-core/blob/master/src/Ohua/ALang/Passes.hs].\r\nUnfortunately the error message tells me very little about where the error actually occurs, but the {{{bndType}}} variables are generally used in the family of {{{AExpr}}} types defined here [https://github.com/ohua-dev/ohua-core/blob/master/src/Ohua/ALang/Lang.hs#L141]. \r\nTo get the power of {{{recursion-schemes}}} all expression types are implemented on a variation of the base functor {{{AExprF}}} and then {{{newtype}}}s are used to create individual expression types.\r\n\r\nIf anyone has an idea as to how I could create a minimal example for you guys feel free to tell me and I'll see what I can do.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14804hGetLine does not document whether newline is returned.2024-02-08T17:32:06ZAlexander KjeldaashGetLine does not document whether newline is returned.Current documentation on hackage:
hGetLine :: Handle -\> IO String
Computation hGetLine hdl reads a line from the file or channel managed by hdl.
This operation may fail with:
> isEOFError if the end of file is encountered when read...Current documentation on hackage:
hGetLine :: Handle -\> IO String
Computation hGetLine hdl reads a line from the file or channel managed by hdl.
This operation may fail with:
> isEOFError if the end of file is encountered when reading the first character of the line.
If hGetLine encounters end-of-file at any other point while reading in a line, it is treated as a line terminator and the (partial) line is returned.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2.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":"hGetLine does not document whether newline is returned.","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Current documentation on hackage:\r\n\r\nhGetLine :: Handle -> IO String\r\n\r\nComputation hGetLine hdl reads a line from the file or channel managed by hdl.\r\n\r\nThis operation may fail with:\r\n\r\n isEOFError if the end of file is encountered when reading the first character of the line.\r\n\r\nIf hGetLine encounters end-of-file at any other point while reading in a line, it is treated as a line terminator and the (partial) line is returned.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14805Allow disabling warnings on a per-block of code basis2019-07-07T18:15:30ZMaxGabrielAllow disabling warnings on a per-block of code basisHaskell developers frequently want to disable a warning, but not for their whole project. Right now the only way to do that is on a per-file basis. This isn't ideal, because it's a pretty broad brush for what is often a warning you only ...Haskell developers frequently want to disable a warning, but not for their whole project. Right now the only way to do that is on a per-file basis. This isn't ideal, because it's a pretty broad brush for what is often a warning you only want to disable in one place. The way other compilers solve this is by allowing you to ignore warnings only between two lines in the code. Here's Clang and GCC:
```
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wunused-variable"
int a;
#pragma clang diagnostic pop
```
```
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wunused-result"
write(foo, bar, baz);
#pragma GCC diagnostic pop
```
Examples of warnings people may want to ignore only in a certain location:
In [yesod-core/yesod/Core.hs](https://github.com/yesodweb/yesod/blob/f2b651b69537985c5a2ca378018fd50537c3454b/yesod-core/Yesod/Core.hs#L5), deprecation warnings are disabled for the whole file, but it's not clear what deprecations are trying to be avoided. It's possible that code is no longer relevant.
The tests for the `yesod-test` package test a function that yesod-test has deprecated, but still wants to test. Because of this, [it ignores all deprecation warnings](https://github.com/yesodweb/yesod/blob/f2b651b69537985c5a2ca378018fd50537c3454b/yesod-test/test/main.hs#L1-L2), when it could be only ignoring them for a few lines.
It's pretty easy to find examples of this; just search a repo for `{-# OPTIONS_GHC -fno` and you'll probably find cases where warnings are disabled in a more broad way than is necessary.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Allow disabling warnings on a per-block of code basis","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Haskell developers frequently want to disable a warning, but not for their whole project. Right now the only way to do that is on a per-file basis. This isn't ideal, because it's a pretty broad brush for what is often a warning you only want to disable in one place. The way other compilers solve this is by allowing you to ignore warnings only between two lines in the code. Here's Clang and GCC:\r\n\r\n{{{\r\n#pragma clang diagnostic push\r\n#pragma clang diagnostic ignored \"-Wunused-variable\"\r\n\r\nint a;\r\n\r\n#pragma clang diagnostic pop\r\n}}}\r\n\r\n{{{\r\n#pragma GCC diagnostic push\r\n#pragma GCC diagnostic ignored \"-Wunused-result\"\r\n write(foo, bar, baz);\r\n#pragma GCC diagnostic pop\r\n}}}\r\n\r\nExamples of warnings people may want to ignore only in a certain location:\r\n\r\nIn [https://github.com/yesodweb/yesod/blob/f2b651b69537985c5a2ca378018fd50537c3454b/yesod-core/Yesod/Core.hs#L5 yesod-core/yesod/Core.hs], deprecation warnings are disabled for the whole file, but it's not clear what deprecations are trying to be avoided. It's possible that code is no longer relevant.\r\n\r\nThe tests for the `yesod-test` package test a function that yesod-test has deprecated, but still wants to test. Because of this, [https://github.com/yesodweb/yesod/blob/f2b651b69537985c5a2ca378018fd50537c3454b/yesod-test/test/main.hs#L1-L2 it ignores all deprecation warnings], when it could be only ignoring them for a few lines.\r\n\r\nIt's pretty easy to find examples of this; just search a repo for `{-# OPTIONS_GHC -fno` and you'll probably find cases where warnings are disabled in a more broad way than is necessary.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14806Officially sanction certain unsafeCoerce applications with unboxed unary tuples2020-01-23T19:26:37ZDavid FeuerOfficially sanction certain unsafeCoerce applications with unboxed unary tuplesIt seems that it should be okay to `unsafeCoerce` between types that wrap certain things in unboxed unary tuples and ones that do not. For example,
```hs
unsafeCoerce :: (A -> B) -> A -> (# B #)
unsafeCoerce :: ((# A #) -> B) -> A -> B
...It seems that it should be okay to `unsafeCoerce` between types that wrap certain things in unboxed unary tuples and ones that do not. For example,
```hs
unsafeCoerce :: (A -> B) -> A -> (# B #)
unsafeCoerce :: ((# A #) -> B) -> A -> B
```
Generally, I believe `unsafeCoerce :: E1 -> E2` should be okay when the only differences are in what is wrapped in an unboxed unary tuple and both of the following hold:
1. Each new unary tuple wrapper in `E2` is in a positive position.
1. Each new unary tuple wrapper in `E1` is in a negative position.
Semantically,
```hs
unsafeCoerce :: (A -> B) -> A -> (# B #)
=
\f a -> let !fa = f a in (# fa #)
unsafeCoerce :: ((# A #) -> B) -> A -> B
=
\f !a -> f (# a #)
```
Am I correct in this interpretation? If so, is this something the developers would be willing to commit to and document? The first version in particular (a new unary tuple wrapper in positive position in the result) would be very useful for reducing both source code and generated code size in libraries supporting both strict and lazy operations.https://gitlab.haskell.org/ghc/ghc/-/issues/14807GHC does not pass -dstg-lint2019-07-07T18:15:30ZSergey VinokurovGHC does not pass -dstg-lintWhen building ghc-8.4 branch with -dstg-lint enabled I got a GHC panic error (please see attachment for full log as it's really big). The error is reproducible on Windows and Debian Linux 64 bit operating systems.
Short error:
```
"inp...When building ghc-8.4 branch with -dstg-lint enabled I got a GHC panic error (please see attachment for full log as it's really big). The error is reproducible on Windows and Debian Linux 64 bit operating systems.
Short error:
```
"inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O -H64m -Wall -this-unit-id ghc-prim-0.5.2.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/./autogen -Ilibraries/ghc-prim/dist-install/build/./autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/./autogen/cabal_macros.h -package-id rts -this-unit-id ghc-prim -XHaskell2010 -O -dcore-lint -dstg-lint -dcmm-lint -no-user-package-db -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags -Wnoncanonical-monad-instances -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -dynamic-too -c libraries/ghc-prim/./GHC/Types.hs -o libraries/ghc-prim/dist-install/build/GHC/Types.o -dyno libraries/ghc-prim/dist-install/build/GHC/Types.dyn_o
ghc-stage1: panic! (the 'impossible' happened)
(GHC version 8.4.0.20180204 for x86_64-unknown-linux):
*** Stg Lint ErrMsgs: in Unarise ***
<no location info>: warning:
[in body of lambda with binders v_s9Xn :: (a_12 :: k0_10)
~~ (b_13 :: k1_11)]
In some algebraic case alternative, number of arguments doesn't match constructor:
Eq# (arity 1)
[]
<no location info>: warning:
[in body of lambda with binders v_s9Xp :: Coercible a_11 b_12]
In some algebraic case alternative, number of arguments doesn't match constructor:
MkCoercible (arity 1)
[]
*** Offending Program ***
... lots of lines skipped ...
*** End of Offense ***
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable
pprPanic, called at compiler/stgSyn/StgLint.hs:68:19 in ghc:StgLint
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
libraries/ghc-prim/ghc.mk:4: recipe for target 'libraries/ghc-prim/dist-install/build/GHC/Types.o' failed
```
As a side note, it seems that it would be good to enable `-dstg-lint` and `-dcmm-lint` in `devel2` flavour, and possibly some other flavours, or at least on CI, so that they will be tested more frequently.8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/14808GHC HEAD regression: GADT constructors no longer quantify tyvars in topologic...2019-07-07T18:15:30ZRyan ScottGHC HEAD regression: GADT constructors no longer quantify tyvars in topological orderOriginally noticed in #14796. This program:
```hs
{-# LANGUAGE ConstraintKinds #-}
{-# LANGUAGE GADTs #-}
{-# LANGUAGE TypeApplications #-}
module Bug where
import Data.Kind
data ECC ctx f a where
ECC :: ctx => f a -> ECC ctx f a
f...Originally noticed in #14796. This program:
```hs
{-# LANGUAGE ConstraintKinds #-}
{-# LANGUAGE GADTs #-}
{-# LANGUAGE TypeApplications #-}
module Bug where
import Data.Kind
data ECC ctx f a where
ECC :: ctx => f a -> ECC ctx f a
f :: [()] -> ECC () [] ()
f = ECC @() @[] @()
```
Typechecks in GHC 8.2.2 and 8.4.1, but not in GHC HEAD:
```
$ ~/Software/ghc2/inplace/bin/ghc-stage2 Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Bug.hs:12:5: error:
• Couldn't match type ‘()’ with ‘[]’
Expected type: [()] -> ECC (() :: Constraint) [] ()
Actual type: () [] -> ECC (() :: Constraint) () []
• In the expression: ECC @() @[] @()
In an equation for ‘f’: f = ECC @() @[] @()
|
12 | f = ECC @() @[] @()
| ^^^^^^^^^^^^^^^
Bug.hs:12:10: error:
• Expected kind ‘* -> *’, but ‘()’ has kind ‘*’
• In the type ‘()’
In the expression: ECC @() @[] @()
In an equation for ‘f’: f = ECC @() @[] @()
|
12 | f = ECC @() @[] @()
| ^^
Bug.hs:12:14: error:
• Expecting one more argument to ‘[]’
Expected a type, but ‘[]’ has kind ‘* -> *’
• In the type ‘[]’
In the expression: ECC @() @[] @()
In an equation for ‘f’: f = ECC @() @[] @()
|
12 | f = ECC @() @[] @()
| ^^
```
This is because the order of type variables for `ECC` has changed between GHC 8.4.1 and HEAD. In 8.4.1, it's
```
$ /opt/ghc/8.4.1/bin/ghci Bug.hs -XTypeApplications -fprint-explicit-foralls
GHCi, version 8.4.0.20180209: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
[1 of 1] Compiling Bug ( Bug.hs, interpreted )
Ok, one module loaded.
λ> :type +v ECC
ECC
:: forall (ctx :: Constraint) (f :: * -> *) a.
ctx =>
f a -> ECC ctx f a
```
In GHC HEAD, however, it's:
```
$ ~/Software/ghc2/inplace/bin/ghc-stage2 --interactive Bug.hs -XTypeApplications -fprint-explicit-foralls
GHCi, version 8.5.20180213: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
[1 of 1] Compiling Bug ( Bug.hs, interpreted )
Ok, one module loaded.
λ> :type +v ECC
ECC
:: forall (f :: * -> *) a (ctx :: Constraint).
ctx =>
f a -> ECC ctx f a
```
This regression was introduced in fa29df02a1b0b926afb2525a258172dcbf0ea460 (Refactor ConDecl: Trac #14529).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonpj |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC HEAD regression: GADT constructors no longer quantify tyvars in topological order","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":["GADTs"],"differentials":[],"test_case":"","architecture":"","cc":["simonpj"],"type":"Bug","description":"Originally noticed in #14796. This program:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE ConstraintKinds #-}\r\n{-# LANGUAGE GADTs #-}\r\n{-# LANGUAGE TypeApplications #-}\r\nmodule Bug where\r\n\r\nimport Data.Kind\r\n\r\ndata ECC ctx f a where\r\n ECC :: ctx => f a -> ECC ctx f a\r\n\r\nf :: [()] -> ECC () [] ()\r\nf = ECC @() @[] @()\r\n}}}\r\n\r\nTypechecks in GHC 8.2.2 and 8.4.1, but not in GHC HEAD:\r\n\r\n{{{\r\n$ ~/Software/ghc2/inplace/bin/ghc-stage2 Bug.hs\r\n[1 of 1] Compiling Bug ( Bug.hs, Bug.o )\r\n\r\nBug.hs:12:5: error:\r\n • Couldn't match type ‘()’ with ‘[]’\r\n Expected type: [()] -> ECC (() :: Constraint) [] ()\r\n Actual type: () [] -> ECC (() :: Constraint) () []\r\n • In the expression: ECC @() @[] @()\r\n In an equation for ‘f’: f = ECC @() @[] @()\r\n |\r\n12 | f = ECC @() @[] @()\r\n | ^^^^^^^^^^^^^^^\r\n\r\nBug.hs:12:10: error:\r\n • Expected kind ‘* -> *’, but ‘()’ has kind ‘*’\r\n • In the type ‘()’\r\n In the expression: ECC @() @[] @()\r\n In an equation for ‘f’: f = ECC @() @[] @()\r\n |\r\n12 | f = ECC @() @[] @()\r\n | ^^\r\n\r\nBug.hs:12:14: error:\r\n • Expecting one more argument to ‘[]’\r\n Expected a type, but ‘[]’ has kind ‘* -> *’\r\n • In the type ‘[]’\r\n In the expression: ECC @() @[] @()\r\n In an equation for ‘f’: f = ECC @() @[] @()\r\n |\r\n12 | f = ECC @() @[] @()\r\n | ^^\r\n}}}\r\n\r\nThis is because the order of type variables for `ECC` has changed between GHC 8.4.1 and HEAD. In 8.4.1, it's\r\n\r\n{{{\r\n$ /opt/ghc/8.4.1/bin/ghci Bug.hs -XTypeApplications -fprint-explicit-foralls\r\nGHCi, version 8.4.0.20180209: http://www.haskell.org/ghc/ :? for help\r\nLoaded GHCi configuration from /home/rgscott/.ghci\r\n[1 of 1] Compiling Bug ( Bug.hs, interpreted )\r\nOk, one module loaded.\r\nλ> :type +v ECC\r\nECC\r\n :: forall (ctx :: Constraint) (f :: * -> *) a.\r\n ctx =>\r\n f a -> ECC ctx f a\r\n}}}\r\n\r\nIn GHC HEAD, however, it's:\r\n\r\n{{{\r\n$ ~/Software/ghc2/inplace/bin/ghc-stage2 --interactive Bug.hs -XTypeApplications -fprint-explicit-foralls\r\nGHCi, version 8.5.20180213: http://www.haskell.org/ghc/ :? for help\r\nLoaded GHCi configuration from /home/rgscott/.ghci\r\n[1 of 1] Compiling Bug ( Bug.hs, interpreted )\r\nOk, one module loaded.\r\nλ> :type +v ECC\r\nECC\r\n :: forall (f :: * -> *) a (ctx :: Constraint).\r\n ctx =>\r\n f a -> ECC ctx f a\r\n}}}\r\n\r\nThis regression was introduced in fa29df02a1b0b926afb2525a258172dcbf0ea460 (Refactor ConDecl: Trac #14529).","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Richard Eisenbergrae@richarde.devRichard Eisenbergrae@richarde.devhttps://gitlab.haskell.org/ghc/ghc/-/issues/14809Invocation of ghc with --make flag should be smarter about hs-boot and lhs-bo...2019-07-07T18:15:29ZmrkkrpInvocation of ghc with --make flag should be smarter about hs-boot and lhs-boot filesCurrently, `--make` in handy for compiling programs with boot files using only one `ghc` invocation. But it behaves strange.
If I pass `A.hs`, `B.hs`, and `A.hs-boot` (where `B.hs` imports module `A` with that `{-# SOURCE -#}` thing), I...Currently, `--make` in handy for compiling programs with boot files using only one `ghc` invocation. But it behaves strange.
If I pass `A.hs`, `B.hs`, and `A.hs-boot` (where `B.hs` imports module `A` with that `{-# SOURCE -#}` thing), I get an error message complaining about module `A` defined twice. Surely GHC should be able to figure out that if the second file has the extension `hs-boot`, it's a boot file and should be used as such.
After all, GHC is perfectly capable of finding boot files if it's given import directories to search in (with `-i`). We can't however easily use that because it so happens that if we tell ghc about such directories, they can contain files that should not be visible. I even tried a workaround: copy all boot files to a separate location and then point to that location with `-i`. To my surprise in that case ghc does not pick up those boot files. (And with more complex nesting of modules I expect more problems with this approach.)
So it would be great if we could just feed all the relevant files into ghc and it would be smart enough not to complain about modules defined twice if one of the modules is in a file with `hs-boot` or `lhs-boot` extension, but use it as a boot file for corresponding module.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Invocation of ghc with --make flag should be smarter about hs-boot and lhs-boot files","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Currently, `--make` in handy for compiling programs with boot files using only one `ghc` invocation. But it behaves strange.\r\n\r\nIf I pass `A.hs`, `B.hs`, and `A.hs-boot` (where `B.hs` imports module `A` with that `{-# SOURCE -#}` thing), I get an error message complaining about module `A` defined twice. Surely GHC should be able to figure out that if the second file has the extension `hs-boot`, it's a boot file and should be used as such.\r\n\r\nAfter all, GHC is perfectly capable of finding boot files if it's given import directories to search in (with `-i`). We can't however easily use that because it so happens that if we tell ghc about such directories, they can contain files that should not be visible. I even tried a workaround: copy all boot files to a separate location and then point to that location with `-i`. To my surprise in that case ghc does not pick up those boot files. (And with more complex nesting of modules I expect more problems with this approach.)\r\n\r\nSo it would be great if we could just feed all the relevant files into ghc and it would be smart enough not to complain about modules defined twice if one of the modules is in a file with `hs-boot` or `lhs-boot` extension, but use it as a boot file for corresponding module.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14810Define MVar "This function is atomic only if there are no other producers for...2021-07-08T13:03:35ZAlexander KjeldaasDefine MVar "This function is atomic only if there are no other producers for this MVar."The sentence:
This function is atomic only if there are no other producers for this MVar.
Is repeated lots of times in the Control.Concurrent.MVar documentation.
However, there is no definition of what "producers for an MVar" means.
...The sentence:
This function is atomic only if there are no other producers for this MVar.
Is repeated lots of times in the Control.Concurrent.MVar documentation.
However, there is no definition of what "producers for an MVar" means.
There needs to be a definition of producer (and consumer I guess).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2.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":"Define MVar \"This function is atomic only if there are no other producers for this MVar.\"","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The sentence:\r\n\r\nThis function is atomic only if there are no other producers for this MVar.\r\n\r\nIs repeated lots of times in the Control.Concurrent.MVar documentation.\r\n\r\nHowever, there is no definition of what \"producers for an MVar\" means.\r\n\r\nThere needs to be a definition of producer (and consumer I guess).","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14811Unary unboxed tuple field causes interface file error2019-07-07T18:15:29ZDavid FeuerUnary unboxed tuple field causes interface file errorCompiling this code under 8.2 or HEAD (but not 8.0), I get an error.
```hs
{-# language UnboxedTuples #-}
module Reccy where
data Foo a = Foo (# a #)
```
```
Reccy.hs:1:1: error:
Can't find interface-file declaration for variable ...Compiling this code under 8.2 or HEAD (but not 8.0), I get an error.
```hs
{-# language UnboxedTuples #-}
module Reccy where
data Foo a = Foo (# a #)
```
```
Reccy.hs:1:1: error:
Can't find interface-file declaration for variable GHC.Types.$tcUnit#
Probable cause: bug in .hi-boot file, or inconsistent .hi file
Use -ddump-if-trace to get an idea of which file caused the error
|
1 | -- {-# language GADTs, TypeOperators #-}
| ^
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Unary unboxed tuple field causes panic","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Compiling this code under 8.2 or HEAD (but not 8.0), I get an error.\r\n\r\n{{{#!hs\r\n{-# language UnboxedTuples #-}\r\nmodule Reccy where\r\n\r\ndata Foo a = Foo (# a #)\r\n}}}\r\n\r\n{{{\r\nReccy.hs:1:1: error:\r\n Can't find interface-file declaration for variable GHC.Types.$tcUnit#\r\n Probable cause: bug in .hi-boot file, or inconsistent .hi file\r\n Use -ddump-if-trace to get an idea of which file caused the error\r\n |\r\n1 | -- {-# language GADTs, TypeOperators #-}\r\n | ^\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.4.1https://gitlab.haskell.org/ghc/ghc/-/issues/14812Dot-Notation for Flipped Function Application2019-07-07T18:15:29ZtepanDot-Notation for Flipped Function ApplicationPlease allow to put a dot `.` (without whitespaces) between two things for *flipped* function application. This could make for code in pseudo-OOP style:
```hs
encrypt(str) = do {
str.map(succ);
}
```
Currently, as a workaround, this ...Please allow to put a dot `.` (without whitespaces) between two things for *flipped* function application. This could make for code in pseudo-OOP style:
```hs
encrypt(str) = do {
str.map(succ);
}
```
Currently, as a workaround, this can be achieved by defining `(.) = flip ($)` (making `.` for function composition unavailable, though):
```hs
encrypt(str) = do {
str.map(succ);
} where (.) = flip ($)
```
(For a remotely similar look-and-feel, one could use `Data.Function.((&))` instead of `(.)`.)
Side note: `.` without whitespaces is already an OOP-like notational convenience in order to denote Modules and their elements in Haskell.
OOP:
- `Prelude.length("Hello")` (static function `length` of class `Prelude` applied to `"Hello"`)
Haskell:
- `Prelude.length("Hello")` (function `length` of module `Prelude` applied to `"Hello"`)
This means, that a distinction between ` . ` (with whitespaces) and `.` (without whitespaces) is already been made, which is why `Just . Just $ 42` compiles, whereas `Just.Just $ 42` doesn't. Analogously, with this Feature Request implemented, `"Hello".map(succ)` would compile whereas `"Hello" . map(succ)"` wouldn't.
Current dot-notation for modules (not to be changed):
- `Foo.bar` (`bar` of module `Foo`)
Proposed dot-noation for function application:
- `foo.bar` (function `bar` applied to `foo`)https://gitlab.haskell.org/ghc/ghc/-/issues/14813EmptyCase thinks pattern match involving type family is not exhaustive, when ...2019-07-07T18:15:28ZRyan ScottEmptyCase thinks pattern match involving type family is not exhaustive, when it actually isGHC warns on this program:
```hs
{-# LANGUAGE EmptyCase #-}
{-# LANGUAGE GADTs #-}
{-# LANGUAGE ScopedTypeVariables #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE TypeInType #-}
{-# OPTIONS_GHC -Wall #-}
module Bug where
import Data.Ki...GHC warns on this program:
```hs
{-# LANGUAGE EmptyCase #-}
{-# LANGUAGE GADTs #-}
{-# LANGUAGE ScopedTypeVariables #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE TypeInType #-}
{-# OPTIONS_GHC -Wall #-}
module Bug where
import Data.Kind
import Data.Void
data SBool (z :: Bool) where
SFalse :: SBool 'False
STrue :: SBool 'True
type family F (b :: Bool) (a :: Type) :: Type where
F 'True a = a
F 'False _ = Void
dispatch :: forall (b :: Bool) (a :: Type). SBool b -> F b a -> a
dispatch STrue x = x
dispatch SFalse x = case x of {}
```
```
$ /opt/ghc/8.2.2/bin/ghci Bug.hs
GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
[1 of 1] Compiling Bug ( Bug.hs, interpreted )
Bug.hs:22:21: warning: [-Wincomplete-patterns]
Pattern match(es) are non-exhaustive
In a case alternative: Patterns not matched: _ :: F b a
|
22 | dispatch SFalse x = case x of {}
| ^^^^
```
This warning is incorrect, as `x` is of type `F 'False a`, or `Void`, in that case alternative.
Curiously, if you ascribe either the pattern for `x`:
```hs
dispatch SFalse (x :: F 'False a) = case x of {}
```
Or the case scrutinee:
```hs
dispatch SFalse x = case x :: F 'False a of {}
```
Then the warning goes away.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.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":"EmptyCase thinks pattern match involving type family is not exhaustive, when it actually is","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":["PatternMatchWarnings"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"GHC warns on this program:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE EmptyCase #-}\r\n{-# LANGUAGE GADTs #-}\r\n{-# LANGUAGE ScopedTypeVariables #-}\r\n{-# LANGUAGE TypeFamilies #-}\r\n{-# LANGUAGE TypeInType #-}\r\n{-# OPTIONS_GHC -Wall #-}\r\nmodule Bug where\r\n\r\nimport Data.Kind\r\nimport Data.Void\r\n\r\ndata SBool (z :: Bool) where\r\n SFalse :: SBool 'False\r\n STrue :: SBool 'True\r\n\r\ntype family F (b :: Bool) (a :: Type) :: Type where\r\n F 'True a = a\r\n F 'False _ = Void\r\n\r\ndispatch :: forall (b :: Bool) (a :: Type). SBool b -> F b a -> a\r\ndispatch STrue x = x\r\ndispatch SFalse x = case x of {}\r\n}}}\r\n\r\n{{{\r\n$ /opt/ghc/8.2.2/bin/ghci Bug.hs\r\nGHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help\r\nLoaded GHCi configuration from /home/rgscott/.ghci\r\n[1 of 1] Compiling Bug ( Bug.hs, interpreted )\r\n\r\nBug.hs:22:21: warning: [-Wincomplete-patterns]\r\n Pattern match(es) are non-exhaustive\r\n In a case alternative: Patterns not matched: _ :: F b a\r\n |\r\n22 | dispatch SFalse x = case x of {}\r\n | ^^^^\r\n}}}\r\n\r\nThis warning is incorrect, as `x` is of type `F 'False a`, or `Void`, in that case alternative.\r\n\r\nCuriously, if you ascribe either the pattern for `x`:\r\n\r\n{{{#!hs\r\ndispatch SFalse (x :: F 'False a) = case x of {}\r\n}}}\r\n\r\nOr the case scrutinee:\r\n\r\n{{{#!hs\r\ndispatch SFalse x = case x :: F 'False a of {}\r\n}}}\r\n\r\nThen the warning goes away.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/14814-g causes "cc failed in phase Assembler" in yaml package2019-07-07T18:15:28ZMateusz Kowalczyk-g causes "cc failed in phase Assembler" in yaml package```bash
git clone https://github.com/snoyberg/yaml
cd yaml
git checkout yaml-0.8.28
stack build yaml --resolver=lts-10.5 --ghc-options='-g'
```
With this I get (I'm using nix below but should be irrelevant):
```
[nix-shell:~/programmin...```bash
git clone https://github.com/snoyberg/yaml
cd yaml
git checkout yaml-0.8.28
stack build yaml --resolver=lts-10.5 --ghc-options='-g'
```
With this I get (I'm using nix below but should be irrelevant):
```
[nix-shell:~/programming/yaml]$ stack build yaml --nix -j1 --resolver=lts-10.5 --ghc-options='-g'
raw-strings-qq-1.1: download
raw-strings-qq-1.1: configure
raw-strings-qq-1.1: build
raw-strings-qq-1.1: copy/register
Building all executables for `yaml' once. After a successful build of all of them, only specified executables will be rebuilt.
yaml-0.8.28: configure (lib + exe)
Configuring yaml-0.8.28...
yaml-0.8.28: build (lib + exe)
Preprocessing library for yaml-0.8.28..
Building library for yaml-0.8.28..
[ 1 of 10] Compiling Text.Libyaml ( Text/Libyaml.hs, .stack-work/dist/x86_64-linux-nix/Cabal-2.0.1.0/build/Text/Libyaml.o )
[ 2 of 10] Compiling Data.Yaml.Parser ( Data/Yaml/Parser.hs, .stack-work/dist/x86_64-linux-nix/Cabal-2.0.1.0/build/Data/Yaml/Parser.o )
[ 3 of 10] Compiling Data.Yaml.Internal ( Data/Yaml/Internal.hs, .stack-work/dist/x86_64-linux-nix/Cabal-2.0.1.0/build/Data/Yaml/Internal.o )
/run/user/1000/ghc25193_0/ghc_30.s: Assembler messages:
/home/shana/programming/yaml//run/user/1000/ghc25193_0/ghc_30.s:67519:0: error:
Error: can't resolve `.Lc1azh_entry_end' {*UND* section} - `c1azh_entry' {*UND* section}
|
67519 | .quad .Lc1azh_entry_end-c1azh_entry
| ^
`cc' failed in phase `Assembler'. (Exit code: 1)
Progress: 1/2
-- While building custom Setup.hs for package yaml-0.8.28 using:
/home/shana/.stack/setup-exe-cache/x86_64-linux-nix/Cabal-simple_mPHDZzAJ_2.0.1.0_ghc-8.2.2 --builddir=.stack-work/dist/x86_64-linux-nix/Cabal-2.0.1.0 build lib:yaml exe:examples exe:json2yaml exe:yaml2json --ghc-options " -ddump-hi -ddump-to-file -fdiagnostics-color=always"
Process exited with code: ExitFailure 1 Completed 2 action(s).
```
```
$ uname -a
Linux kagami 4.14.12 #1-NixOS SMP Fri Jan 5 14:48:59 UTC 2018 x86_64 GNU/Linux
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.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":"-g causes \"cc failed in phase Assembler\" in yaml package","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{#!bash\r\ngit clone https://github.com/snoyberg/yaml\r\ncd yaml\r\ngit checkout yaml-0.8.28\r\nstack build yaml --resolver=lts-10.5 --ghc-options='-g'\r\n}}}\r\n\r\nWith this I get (I'm using nix below but should be irrelevant):\r\n\r\n{{{\r\n[nix-shell:~/programming/yaml]$ stack build yaml --nix -j1 --resolver=lts-10.5 --ghc-options='-g'\r\nraw-strings-qq-1.1: download\r\nraw-strings-qq-1.1: configure\r\nraw-strings-qq-1.1: build\r\nraw-strings-qq-1.1: copy/register\r\nBuilding all executables for `yaml' once. After a successful build of all of them, only specified executables will be rebuilt.\r\nyaml-0.8.28: configure (lib + exe)\r\nConfiguring yaml-0.8.28...\r\nyaml-0.8.28: build (lib + exe)\r\nPreprocessing library for yaml-0.8.28..\r\nBuilding library for yaml-0.8.28..\r\n[ 1 of 10] Compiling Text.Libyaml ( Text/Libyaml.hs, .stack-work/dist/x86_64-linux-nix/Cabal-2.0.1.0/build/Text/Libyaml.o )\r\n[ 2 of 10] Compiling Data.Yaml.Parser ( Data/Yaml/Parser.hs, .stack-work/dist/x86_64-linux-nix/Cabal-2.0.1.0/build/Data/Yaml/Parser.o )\r\n[ 3 of 10] Compiling Data.Yaml.Internal ( Data/Yaml/Internal.hs, .stack-work/dist/x86_64-linux-nix/Cabal-2.0.1.0/build/Data/Yaml/Internal.o )\r\n/run/user/1000/ghc25193_0/ghc_30.s: Assembler messages:\r\n \r\n/home/shana/programming/yaml//run/user/1000/ghc25193_0/ghc_30.s:67519:0: error:\r\n Error: can't resolve `.Lc1azh_entry_end' {*UND* section} - `c1azh_entry' {*UND* section}\r\n | \r\n67519 | .quad .Lc1azh_entry_end-c1azh_entry\r\n | ^ \r\n`cc' failed in phase `Assembler'. (Exit code: 1)\r\nProgress: 1/2\r\n-- While building custom Setup.hs for package yaml-0.8.28 using:\r\n /home/shana/.stack/setup-exe-cache/x86_64-linux-nix/Cabal-simple_mPHDZzAJ_2.0.1.0_ghc-8.2.2 --builddir=.stack-work/dist/x86_64-linux-nix/Cabal-2.0.1.0 build lib:yaml exe:examples exe:json2yaml exe:yaml2json --ghc-options \" -ddump-hi -ddump-to-file -fdiagnostics-color=always\"\r\n Process exited with code: ExitFailure 1 Completed 2 action(s).\r\n}}}\r\n\r\n{{{\r\n$ uname -a\r\nLinux kagami 4.14.12 #1-NixOS SMP Fri Jan 5 14:48:59 UTC 2018 x86_64 GNU/Linux\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14815-XStrict prevents code inlining.2019-07-07T18:15:28Zdanilo2-XStrict prevents code inlining.Hi, let's consider the following code:
```hs
{-# LANGUAGE Strict #-} -- Comment/uncommenting this
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE GeneralizedNewtypeDeriving #-}
module K where
import ...Hi, let's consider the following code:
```hs
{-# LANGUAGE Strict #-} -- Comment/uncommenting this
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE GeneralizedNewtypeDeriving #-}
module K where
import Control.Monad.Trans
import qualified Control.Monad.State.Strict as S
import Control.Monad.Primitive
newtype StateT s m a = StateT (S.StateT s m a) -- S is Control.Monad.State.Strict
deriving (Functor, Applicative, Monad, MonadTrans)
instance PrimMonad m => PrimMonad (StateT s m) where
type PrimState (StateT s m) = PrimState m
primitive ~a = lift (primitive a) ; {-# INLINE primitive #-}
```
If compiled with `-XStrict` this code is not inlined properly and it badly affects the performance. While discussing it on Haskell IRC `lyxia` helped very much with discovering the CORE differences. The lazy version has couple of things which the strict version is missing in form of `[InlPrag=INLINE (sat-args=0)]` on toplevel identifiers.
Core: https://gist.github.com/Lysxia/34684c9ca9fe4772ea38a5065414f5428.4.1https://gitlab.haskell.org/ghc/ghc/-/issues/14816DmdAnal punishes free variables compared to static argument encoding2022-11-30T20:18:40ZDavid FeuerDmdAnal punishes free variables compared to static argument encodingWhen I compile
```hs
test :: (a -> a -> a) -> Int -> a -> HashMap Int a -> HashMap Int a
test f k a m = insertModifying a (blink (f a)) k m
blink :: (a -> b) -> a -> (# b #)
-- Or blink g = \a -> (# g a #) ; it makes no difference.
bli...When I compile
```hs
test :: (a -> a -> a) -> Int -> a -> HashMap Int a -> HashMap Int a
test f k a m = insertModifying a (blink (f a)) k m
blink :: (a -> b) -> a -> (# b #)
-- Or blink g = \a -> (# g a #) ; it makes no difference.
blink g a = (# g a #)
```
I get
```
test
= \ (@ a_a9o3)
(f_a7iP :: a_a9o3 -> a_a9o3 -> a_a9o3)
(k_a7iQ :: Int)
(a1_a7iR :: a_a9o3)
(m_a7iS :: HashMap Int a_a9o3) ->
case k_a7iQ of { GHC.Types.I# ww1_sa1Z ->
RULES.$w$sinsertModifying
@ a_a9o3
a1_a7iR
(let {
g_s9E1 [Dmd=<L,C(U)>] :: a_a9o3 -> a_a9o3
[LclId]
g_s9E1 = f_a7iP a1_a7iR } in
\ (a2_a7iU :: a_a9o3) -> (# g_s9E1 a2_a7iU #))
ww1_sa1Z
m_a7iS
}
```
We build `g_s9E1 = f_a7iP a1_a7iR` for no apparent reason. Trouble persists into STG:
```
RULES.test
:: forall a.
(a -> a -> a)
-> GHC.Types.Int
-> a
-> Data.HashMap.Base.HashMap GHC.Types.Int a
-> Data.HashMap.Base.HashMap GHC.Types.Int a
[GblId,
Arity=4,
Str=<L,1*C1(C(U))><S(S),1*U(U)><L,U><S,1*U>,
Unf=OtherCon []] =
[] \r [f_saiX k_saiY a1_saiZ m_saj0]
case k_saiY of {
GHC.Types.I# ww1_saj2 [Occ=Once] ->
let {
g_saj3 [Occ=OnceL!, Dmd=<L,C(U)>] :: a_a9o3 -> a_a9o3
[LclId] =
[f_saiX a1_saiZ] \u [] f_saiX a1_saiZ; } in
let {
sat_saj6 [Occ=Once] :: a_a9o3 -> (# a_a9o3 #)
[LclId] =
[g_saj3] \r [a2_saj4]
let {
sat_saj5 [Occ=Once] :: a_a9o3
[LclId] =
[g_saj3 a2_saj4] \u [] g_saj3 a2_saj4;
} in Unit# [sat_saj5];
} in RULES.$w$sinsertModifying a1_saiZ sat_saj6 ww1_saj2 m_saj0;
};
```
`insertModifying` uses its function argument at most once, so there is no possible benefit to this partial application.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | nomeata |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Missed Called Arity opportunity?","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["nomeata"],"type":"Bug","description":"When I compile\r\n\r\n{{{#!hs\r\ntest :: (a -> a -> a) -> Int -> a -> HashMap Int a -> HashMap Int a\r\ntest f k a m = insertModifying a (blink (f a)) k m\r\n\r\nblink :: (a -> b) -> a -> (# b #)\r\n-- Or blink g = \\a -> (# g a #) ; it makes no difference.\r\nblink g a = (# g a #)\r\n}}}\r\n\r\nI get\r\n\r\n{{{\r\ntest\r\n = \\ (@ a_a9o3)\r\n (f_a7iP :: a_a9o3 -> a_a9o3 -> a_a9o3)\r\n (k_a7iQ :: Int)\r\n (a1_a7iR :: a_a9o3)\r\n (m_a7iS :: HashMap Int a_a9o3) ->\r\n case k_a7iQ of { GHC.Types.I# ww1_sa1Z ->\r\n RULES.$w$sinsertModifying\r\n @ a_a9o3\r\n a1_a7iR\r\n (let {\r\n g_s9E1 [Dmd=<L,C(U)>] :: a_a9o3 -> a_a9o3\r\n [LclId]\r\n g_s9E1 = f_a7iP a1_a7iR } in\r\n \\ (a2_a7iU :: a_a9o3) -> (# g_s9E1 a2_a7iU #))\r\n ww1_sa1Z\r\n m_a7iS\r\n }\r\n}}}\r\n\r\nWe build `g_s9E1 = f_a7iP a1_a7iR` for no apparent reason. Trouble persists into STG:\r\n\r\n{{{\r\nRULES.test\r\n :: forall a.\r\n (a -> a -> a)\r\n -> GHC.Types.Int\r\n -> a\r\n -> Data.HashMap.Base.HashMap GHC.Types.Int a\r\n -> Data.HashMap.Base.HashMap GHC.Types.Int a\r\n[GblId,\r\n Arity=4,\r\n Str=<L,1*C1(C(U))><S(S),1*U(U)><L,U><S,1*U>,\r\n Unf=OtherCon []] =\r\n [] \\r [f_saiX k_saiY a1_saiZ m_saj0]\r\n case k_saiY of {\r\n GHC.Types.I# ww1_saj2 [Occ=Once] ->\r\n let {\r\n g_saj3 [Occ=OnceL!, Dmd=<L,C(U)>] :: a_a9o3 -> a_a9o3\r\n [LclId] =\r\n [f_saiX a1_saiZ] \\u [] f_saiX a1_saiZ; } in\r\n let {\r\n sat_saj6 [Occ=Once] :: a_a9o3 -> (# a_a9o3 #)\r\n [LclId] =\r\n [g_saj3] \\r [a2_saj4]\r\n let {\r\n sat_saj5 [Occ=Once] :: a_a9o3\r\n [LclId] =\r\n [g_saj3 a2_saj4] \\u [] g_saj3 a2_saj4;\r\n } in Unit# [sat_saj5];\r\n } in RULES.$w$sinsertModifying a1_saiZ sat_saj6 ww1_saj2 m_saj0;\r\n };\r\n}}}\r\n\r\n`insertModifying` uses its function argument at most once, so there is no possible benefit to this partial application.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14817GHC 8.4.1 pretty-prints data family instances with redundant kind signatures ...2019-07-07T18:15:27ZRyan ScottGHC 8.4.1 pretty-prints data family instances with redundant kind signatures using -ddump-splicesConsider this program:
```hs
{-# LANGUAGE TemplateHaskell #-}
{-# LANGUAGE TypeFamilies #-}
{-# OPTIONS_GHC -ddump-splices #-}
module Bug where
$([d| data family Foo :: *
data instance Foo :: * |])
```
On GHC 8.2.2, this gives t...Consider this program:
```hs
{-# LANGUAGE TemplateHaskell #-}
{-# LANGUAGE TypeFamilies #-}
{-# OPTIONS_GHC -ddump-splices #-}
module Bug where
$([d| data family Foo :: *
data instance Foo :: * |])
```
On GHC 8.2.2, this gives the following `-ddump-splices` output:
```
$ /opt/ghc/8.2.2/bin/ghci Bug.hs
GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
[1 of 1] Compiling Bug ( Bug.hs, interpreted )
Bug.hs:(6,3)-(7,31): Splicing declarations
[d| data family Foo_a1sB :: *
data instance :: * |]
======>
data family Foo_a494 :: GHC.Types.Type
data instance :: GHC.Types.Type
```
But on GHC 8.4.1, we have:
```
$ /opt/ghc/8.4.1/bin/ghci Bug.hs
GHCi, version 8.4.0.20180209: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
[1 of 1] Compiling Bug ( Bug.hs, interpreted )
Bug.hs:(6,3)-(7,31): Splicing declarations
[d| data family Foo_a1xd :: *
data instance Foo_a1xd :: * :: * |]
======>
data family Foo_a487 :: GHC.Types.Type
data instance Foo_a487 :: GHC.Types.Type :: GHC.Types.Type
```
Notice how there is a redundant kind signature in `data instance Foo_a1xd :: * :: *`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.1-alpha3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | alanz |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC 8.4.1 pretty-prints data family instances with redundant kind signatures using -ddump-splices","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.1-alpha3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["alanz"],"type":"Bug","description":"Consider this program:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE TemplateHaskell #-}\r\n{-# LANGUAGE TypeFamilies #-}\r\n{-# OPTIONS_GHC -ddump-splices #-}\r\nmodule Bug where\r\n\r\n$([d| data family Foo :: *\r\n data instance Foo :: * |])\r\n}}}\r\n\r\nOn GHC 8.2.2, this gives the following `-ddump-splices` output:\r\n\r\n{{{\r\n$ /opt/ghc/8.2.2/bin/ghci Bug.hs\r\nGHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help\r\nLoaded GHCi configuration from /home/rgscott/.ghci\r\n[1 of 1] Compiling Bug ( Bug.hs, interpreted )\r\nBug.hs:(6,3)-(7,31): Splicing declarations\r\n [d| data family Foo_a1sB :: *\r\n \r\n data instance :: * |]\r\n ======>\r\n data family Foo_a494 :: GHC.Types.Type\r\n data instance :: GHC.Types.Type\r\n}}}\r\n\r\nBut on GHC 8.4.1, we have:\r\n\r\n{{{\r\n$ /opt/ghc/8.4.1/bin/ghci Bug.hs\r\nGHCi, version 8.4.0.20180209: http://www.haskell.org/ghc/ :? for help\r\nLoaded GHCi configuration from /home/rgscott/.ghci\r\n[1 of 1] Compiling Bug ( Bug.hs, interpreted )\r\nBug.hs:(6,3)-(7,31): Splicing declarations\r\n [d| data family Foo_a1xd :: *\r\n \r\n data instance Foo_a1xd :: * :: * |]\r\n ======>\r\n data family Foo_a487 :: GHC.Types.Type\r\n data instance Foo_a487 :: GHC.Types.Type :: GHC.Types.Type\r\n}}}\r\n\r\nNotice how there is a redundant kind signature in `data instance Foo_a1xd :: * :: *`.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/14818Provide highestOneBit function in Data.Bits module2019-07-07T18:15:27ZkostmoProvide highestOneBit function in Data.Bits moduleThis function yields the [largest power of 2 less than or equal to the given number](https://stackoverflow.com/a/17379704/105137).
Relative to the Java standard library, which [provides this function](https://docs.oracle.com/javase/7/do...This function yields the [largest power of 2 less than or equal to the given number](https://stackoverflow.com/a/17379704/105137).
Relative to the Java standard library, which [provides this function](https://docs.oracle.com/javase/7/docs/api/java/lang/Integer.html#highestOneBit(int)), there is a gap in the Haskell library, even though the Haskell docs [describe a method to calculate logBase2 via the \`countLeadingZeros\` function](https://hackage.haskell.org/package/base-4.10.1.0/docs/Data-Bits.html#v:countLeadingZeros).
From the Java documentation:
> The implementations of the "bit twiddling" methods (such as `highestOneBit` and `numberOfTrailingZeros`) are based on material from Henry S. Warren, Jr.'s ''Hacker's Delight'', (Addison Wesley, 2002).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Provide highestOneBit function in Data.Bits module","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"This function yields the [https://stackoverflow.com/a/17379704/105137 largest power of 2 less than or equal to the given number].\r\n\r\n\r\nRelative to the Java standard library, which [https://docs.oracle.com/javase/7/docs/api/java/lang/Integer.html#highestOneBit(int) provides this function], there is a gap in the Haskell library, even though the Haskell docs [https://hackage.haskell.org/package/base-4.10.1.0/docs/Data-Bits.html#v:countLeadingZeros describe a method to calculate logBase2 via the `countLeadingZeros` function].\r\n\r\nFrom the Java documentation:\r\n\r\n> The implementations of the \"bit twiddling\" methods (such as `highestOneBit` and `numberOfTrailingZeros`) are based on material from Henry S. Warren, Jr.'s ''Hacker's Delight'', (Addison Wesley, 2002).","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/14819GHC 8.2 does not accept British {-# LANGUAGE GeneralisedNewtypeDeriving #-} s...2019-07-07T18:15:26ZclintonGHC 8.2 does not accept British {-# LANGUAGE GeneralisedNewtypeDeriving #-} spellingThe GHC docs for GeneralisedNewtypeDeriving at (https://downloads.haskell.org/\~ghc/latest/docs/html/users_guide/glasgow_exts.html\#generalised-derived-instances-for-newtypes) suggest British spelling should be accepted, and indeed it's ...The GHC docs for GeneralisedNewtypeDeriving at (https://downloads.haskell.org/\~ghc/latest/docs/html/users_guide/glasgow_exts.html\#generalised-derived-instances-for-newtypes) suggest British spelling should be accepted, and indeed it's the preferred spelling in the docs. However GHC 8.2 throws an error. I haven't tested this against HEAD so if it's fixed there please feel free to close.
I know this is a bit picky but it's caught me out a few times and I couldn't see it previously reported (I may have missed it though).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | lowest |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC 8.2 does not accept British {-# LANGUAGE GeneralisedNewtypeDeriving #-} spelling","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The GHC docs for GeneralisedNewtypeDeriving at (https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#generalised-derived-instances-for-newtypes) suggest British spelling should be accepted, and indeed it's the preferred spelling in the docs. However GHC 8.2 throws an error. I haven't tested this against HEAD so if it's fixed there please feel free to close.\r\n\r\nI know this is a bit picky but it's caught me out a few times and I couldn't see it previously reported (I may have missed it though).","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/14820MultiFunctionalDependencies2019-07-07T18:15:26ZzaoqiMultiFunctionalDependencies<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2.2 |
| Type | FeatureRequest |
| TypeOfFailure ...<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"MultiFunctionalDependencies","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14821-O2 forces -optlo-O3 in a way that cannot be overridden at command line2019-07-07T18:15:26Zjoeyhess-O2 forces -optlo-O3 in a way that cannot be overridden at command lineI would expect -O2 -optlo-O2 to pass -O2 to the llvm optimiser. However, it seems that -O2 implies -optlo-O3, overriding the command-line's -optlo-O2.
The workaround seems to be to use -O1 -optlo-O2, but of course this misses some ghc o...I would expect -O2 -optlo-O2 to pass -O2 to the llvm optimiser. However, it seems that -O2 implies -optlo-O3, overriding the command-line's -optlo-O2.
The workaround seems to be to use -O1 -optlo-O2, but of course this misses some ghc optimizations.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------- |
| Version | 8.0.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (LLVM) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"-O2 forces -optlo-O3 in a way that cannot be overridden at command line","status":"New","operating_system":"","component":"Compiler (LLVM)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I would expect -O2 -optlo-O2 to pass -O2 to the llvm optimiser. However, it seems that -O2 implies -optlo-O3, overriding the command-line's -optlo-O2.\r\n\r\nThe workaround seems to be to use -O1 -optlo-O2, but of course this misses some ghc optimizations.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/14822-XQuantifiedConstraints: Turn term-level entailments (:-) into constraints (=>)2019-07-07T18:15:26ZIcelandjack-XQuantifiedConstraints: Turn term-level entailments (:-) into constraints (=>)This code works fine:
```hs
{-# Language TypeOperators, RankNTypes, KindSignatures, GADTs, DataKinds, MultiParamTypeClasses, FlexibleInstances, ConstraintKinds, ScopedTypeVariables #-}
import Data.Kind
-- 'constraints' machinery
data ...This code works fine:
```hs
{-# Language TypeOperators, RankNTypes, KindSignatures, GADTs, DataKinds, MultiParamTypeClasses, FlexibleInstances, ConstraintKinds, ScopedTypeVariables #-}
import Data.Kind
-- 'constraints' machinery
data Dict c where
Dict :: c => Dict c
newtype a :- b = Sub (a => Dict b) -- entailment
-- 'singletons' machinery
data SBool :: Bool -> Type where
SFalse :: SBool 'False
STrue :: SBool 'True
class SBoolI (bool::Bool) where sbool :: SBool bool
instance SBoolI 'False where sbool = SFalse
instance SBoolI 'True where sbool = STrue
-- VVV Example VVV
class Funny (b::Bool) (b'::Bool)
instance Funny 'False b'
instance Funny 'True 'True
instance Funny 'True 'False
proof :: forall b b'. (SBoolI b, SBoolI b') :- Funny b b'
proof = Sub (case (sbool :: SBool b, sbool :: SBool b') of
(SFalse, _) -> Dict
(STrue, SFalse) -> Dict
(STrue, STrue) -> Dict)
-- ^^^ Example ^^^
```
What I'm interested in is the entailment:
Singletons for `b` and `b'` entail `Funny b b'`. This is witnessed by `proof`.
Given that we have a branch for `-XQuantifiedConstraints`, it is tantalizing to convert this into an implication constraint `(SBoolI b, SBoolI b') => Funny b b'`.
Is such a thing sensible (wrt coherence) and if so is it at all possible to do this on WIPT2893?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"-XQuantifiedConstraints: Turn term-level entailments (:-) into constraints (=>)","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":["QuantifiedConstraints,","wipT2893"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This code works fine:\r\n\r\n{{{#!hs\r\n{-# Language TypeOperators, RankNTypes, KindSignatures, GADTs, DataKinds, MultiParamTypeClasses, FlexibleInstances, ConstraintKinds, ScopedTypeVariables #-}\r\n\r\nimport Data.Kind\r\n\r\n-- 'constraints' machinery\r\ndata Dict c where\r\n Dict :: c => Dict c\r\n\r\nnewtype a :- b = Sub (a => Dict b) -- entailment\r\n\r\n-- 'singletons' machinery\r\ndata SBool :: Bool -> Type where\r\n SFalse :: SBool 'False\r\n STrue :: SBool 'True\r\n\r\nclass SBoolI (bool::Bool) where sbool :: SBool bool\r\ninstance SBoolI 'False where sbool = SFalse\r\ninstance SBoolI 'True where sbool = STrue\r\n\r\n-- VVV Example VVV\r\nclass Funny (b::Bool) (b'::Bool)\r\ninstance Funny 'False b'\r\ninstance Funny 'True 'True\r\ninstance Funny 'True 'False\r\n\r\nproof :: forall b b'. (SBoolI b, SBoolI b') :- Funny b b'\r\nproof = Sub (case (sbool :: SBool b, sbool :: SBool b') of\r\n (SFalse, _) -> Dict\r\n (STrue, SFalse) -> Dict \r\n (STrue, STrue) -> Dict)\r\n-- ^^^ Example ^^^\r\n}}}\r\n\r\nWhat I'm interested in is the entailment: \r\n\r\nSingletons for `b` and `b'` entail `Funny b b'`. This is witnessed by `proof`.\r\n\r\nGiven that we have a branch for `-XQuantifiedConstraints`, it is tantalizing to convert this into an implication constraint `(SBoolI b, SBoolI b') => Funny b b'`.\r\n\r\nIs such a thing sensible (wrt coherence) and if so is it at all possible to do this on WIPT2893?","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14823Test profiling/should_run/scc001 fails on Circle CI2019-07-07T18:15:25ZmrkkrpTest profiling/should_run/scc001 fails on Circle CIThe test profiling/should_run/scc001 fails on CI:
```hs
module Main (main) where
main :: IO ()
main = do print $ f True
print $ g 3
print $ h 'a'
f :: a -> a
f x = x
g :: Int -> Int
g x = x
h :: Char -> Char
Just...The test profiling/should_run/scc001 fails on CI:
```hs
module Main (main) where
main :: IO ()
main = do print $ f True
print $ g 3
print $ h 'a'
f :: a -> a
f x = x
g :: Int -> Int
g x = x
h :: Char -> Char
Just h = Just id
```
And it outputs:
```
True
3
ghc-stage2: ghc-iserv terminated (-11)
```
instead of
```
True
3
'a'
```
I guess I'll mark it as an expected failure for now in my PR.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.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":"Test profiling/should_run/scc001 fails on Circle CI","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The test profiling/should_run/scc001 fails on CI:\r\n\r\n{{{#!hs\r\nmodule Main (main) where\r\n\r\nmain :: IO ()\r\nmain = do print $ f True\r\n print $ g 3\r\n print $ h 'a'\r\n\r\nf :: a -> a\r\nf x = x\r\n\r\ng :: Int -> Int\r\ng x = x\r\n\r\nh :: Char -> Char\r\nJust h = Just id\r\n}}}\r\n\r\nAnd it outputs:\r\n\r\n{{{\r\nTrue\r\n3\r\nghc-stage2: ghc-iserv terminated (-11)\r\n}}}\r\n\r\ninstead of\r\n\r\n{{{\r\nTrue\r\n3\r\n'a'\r\n}}}\r\n\r\nI guess I'll mark it as an expected failure for now in my PR.","type_of_failure":"OtherFailure","blocking":[]} -->8.10.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/14824automatically select instance2019-07-07T18:15:25Zzaoqiautomatically select instanceThere is
```hs
{-# LANGUAGE OverlappingInstances, MultiParamTypeClasses #-}
data X0 = X0 deriving Show
data X1 = X1 deriving Show
data X2 = X2 deriving Show
data X3 = X3 deriving Show
class C a b where m :: [a] -> b
instance C X0 X0 whe...There is
```hs
{-# LANGUAGE OverlappingInstances, MultiParamTypeClasses #-}
data X0 = X0 deriving Show
data X1 = X1 deriving Show
data X2 = X2 deriving Show
data X3 = X3 deriving Show
class C a b where m :: [a] -> b
instance C X0 X0 where m _ = X0
instance C X1 X2 where m _ = X2
instance C X0 X3 where m _ = X3
```
X0 X1 X2 X3 is 4 types in real program.
FunctionalDependencies can't work.
```
*Main> m [X1]
<interactive>:6:1: error:
• Ambiguous type variable ‘a0’ arising from a use of ‘print’
prevents the constraint ‘(Show a0)’ from being solved.
Probable fix: use a type annotation to specify what ‘a0’ should be.
These potential instances exist:
instance Show Ordering -- Defined in ‘GHC.Show’
instance Show Integer -- Defined in ‘GHC.Show’
instance [overlap ok] [safe] Show X0 -- Defined at a.hs:2:23
...plus 26 others
...plus 11 instances involving out-of-scope types
(use -fprint-potential-instances to see them all)
• In a stmt of an interactive GHCi command: print it
```https://gitlab.haskell.org/ghc/ghc/-/issues/14825Access violation on Windows is not propagated to the OS2019-07-07T18:15:25ZvarosiAccess violation on Windows is not propagated to the OSWe're using Haskell in production environment. Some times we get exceptions, like this:
"Access violation in generated code when reading 0000000000000000"
and nothing more. This is extremely hard and time consuming to debug where this e...We're using Haskell in production environment. Some times we get exceptions, like this:
"Access violation in generated code when reading 0000000000000000"
and nothing more. This is extremely hard and time consuming to debug where this exception came from. There is no information about at which address was the exception thrown.
The correct way on Windows is such exceptions to be propagated to the operating system. This way we will attach a debugger to the process and it'll get and visualize where the exception happened. Currently GHC runtime is catching the exception, skip its source information and present that uninformative message to the user.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Access violation on Windows is not propagated to the OS","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"We're using Haskell in production environment. Some times we get exceptions, like this:\r\n\"Access violation in generated code when reading 0000000000000000\"\r\n\r\nand nothing more. This is extremely hard and time consuming to debug where this exception came from. There is no information about at which address was the exception thrown. \r\nThe correct way on Windows is such exceptions to be propagated to the operating system. This way we will attach a debugger to the process and it'll get and visualize where the exception happened. Currently GHC runtime is catching the exception, skip its source information and present that uninformative message to the user. ","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14826Flatten data types extending other data types in STG2019-07-07T18:15:25ZJoachim Breitnermail@joachim-breitner.deFlatten data types extending other data types in STGThis idea was triggered by https://mail.haskell.org/pipermail/haskell-cafe/2018-February/128570.html although it does not solve that particular case. Hence I don’t know if there is any practical use for it, but I wanted to jot it down.
...This idea was triggered by https://mail.haskell.org/pipermail/haskell-cafe/2018-February/128570.html although it does not solve that particular case. Hence I don’t know if there is any practical use for it, but I wanted to jot it down.
Consider a data type
```
data Result = Ok !Foo | NotOK Error
```
where `Foo` is a concrete algebraic data type with $n$ constructors.
Then the following transformation should be safe:
- Do not generate an info table for `Ok`
- Give the `NotOK` the constructor number $n+1$.
- Replace calls to `Ok` with `id`
- Replace
`
case r as b of Of f -> E[b,f] | NotOk e -> E[b,e]
`
with
`
case r as b of DEFAULT -> E[b,b] | NotOk e -> E[b,e]
`
This effectively makes every constructor or `Foo` a constructor of `Ok`, and eliminates the pointer indirection introduced by `Foo`. Checking if a `Result` is `Ok` is now a simple check of the pointer tag (if `Foo` and `Result` do not have too many constructors).
Note that `Result` could have additional constructors, but only one can be eliminated. This one constructor needs to
- have one argument
- be strict in that argument
- that argument must be an algebraic data type (even after this flattening) does not have `NotOk` as a constructor.
We currently cannot do this in `Core`, but we could if our safe coercions were directed.
Do you think you have a case where this could give a performance boost? Maybe some parser library? You can try this now using pattern synonyms and `unsafeCoerce`. If you think there is something to be gained here, then we can consider implementing this.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.5 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Flatten data types extending other data types in STG","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"This idea was triggered by https://mail.haskell.org/pipermail/haskell-cafe/2018-February/128570.html although it does not solve that particular case. Hence I don’t know if there is any practical use for it, but I wanted to jot it down.\r\n\r\nConsider a data type\r\n{{{\r\ndata Result = Ok !Foo | NotOK Error\r\n}}}\r\nwhere `Foo` is a concrete algebraic data type with $n$ constructors.\r\n\r\nThen the following transformation should be safe:\r\n\r\n * Do not generate an info table for `Ok`\r\n * Give the `NotOK` the constructor number $n+1$.\r\n * Replace calls to `Ok` with `id`\r\n * Replace\r\n {{{\r\n case r as b of Of f -> E[b,f] | NotOk e -> E[b,e]\r\n }}}\r\n with\r\n {{{\r\n case r as b of DEFAULT -> E[b,b] | NotOk e -> E[b,e]\r\n }}}\r\n\r\nThis effectively makes every constructor or `Foo` a constructor of `Ok`, and eliminates the pointer indirection introduced by `Foo`. Checking if a `Result` is `Ok` is now a simple check of the pointer tag (if `Foo` and `Result` do not have too many constructors).\r\n\r\nNote that `Result` could have additional constructors, but only one can be eliminated. This one constructor needs to \r\n\r\n * have one argument\r\n * be strict in that argument\r\n * that argument must be an algebraic data type (even after this flattening) does not have `NotOk` as a constructor.\r\n\r\nWe currently cannot do this in `Core`, but we could if our safe coercions were directed.\r\n\r\n\r\nDo you think you have a case where this could give a performance boost? Maybe some parser library? You can try this now using pattern synonyms and `unsafeCoerce`. If you think there is something to be gained here, then we can consider implementing this.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14827Recognize when inlining would create a join point2019-07-07T18:15:25ZersetzenRecognize when inlining would create a join point[This discussion](https://www.reddit.com/r/haskell/comments/7yh8ar/i_wrote_a_program_that_runs_about_10_times_faster/) revolved around a program that runs 10x faster under ghci.
One way to solve this is to remove a superfluous inline pr...[This discussion](https://www.reddit.com/r/haskell/comments/7yh8ar/i_wrote_a_program_that_runs_about_10_times_faster/) revolved around a program that runs 10x faster under ghci.
One way to solve this is to remove a superfluous inline pragma which allows the following transformation to happen:
```
letrec {
f a = case e of {
p1 -> f a';
p2 -> (# l, r #);
}} in case f e2 of { (# l, r #) -> e3; }
```
into
```
joinrec {
f a = case e of {
p1 -> jump f a';
p2 -> e3;
}} in jump f e2
```
More generally a recursive let binding that is called exactly once from the outside. If all recursive calls are tail calls and the outside one isn't then we could safely replace the call with the binding and end up with join points. In this case it means a 10x speedup so it might be worth doing generally.
```
letrec { fi = ei; } in ... (fj e) ... => ... (joinrec { fi = ei; } in jump fj e) ...
```
[Self contained example](https://gist.github.com/AndreasPK/8e6f0cbf253f0930f4cda81e685ac136)https://gitlab.haskell.org/ghc/ghc/-/issues/14828panic! when using :print on some functions with class constraints?2021-01-12T00:18:35Zjolpanic! when using :print on some functions with class constraints?These are the problematic ones I've found:
```
> :t foldl
foldl :: Foldable t => (b -> a -> b) -> b -> t a -> b
> :print foldl
ghc: panic! (the 'impossible' happened)
(GHC version 8.2.2 for x86_64-unknown-linux):
isUnliftedType
t1_...These are the problematic ones I've found:
```
> :t foldl
foldl :: Foldable t => (b -> a -> b) -> b -> t a -> b
> :print foldl
ghc: panic! (the 'impossible' happened)
(GHC version 8.2.2 for x86_64-unknown-linux):
isUnliftedType
t1_a1H7[rt] :: TYPE t_a1H6[rt]
Call stack:
CallStack (from HasCallStack):
prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable
callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable
pprPanic, called at compiler/types/Type.hs:1952:10 in ghc:Type
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
> :t fmap
fmap :: Functor f => (a -> b) -> f a -> f b
> :print fmap
ghc: panic! (the 'impossible' happened)
(GHC version 8.2.2 for x86_64-unknown-linux):
isUnliftedType
t1_a1Hu[rt] :: TYPE t_a1Ht[rt]
Call stack:
CallStack (from HasCallStack):
prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable
callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable
pprPanic, called at compiler/types/Type.hs:1952:10 in ghc:Type
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
> :t return
return :: Monad m => a -> m a
> :print return
ghc: panic! (the 'impossible' happened)
(GHC version 8.2.2 for x86_64-unknown-linux):
isUnliftedType
t1_a1Wt[rt] :: TYPE t_a1Ws[rt]
Call stack:
CallStack (from HasCallStack):
prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable
callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable
pprPanic, called at compiler/types/Type.hs:1952:10 in ghc:Type
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
> :t pure
pure :: Applicative f => a -> f a
> :print pure
ghc: panic! (the 'impossible' happened)
(GHC version 8.2.2 for x86_64-unknown-linux):
isUnliftedType
t1_a1WP[rt] :: TYPE t_a1WO[rt]
Call stack:
CallStack (from HasCallStack):
prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable
callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable
pprPanic, called at compiler/types/Type.hs:1952:10 in ghc:Type
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
These that don't have constraints are fine:
```
> :print id
id = (_t1::a -> a)
> :print map
map = (_t2::(a1 -> b) -> [a1] -> [b])
> :print const
const = (_t3::a2 -> b1 -> a2)
```
This value and function created in the session are fine:
```
> let x :: Monad m => m (); x = return ()
Prelude|
> :p x
x = (_t5::Monad m1 => m1 ())
> let f :: Monad m => Int -> m Int; f n = return (n + 1)
Prelude|
> :p f
f = (_t6::Monad m2 => Int -> m2 Int)
```
mempty and mappend imported from Data.Monoid are fine:
```
> :m + Data.Monoid
> :p mempty
mempty = (_t7::Monoid a4 => a4)
> :p mappend
mappend = (_t8::Monoid a4 => a4 -> a4 -> a4)
```
foldl' and foldr imported from Data.List are not fine:
```
> :m + Data.List
> :p foldl'
ghc: panic! (the 'impossible' happened)
(GHC version 8.2.2 for x86_64-unknown-linux):
isUnliftedType
t1_a6Qy[rt] :: TYPE t_a6Qx[rt]
Call stack:
CallStack (from HasCallStack):
prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable
callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable
pprPanic, called at compiler/types/Type.hs:1952:10 in ghc:Type
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
> :p Data.List.foldr
ghc: panic! (the 'impossible' happened)
(GHC version 8.2.2 for x86_64-unknown-linux):
isUnliftedType
t2_a6RG[rt] :: TYPE t1_a6RF[rt]
Call stack:
CallStack (from HasCallStack):
prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable
callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable
pprPanic, called at compiler/types/Type.hs:1952:10 in ghc:Type
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
but `all` and `init` from that same module are fine:
```
> :p Data.List.all
all = (_t13::Foldable t1 => (a22 -> Bool) -> t1 a22 -> Bool)
> :p Data.List.init
init = (_t14::[a29] -> [a29])
```
So, in a given module, among functions with class constraints, some have the error and others don't. I haven't found a value that's not a function with the error, and I haven't found a function with no class constraints exhibit the error.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.2 |
| 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":"panic! when using :print on some functions with class constraints?","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"These are the problematic ones I've found:\r\n\r\n{{{\r\n> :t foldl\r\nfoldl :: Foldable t => (b -> a -> b) -> b -> t a -> b\r\n> :print foldl\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.2.2 for x86_64-unknown-linux):\r\n\tisUnliftedType\r\n t1_a1H7[rt] :: TYPE t_a1H6[rt]\r\n Call stack:\r\n CallStack (from HasCallStack):\r\n prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable\r\n callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable\r\n pprPanic, called at compiler/types/Type.hs:1952:10 in ghc:Type\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n> :t fmap\r\nfmap :: Functor f => (a -> b) -> f a -> f b\r\n> :print fmap\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.2.2 for x86_64-unknown-linux):\r\n\tisUnliftedType\r\n t1_a1Hu[rt] :: TYPE t_a1Ht[rt]\r\n Call stack:\r\n CallStack (from HasCallStack):\r\n prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable\r\n callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable\r\n pprPanic, called at compiler/types/Type.hs:1952:10 in ghc:Type\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n> :t return\r\nreturn :: Monad m => a -> m a\r\n> :print return\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.2.2 for x86_64-unknown-linux):\r\n\tisUnliftedType\r\n t1_a1Wt[rt] :: TYPE t_a1Ws[rt]\r\n Call stack:\r\n CallStack (from HasCallStack):\r\n prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable\r\n callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable\r\n pprPanic, called at compiler/types/Type.hs:1952:10 in ghc:Type\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n> :t pure\r\npure :: Applicative f => a -> f a\r\n> :print pure\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.2.2 for x86_64-unknown-linux):\r\n\tisUnliftedType\r\n t1_a1WP[rt] :: TYPE t_a1WO[rt]\r\n Call stack:\r\n CallStack (from HasCallStack):\r\n prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable\r\n callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable\r\n pprPanic, called at compiler/types/Type.hs:1952:10 in ghc:Type\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n}}}\r\n\r\nThese that don't have constraints are fine:\r\n\r\n{{{\r\n> :print id\r\nid = (_t1::a -> a)\r\n> :print map\r\nmap = (_t2::(a1 -> b) -> [a1] -> [b])\r\n> :print const\r\nconst = (_t3::a2 -> b1 -> a2)\r\n}}}\r\n\r\nThis value and function created in the session are fine:\r\n\r\n{{{\r\n> let x :: Monad m => m (); x = return ()\r\nPrelude| \r\n> :p x\r\nx = (_t5::Monad m1 => m1 ())\r\n> let f :: Monad m => Int -> m Int; f n = return (n + 1)\r\nPrelude| \r\n> :p f\r\nf = (_t6::Monad m2 => Int -> m2 Int)\r\n}}}\r\n\r\nmempty and mappend imported from Data.Monoid are fine:\r\n\r\n{{{\r\n> :m + Data.Monoid\r\n> :p mempty\r\nmempty = (_t7::Monoid a4 => a4)\r\n> :p mappend\r\nmappend = (_t8::Monoid a4 => a4 -> a4 -> a4)\r\n}}}\r\n\r\nfoldl' and foldr imported from Data.List are not fine:\r\n\r\n{{{\r\n> :m + Data.List\r\n> :p foldl'\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.2.2 for x86_64-unknown-linux):\r\n\tisUnliftedType\r\n t1_a6Qy[rt] :: TYPE t_a6Qx[rt]\r\n Call stack:\r\n CallStack (from HasCallStack):\r\n prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable\r\n callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable\r\n pprPanic, called at compiler/types/Type.hs:1952:10 in ghc:Type\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n> :p Data.List.foldr\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.2.2 for x86_64-unknown-linux):\r\n\tisUnliftedType\r\n t2_a6RG[rt] :: TYPE t1_a6RF[rt]\r\n Call stack:\r\n CallStack (from HasCallStack):\r\n prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable\r\n callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable\r\n pprPanic, called at compiler/types/Type.hs:1952:10 in ghc:Type\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n}}}\r\n\r\nbut `all` and `init` from that same module are fine:\r\n\r\n{{{\r\n> :p Data.List.all\r\nall = (_t13::Foldable t1 => (a22 -> Bool) -> t1 a22 -> Bool)\r\n> :p Data.List.init\r\ninit = (_t14::[a29] -> [a29])\r\n}}}\r\n\r\nSo, in a given module, among functions with class constraints, some have the error and others don't. I haven't found a value that's not a function with the error, and I haven't found a function with no class constraints exhibit the error.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14829Linking error with ANN pragma2023-02-08T19:40:44ZehubinetteLinking error with ANN pragmaThere seems to be an issue with the ANN pragma, with fatal compilation errors.
To reproduce, setup two modules as such:
```hs
module Test where
import Weights (Weight(..))
{-# ANN mainTest (Weight 2) #-}
mainTest :: IO ()
mainTest = ...There seems to be an issue with the ANN pragma, with fatal compilation errors.
To reproduce, setup two modules as such:
```hs
module Test where
import Weights (Weight(..))
{-# ANN mainTest (Weight 2) #-}
mainTest :: IO ()
mainTest = return ()
```
```hs
{-# LANGUAGE DeriveDataTypeable #-}
module Weights (Weight(..)) where
import Data.Data (Data(..))
newtype Weight = Weight Integer deriving Data
```
Compiling with GHC version `8.2.2` yields:
```
λ ghc Test.hs
[1 of 2] Compiling Weights ( Weights.hs, Weights.o )
[2 of 2] Compiling Test ( Test.hs, Test.o )
Test.hs:5:1: fatal:
cannot find object file ‘./Weights.dyn_o’
while linking an interpreted expression
```
The issue disappears with `-dynamic` or `-dynamic-too`:
```
λ ghc -dynamic Test.hs
[1 of 2] Compiling Weights ( Weights.hs, Weights.o )
[2 of 2] Compiling Test ( Test.hs, Test.o )
```
Issue persist in HEAD, GHC version `8.5.20180219`, but again disappears with `-dynamic-too` *or* `-dynamic`:
```
λ ../../ghc/inplace/bin/ghc-stage2 -dynamic-too Test.hs
[1 of 2] Compiling Weights ( Weights.hs, Weights.o )
[2 of 2] Compiling Test ( Test.hs, Test.o )
```
Remove the ANN pragma, and the compiler behaves just fine with both GHC versions. Please tell me if I can provide more information. Cheers.https://gitlab.haskell.org/ghc/ghc/-/issues/14830Use test instead of cmp for comparison against zero.2019-07-07T18:15:24ZAndreas KlebingerUse test instead of cmp for comparison against zero.For comparisons `test r, r` and `cmp r, $0` are interchangeable at least on x86.
However using test leads to slightly smaller code. (Saves a byte per comparison).
A good starting point is stmtToInstrs in compiler/nativeGen/X86/CodeGen ...For comparisons `test r, r` and `cmp r, $0` are interchangeable at least on x86.
However using test leads to slightly smaller code. (Saves a byte per comparison).
A good starting point is stmtToInstrs in compiler/nativeGen/X86/CodeGen starting with how CmmCondBranch is compiled to Instructions.
From there it should be not too hard to track down the required changes.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Compiler (NCG) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Use test instead of cmp for comparison against zero.","status":"New","operating_system":"","component":"Compiler (NCG)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"For comparisons `test r, r` and `cmp r, $0` are interchangeable at least on x86.\r\n\r\nHowever using test leads to slightly smaller code. (Saves a byte per comparison).\r\n\r\nA good starting point is stmtToInstrs in compiler/nativeGen/X86/CodeGen starting with how CmmCondBranch is compiled to Instructions. \r\n\r\nFrom there it should be not too hard to track down the required changes.\r\n\r\n\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14831QuantifiedConstraints: Odd superclass constraint2019-07-07T18:15:24ZIcelandjackQuantifiedConstraints: Odd superclass constraintThis code works
```hs
{-# Language QuantifiedConstraints, RankNTypes, PolyKinds, ConstraintKinds, UndecidableInstances #-}
import Data.Semigroup
newtype Free cls a = Free ()
instance (forall xx. cls xx => Semigroup xx) => Semigroup (...This code works
```hs
{-# Language QuantifiedConstraints, RankNTypes, PolyKinds, ConstraintKinds, UndecidableInstances #-}
import Data.Semigroup
newtype Free cls a = Free ()
instance (forall xx. cls xx => Semigroup xx) => Semigroup (Free cls a) where
(<>) = undefined
stimes = undefined
sconcat = undefined
-- instance (forall xx. cls xx => Semigroup xx) => Monoid (Free cls a) where
-- mempty = undefined
```
but uncomment the `Monoid` instance and we get
```
$ ghci -ignore-dot-ghci /tmp/I.hs
GHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling Main ( /tmp/I.hs, interpreted )
/tmp/I.hs:12:10: error:
• Could not deduce: cls (Free cls a)
arising from the superclasses of an instance declaration
from the context: forall xx. cls xx => Semigroup xx
bound by the instance declaration at /tmp/I.hs:12:10-67
• In the instance declaration for ‘Monoid (Free cls a)’
|
12 | instance (forall xx. cls xx => Semigroup xx) => Monoid (Free cls a) where
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Failed, no modules loaded.
Prelude>
```
Is this correct behavior?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"QuantifiedConstraints: Odd superclass constraint","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":["QuantifiedConstraints","wipT2893"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This code works\r\n\r\n{{{#!hs\r\n{-# Language QuantifiedConstraints, RankNTypes, PolyKinds, ConstraintKinds, UndecidableInstances #-}\r\n\r\nimport Data.Semigroup\r\n\r\nnewtype Free cls a = Free ()\r\n\r\ninstance (forall xx. cls xx => Semigroup xx) => Semigroup (Free cls a) where\r\n (<>) = undefined \r\n stimes = undefined\r\n sconcat = undefined\r\n\r\n-- instance (forall xx. cls xx => Semigroup xx) => Monoid (Free cls a) where\r\n-- mempty = undefined \r\n}}}\r\n\r\nbut uncomment the `Monoid` instance and we get\r\n\r\n{{{\r\n$ ghci -ignore-dot-ghci /tmp/I.hs\r\nGHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help\r\n[1 of 1] Compiling Main ( /tmp/I.hs, interpreted )\r\n\r\n/tmp/I.hs:12:10: error:\r\n • Could not deduce: cls (Free cls a)\r\n arising from the superclasses of an instance declaration\r\n from the context: forall xx. cls xx => Semigroup xx\r\n bound by the instance declaration at /tmp/I.hs:12:10-67\r\n • In the instance declaration for ‘Monoid (Free cls a)’\r\n |\r\n12 | instance (forall xx. cls xx => Semigroup xx) => Monoid (Free cls a) where\r\n | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\r\nFailed, no modules loaded.\r\nPrelude> \r\n}}}\r\n\r\nIs this correct behavior?","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14832QuantifiedConstraints: Adding to the context causes failure2023-07-11T20:35:15ZIcelandjackQuantifiedConstraints: Adding to the context causes failureWith Simon's latest changes (ticket:14733\##14832) this works:
```hs
{-# Language QuantifiedConstraints, RankNTypes, PolyKinds, ConstraintKinds, UndecidableInstances, GADTs #-}
import Control.Category
import Data.Kind
import Data.Coerc...With Simon's latest changes (ticket:14733\##14832) this works:
```hs
{-# Language QuantifiedConstraints, RankNTypes, PolyKinds, ConstraintKinds, UndecidableInstances, GADTs #-}
import Control.Category
import Data.Kind
import Data.Coerce
data With cls a b where
With :: cls a b => With cls a b
type Coercion = With Coercible
type Refl rel = (forall xx. rel xx xx :: Constraint)
type Trans rel = (forall xx yy zz. (rel xx yy, rel yy zz) => rel xx zz :: Constraint)
instance Refl rel => Category (With rel) where
id = With
(.) = undefined
```
But strengthening the context with `Trans rel`:
```hs
instance (Refl rel, Trans rel) => Category (With rel) where
```
causes it to fail
```
GHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling Main ( J.hs, interpreted )
J.hs:15:10: error:
• Could not deduce: rel xx zz
from the context: (Refl rel, Trans rel)
bound by an instance declaration:
forall k (rel :: k -> k -> Constraint).
(Refl rel, Trans rel) =>
Category (With rel)
at J.hs:15:10-53
or from: (rel xx yy, rel yy zz)
bound by a quantified context at J.hs:15:10-53
• In the ambiguity check for an instance declaration
To defer the ambiguity check to use sites, enable AllowAmbiguousTypes
In the instance declaration for ‘Category (With rel)’
|
15 | instance (Refl rel, Trans rel) => Category (With rel) where
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
J.hs:15:10: error:
• Could not deduce: rel xx xx
from the context: (Refl rel, Trans rel)
bound by an instance declaration:
forall k (rel :: k -> k -> Constraint).
(Refl rel, Trans rel) =>
Category (With rel)
at J.hs:15:10-53
• In the ambiguity check for an instance declaration
To defer the ambiguity check to use sites, enable AllowAmbiguousTypes
In the instance declaration for ‘Category (With rel)’
|
15 | instance (Refl rel, Trans rel) => Category (With rel) where
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Failed, no modules loaded.
Prelude>
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"QuantifiedConstraints: Strengthening context causes failure","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":["QuantifiedConstraints","wipT2893"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"With Simon's latest changes (ticket:14733#comment:9) this works:\r\n\r\n{{{#!hs\r\n{-# Language QuantifiedConstraints, RankNTypes, PolyKinds, ConstraintKinds, UndecidableInstances, GADTs #-}\r\n\r\nimport Control.Category\r\nimport Data.Kind\r\nimport Data.Coerce\r\n\r\ndata With cls a b where\r\n With :: cls a b => With cls a b\r\n\r\ntype Coercion = With Coercible\r\n\r\ntype Refl rel = (forall xx. rel xx xx :: Constraint)\r\ntype Trans rel = (forall xx yy zz. (rel xx yy, rel yy zz) => rel xx zz :: Constraint)\r\n\r\ninstance Refl rel => Category (With rel) where\r\n id = With\r\n (.) = undefined\r\n}}}\r\n\r\nBut strengthening the context with `Trans rel`:\r\n\r\n{{{#!hs\r\ninstance (Refl rel, Trans rel) => Category (With rel) where\r\n}}}\r\n\r\ncauses it to fail\r\n\r\n{{{\r\nGHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help\r\n[1 of 1] Compiling Main ( J.hs, interpreted )\r\n\r\nJ.hs:15:10: error:\r\n • Could not deduce: rel xx zz\r\n from the context: (Refl rel, Trans rel)\r\n bound by an instance declaration:\r\n forall k (rel :: k -> k -> Constraint).\r\n (Refl rel, Trans rel) =>\r\n Category (With rel)\r\n at J.hs:15:10-53\r\n or from: (rel xx yy, rel yy zz)\r\n bound by a quantified context at J.hs:15:10-53\r\n • In the ambiguity check for an instance declaration\r\n To defer the ambiguity check to use sites, enable AllowAmbiguousTypes\r\n In the instance declaration for ‘Category (With rel)’\r\n |\r\n15 | instance (Refl rel, Trans rel) => Category (With rel) where\r\n | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\r\n\r\nJ.hs:15:10: error:\r\n • Could not deduce: rel xx xx\r\n from the context: (Refl rel, Trans rel)\r\n bound by an instance declaration:\r\n forall k (rel :: k -> k -> Constraint).\r\n (Refl rel, Trans rel) =>\r\n Category (With rel)\r\n at J.hs:15:10-53\r\n • In the ambiguity check for an instance declaration\r\n To defer the ambiguity check to use sites, enable AllowAmbiguousTypes\r\n In the instance declaration for ‘Category (With rel)’\r\n |\r\n15 | instance (Refl rel, Trans rel) => Category (With rel) where\r\n | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\r\nFailed, no modules loaded.\r\nPrelude> \r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14833QuantifiedConstraints: GHC can't deduce (() :: Constraint)?2019-07-07T18:15:24ZIcelandjackQuantifiedConstraints: GHC can't deduce (() :: Constraint)?```hs
{-# Language QuantifiedConstraints, RankNTypes, PolyKinds, ConstraintKinds, UndecidableInstances, GADTs #-}
import Data.Kind
data Dict c where
Dict :: c => Dict c
class (a => b) => Implies a b
instance (a => b) => Implies a...```hs
{-# Language QuantifiedConstraints, RankNTypes, PolyKinds, ConstraintKinds, UndecidableInstances, GADTs #-}
import Data.Kind
data Dict c where
Dict :: c => Dict c
class (a => b) => Implies a b
instance (a => b) => Implies a b
type a :- b = Dict (Implies a b)
iota :: (Implies () a) :- a
iota = Dict
```
GHC claims that it can't deduce `(() :: Constraint)` :)
```
GHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling Main ( /tmp/H.hs, interpreted )
/tmp/H.hs:14:8: error:
• Could not deduce () :: Constraint arising from a use of ‘Dict’
from the context: Implies () :: Constraint a
bound by a quantified context at /tmp/H.hs:1:1
Possible fix:
add () :: Constraint to the context of
the type signature for:
iota :: forall (a :: Constraint). Implies () :: Constraint a :- a
• In the expression: Dict
In an equation for ‘iota’: iota = Dict
|
14 | iota = Dict
| ^^^^
Failed, no modules loaded.
Prelude>
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"QuantifiedConstraints: GHC can't deduce (() :: Constraint)?","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":["QuantifiedConstraints","wipT2893"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{#!hs\r\n{-# Language QuantifiedConstraints, RankNTypes, PolyKinds, ConstraintKinds, UndecidableInstances, GADTs #-}\r\n\r\nimport Data.Kind\r\n\r\ndata Dict c where\r\n Dict :: c => Dict c\r\n\r\nclass (a => b) => Implies a b\r\ninstance (a => b) => Implies a b\r\n\r\ntype a :- b = Dict (Implies a b)\r\n\r\niota :: (Implies () a) :- a\r\niota = Dict\r\n}}}\r\n\r\nGHC claims that it can't deduce `(() :: Constraint)` :)\r\n\r\n{{{\r\nGHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help\r\n[1 of 1] Compiling Main ( /tmp/H.hs, interpreted )\r\n\r\n/tmp/H.hs:14:8: error:\r\n • Could not deduce () :: Constraint arising from a use of ‘Dict’\r\n from the context: Implies () :: Constraint a\r\n bound by a quantified context at /tmp/H.hs:1:1\r\n Possible fix:\r\n add () :: Constraint to the context of\r\n the type signature for:\r\n iota :: forall (a :: Constraint). Implies () :: Constraint a :- a\r\n • In the expression: Dict\r\n In an equation for ‘iota’: iota = Dict\r\n |\r\n14 | iota = Dict\r\n | ^^^^\r\nFailed, no modules loaded.\r\nPrelude> \r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14834Executable have problems with DWARF debug information2019-07-07T18:15:23ZvarosiExecutable have problems with DWARF debug informationWe're compiling production code with GHC 8.2.2 under Windows 10 (i.e. Mingw64).
A crash occured during one of our FFI bindings and we wanted to use latest GHC debugging functionallity to find the problem faster.
We used a tool cv2pdb to ...We're compiling production code with GHC 8.2.2 under Windows 10 (i.e. Mingw64).
A crash occured during one of our FFI bindings and we wanted to use latest GHC debugging functionallity to find the problem faster.
We used a tool cv2pdb to convert DWARF information into PDB, but we hit a crash with the tool - [https://github.com/rainers/cv2pdb/issues/23](https://github.com/rainers/cv2pdb/issues/23)
In response, the tool author brought us back a output of a problem in objdump tool over our executable:
```
c:\tmp\cv\crash>C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe -W crash.exe >objdump
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section
C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: There is a hole [0x682a - 0x6867] in .debug_loc section.
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------------- |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Debugging) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Executable have problems with DWARF debug information","status":"New","operating_system":"","component":"Compiler (Debugging)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"We're compiling production code with GHC 8.2.2 under Windows 10 (i.e. Mingw64). \r\nA crash occured during one of our FFI bindings and we wanted to use latest GHC debugging functionallity to find the problem faster. \r\nWe used a tool cv2pdb to convert DWARF information into PDB, but we hit a crash with the tool - [https://github.com/rainers/cv2pdb/issues/23]\r\nIn response, the tool author brought us back a output of a problem in objdump tool over our executable:\r\n\r\n{{{\r\nc:\\tmp\\cv\\crash>C:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe -W crash.exe >objdump\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section\r\nC:\\l\\d\\GDC-2.068\\bin\\x86_64-unknown-linux-gnu-objdump.exe: Warning: There is a hole [0x682a - 0x6867] in .debug_loc section.\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14835QuantifiedConstraints: Can't deduce "(a, b)" from "a" and "b"2019-07-07T18:15:23ZIcelandjackQuantifiedConstraints: Can't deduce "(a, b)" from "a" and "b"```hs
{-# Language QuantifiedConstraints, RankNTypes, PolyKinds, ConstraintKinds, UndecidableInstances, GADTs, LiberalTypeSynonyms, TypeOperators, MultiParamTypeClasses, FlexibleInstances #-}
data Dict c where
Dict :: c => Dict c
inf...```hs
{-# Language QuantifiedConstraints, RankNTypes, PolyKinds, ConstraintKinds, UndecidableInstances, GADTs, LiberalTypeSynonyms, TypeOperators, MultiParamTypeClasses, FlexibleInstances #-}
data Dict c where
Dict :: c => Dict c
infixr |-
class (a => b) => (a |- b)
instance (a => b) => (a |- b)
type a :- b = Dict (a |- b)
class ((a, b) => c) => Curried a b c
instance ((a, b) => c) => Curried a b c
curryC :: forall a b c. ((a, b) |- c) :- (a |- b |- c)
curryC = Dict
```
This fails with
```
GHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling Main ( /tmp/Test.hs, interpreted )
/tmp/Test.hs:16:10: error:
• Could not deduce (a, b) arising from a use of ‘Dict’
from the context: (a, b) |- c
bound by a quantified context at /tmp/Test.hs:1:1
or from: a bound by a quantified context at /tmp/Test.hs:1:1
or from: b bound by a quantified context at /tmp/Test.hs:1:1
Possible fix:
add (a, b) to the context of
the type signature for:
curryC :: forall (a :: Constraint) (b :: Constraint) (c :: Constraint).
((a, b) |- c) :- (a |- (b |- c))
• In the expression: Dict
In an equation for ‘curryC’: curryC = Dict
|
16 | curryC = Dict
| ^^^^
Failed, no modules loaded.
```
but it works by changing the type of `curryC`:
```hs
curryC :: forall a b c. Curried a b c :- (a |- b |- c)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"QuantifiedConstraints: Can't deduce \"(a, b)\" from \"a\" and \"b\"","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":["QuantifiedConstraints","wipT2893"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{#!hs\r\n{-# Language QuantifiedConstraints, RankNTypes, PolyKinds, ConstraintKinds, UndecidableInstances, GADTs, LiberalTypeSynonyms, TypeOperators, MultiParamTypeClasses, FlexibleInstances #-}\r\n\r\ndata Dict c where\r\n Dict :: c => Dict c\r\n\r\ninfixr |-\r\nclass (a => b) => (a |- b)\r\ninstance (a => b) => (a |- b)\r\n\r\ntype a :- b = Dict (a |- b)\r\n\r\nclass ((a, b) => c) => Curried a b c\r\ninstance ((a, b) => c) => Curried a b c\r\n\r\ncurryC :: forall a b c. ((a, b) |- c) :- (a |- b |- c)\r\ncurryC = Dict\r\n}}}\r\n\r\nThis fails with\r\n\r\n{{{\r\nGHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help\r\n[1 of 1] Compiling Main ( /tmp/Test.hs, interpreted )\r\n\r\n/tmp/Test.hs:16:10: error:\r\n • Could not deduce (a, b) arising from a use of ‘Dict’\r\n from the context: (a, b) |- c\r\n bound by a quantified context at /tmp/Test.hs:1:1\r\n or from: a bound by a quantified context at /tmp/Test.hs:1:1\r\n or from: b bound by a quantified context at /tmp/Test.hs:1:1\r\n Possible fix:\r\n add (a, b) to the context of\r\n the type signature for:\r\n curryC :: forall (a :: Constraint) (b :: Constraint) (c :: Constraint).\r\n ((a, b) |- c) :- (a |- (b |- c))\r\n • In the expression: Dict\r\n In an equation for ‘curryC’: curryC = Dict\r\n |\r\n16 | curryC = Dict\r\n | ^^^^\r\nFailed, no modules loaded.\r\n}}}\r\n\r\nbut it works by changing the type of `curryC`:\r\n\r\n{{{#!hs\r\ncurryC :: forall a b c. Curried a b c :- (a |- b |- c)\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14836GHC fails to infer implied superclass constraint2019-07-07T18:15:23ZEric CrockettGHC fails to infer implied superclass constraintThe following code should compile, but does not.
```
{-# LANGUAGE FlexibleInstances, UndecidableInstances #-}
module Bug where
class (Monad m) => RequiresMonad m where
class (Monad m) => ImpliesMonad m where
instance (ImpliesMonad m...The following code should compile, but does not.
```
{-# LANGUAGE FlexibleInstances, UndecidableInstances #-}
module Bug where
class (Monad m) => RequiresMonad m where
class (Monad m) => ImpliesMonad m where
instance (ImpliesMonad m) => RequiresMonad m where
```
The basic idea is that I put the constraint `ImpliesMonad m` on the `RequiresMonad` instance, which does in fact imply `Monad m`. However, GHC complains:
```
• Could not deduce (Monad m)
arising from the superclasses of an instance declaration
from the context: ImpliesMonad m
bound by the instance declaration
at Bug.hs:9:10-44
Possible fix:
add (Monad m) to the context of the instance declaration
• In the instance declaration for ‘RequiresMonad m’
```
Of course, GHC is perfectly happy if I replace the instance constraint `ImpliesMonad m` with `Monad m`.
Possibly related to #10338 or #11948.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.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 fails to infer implied superclass constraint","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following code should compile, but does not.\r\n{{{\r\n{-# LANGUAGE FlexibleInstances, UndecidableInstances #-}\r\n\r\nmodule Bug where\r\n\r\nclass (Monad m) => RequiresMonad m where\r\n\r\nclass (Monad m) => ImpliesMonad m where\r\n\r\ninstance (ImpliesMonad m) => RequiresMonad m where\r\n}}}\r\n\r\nThe basic idea is that I put the constraint `ImpliesMonad m` on the `RequiresMonad` instance, which does in fact imply `Monad m`. However, GHC complains:\r\n{{{\r\n • Could not deduce (Monad m)\r\n arising from the superclasses of an instance declaration\r\n from the context: ImpliesMonad m\r\n bound by the instance declaration\r\n at Bug.hs:9:10-44\r\n Possible fix:\r\n add (Monad m) to the context of the instance declaration\r\n • In the instance declaration for ‘RequiresMonad m’\r\n}}}\r\n\r\nOf course, GHC is perfectly happy if I replace the instance constraint `ImpliesMonad m` with `Monad m`.\r\n\r\nPossibly related to #10338 or #11948.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14837Semigroup and Monoid instances for ST2019-07-07T18:15:23ZAndrew MartinSemigroup and Monoid instances for STIn `base-4.9`, a `Monoid` instance for `IO` was introduced. I would like to propose adding a similar instance for `ST`. This should be even less controversial since there is only one meaningful `Monoid` instance for `ST` (it lacks the ex...In `base-4.9`, a `Monoid` instance for `IO` was introduced. I would like to propose adding a similar instance for `ST`. This should be even less controversial since there is only one meaningful `Monoid` instance for `ST` (it lacks the exception-catching facilities of `IO`). The behavior of the `Semigroup` and `Monoid` instances would need to match this:
```
instance Monoid a => Monoid (ST s a) where
mappend = liftA2 mappend
mempty = pure mempty
```
This would let me use `fold` and `foldMap` over `ST` computations, which would occasionally be useful.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Semigroup and Monoid instances for ST","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":["base"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"In `base-4.9`, a `Monoid` instance for `IO` was introduced. I would like to propose adding a similar instance for `ST`. This should be even less controversial since there is only one meaningful `Monoid` instance for `ST` (it lacks the exception-catching facilities of `IO`). The behavior of the `Semigroup` and `Monoid` instances would need to match this:\r\n\r\n{{{\r\ninstance Monoid a => Monoid (ST s a) where\r\n mappend = liftA2 mappend\r\n mempty = pure mempty\r\n}}}\r\n\r\nThis would let me use `fold` and `foldMap` over `ST` computations, which would occasionally be useful.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14838missing "incomplete-patterns" warning for TH-generated functions2021-04-20T07:14:10Zgelisammissing "incomplete-patterns" warning for TH-generated functions"incomplete-patterns" warnings are generated for TH-generated case expressions, but not for TH-generated functions, so the behaviour is inconsistent.
For example:
```hs
{-# LANGUAGE TemplateHaskell #-}
module Lib where
import Language...."incomplete-patterns" warnings are generated for TH-generated case expressions, but not for TH-generated functions, so the behaviour is inconsistent.
For example:
```hs
{-# LANGUAGE TemplateHaskell #-}
module Lib where
import Language.Haskell.TH
qIncompleteCase :: Q [Dec]
qIncompleteCase = [d|
incompleteCase :: Bool -> ()
incompleteCase b = case b of
True -> () |]
qIncompleteFunction :: Q [Dec]
qIncompleteFunction =[d|
incompleteFunction :: Bool -> ()
incompleteFunction True = () |]
```
```hs
{-# LANGUAGE TemplateHaskell #-}
module Bug where
import Lib
$qIncompleteCase
$qIncompleteFunction
incompleteCase' :: Bool -> ()
incompleteCase' b = case b of
True -> ()
incompleteFunction' :: Bool -> ()
incompleteFunction' True = ()
```
When compiling the above two files with `-Wall`, GHC 8.2.2 produces an "incomplete-patterns" warning for `qIncompleteCase`, `incompleteCase'`, and `incompleteFunction'`, but not for `qIncompleteFunction`. I would prefer to get a warning for `qIncompleteFunction` as well.
My use case is the [surjective](https://hackage.haskell.org/package/surjective) package, in which I intentionally generate code which produces warnings in order to warn the user about corresponding issues in their code. I could generate [better error messages](https://github.com/gelisam/surjective/blob/master/src/Surjective.hs#L158-L162) if GHC generated warnings for TH-generated functions as well.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 8.2.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":"missing \"incomplete-patterns\" warning for TH-generated functions","status":"New","operating_system":"","component":"Template Haskell","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"\"incomplete-patterns\" warnings are generated for TH-generated case expressions, but not for TH-generated functions, so the behaviour is inconsistent.\r\n\r\nFor example:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE TemplateHaskell #-}\r\nmodule Lib where\r\nimport Language.Haskell.TH\r\n\r\nqIncompleteCase :: Q [Dec]\r\nqIncompleteCase = [d|\r\n incompleteCase :: Bool -> ()\r\n incompleteCase b = case b of\r\n True -> () |]\r\n\r\nqIncompleteFunction :: Q [Dec]\r\nqIncompleteFunction =[d|\r\n incompleteFunction :: Bool -> ()\r\n incompleteFunction True = () |]\r\n}}}\r\n\r\n{{{#!hs\r\n{-# LANGUAGE TemplateHaskell #-}\r\nmodule Bug where\r\nimport Lib\r\n\r\n$qIncompleteCase\r\n\r\n$qIncompleteFunction\r\n\r\nincompleteCase' :: Bool -> ()\r\nincompleteCase' b = case b of\r\n True -> ()\r\n\r\nincompleteFunction' :: Bool -> ()\r\nincompleteFunction' True = ()\r\n}}}\r\n\r\nWhen compiling the above two files with `-Wall`, GHC 8.2.2 produces an \"incomplete-patterns\" warning for `qIncompleteCase`, `incompleteCase'`, and `incompleteFunction'`, but not for `qIncompleteFunction`. I would prefer to get a warning for `qIncompleteFunction` as well.\r\n\r\nMy use case is the [https://hackage.haskell.org/package/surjective surjective] package, in which I intentionally generate code which produces warnings in order to warn the user about corresponding issues in their code. I could generate [https://github.com/gelisam/surjective/blob/master/src/Surjective.hs#L158-L162 better error messages] if GHC generated warnings for TH-generated functions as well.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14839Bits typeclass law for LSB2020-01-23T19:26:36ZAndrew MartinBits typeclass law for LSBThe documentation for the `Bits` typeclass claims:
> Bits are numbered from 0 with bit 0 being the least significant bit.
However, there's no law specified in the typeclass that enforces this. I realized this recently because I've been...The documentation for the `Bits` typeclass claims:
> Bits are numbered from 0 with bit 0 being the least significant bit.
However, there's no law specified in the typeclass that enforces this. I realized this recently because I've been adding the laws for `Bits` to a library of property tests I maintain: http://hackage.haskell.org/package/quickcheck-classes-0.3.3/docs/Test-QuickCheck-Classes.html\#v:bitsLaws
In another package of mine, someone requested to add a `Bits` instance for a type but with the MSB considered bit 0. (https://github.com/andrewthad/haskell-ip/issues/29) I thought this would fail to satisfy a law of `Bits`, but it doesn't. So at the least, I was thinking we could add the following laws to `FiniteBits`:
```
countTrailingZeros (bit 0) = 0
countLeadingZeros (bit 0) = finiteBitSize undefined - 1
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.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":"Bits typeclass law for LSB","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":["base"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The documentation for the `Bits` typeclass claims:\r\n\r\n> Bits are numbered from 0 with bit 0 being the least significant bit.\r\n\r\nHowever, there's no law specified in the typeclass that enforces this. I realized this recently because I've been adding the laws for `Bits` to a library of property tests I maintain: http://hackage.haskell.org/package/quickcheck-classes-0.3.3/docs/Test-QuickCheck-Classes.html#v:bitsLaws\r\n\r\nIn another package of mine, someone requested to add a `Bits` instance for a type but with the MSB considered bit 0. (https://github.com/andrewthad/haskell-ip/issues/29) I thought this would fail to satisfy a law of `Bits`, but it doesn't. So at the least, I was thinking we could add the following laws to `FiniteBits`:\r\n\r\n{{{\r\ncountTrailingZeros (bit 0) = 0\r\ncountLeadingZeros (bit 0) = finiteBitSize undefined - 1\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14840QuantifiedConstraints: Can't define class alias2019-07-07T18:15:22ZIcelandjackQuantifiedConstraints: Can't define class alias```hs
{-# Language TypeInType, MultiParamTypeClasses, TypeFamilies, FlexibleContexts, FunctionalDependencies, AllowAmbiguousTypes, QuantifiedConstraints, GADTs, ConstraintKinds, KindSignatures, RankNTypes, FlexibleInstances, UndecidableI...```hs
{-# Language TypeInType, MultiParamTypeClasses, TypeFamilies, FlexibleContexts, FunctionalDependencies, AllowAmbiguousTypes, QuantifiedConstraints, GADTs, ConstraintKinds, KindSignatures, RankNTypes, FlexibleInstances, UndecidableInstances, TypeOperators #-}
import Data.Kind
class Reifies s a | s -> a where
reflect :: proxy s -> a
newtype Lift :: forall k. (Type -> Constraint) -> Type -> k -> Type where
Lift :: a -> Lift cls a s
data family Def :: (k -> Constraint) -> (k -> Type)
class (forall s a. Reifies s (Def cls a) => cls (Lift cls a s)) => ReifiableConstraint cls
instance (forall s a. Reifies s (Def cls a) => cls (Lift cls a s)) => ReifiableConstraint cls
```
gives an error
```
$ ghci -ignore-dot-ghci Bug.hs
GHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling Main ( /tmp/Bug.hs, interpreted )
/tmp/Bug.hs:14:10: error:
• Could not deduce: cls (Lift cls a s)
arising from the superclasses of an instance declaration
from the context: forall (s :: k) a.
Reifies s (Def cls a) =>
cls (Lift cls a s)
bound by the instance declaration at /tmp/Bug.hs:14:10-93
or from: Reifies s (Def cls a)
bound by a quantified context at /tmp/Bug.hs:1:1
• In the instance declaration for ‘ReifiableConstraint cls’
|
14 | instance (forall s a. Reifies s (Def cls a) => cls (Lift cls a s)) => ReifiableConstraint cls
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Failed, no modules loaded.
Prelude>
```
This is a rare occasion that the class alias trick fails for me so \~+\~yay\~+\~. But is it intended?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"QuantifiedConstraints: Can't define class alias","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":["QuantifiedConstraints","wipT2893"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{#!hs\r\n{-# Language TypeInType, MultiParamTypeClasses, TypeFamilies, FlexibleContexts, FunctionalDependencies, AllowAmbiguousTypes, QuantifiedConstraints, GADTs, ConstraintKinds, KindSignatures, RankNTypes, FlexibleInstances, UndecidableInstances, TypeOperators #-}\r\n\r\nimport Data.Kind\r\n\r\nclass Reifies s a | s -> a where\r\n reflect :: proxy s -> a\r\n\r\nnewtype Lift :: forall k. (Type -> Constraint) -> Type -> k -> Type where\r\n Lift :: a -> Lift cls a s\r\n\r\ndata family Def :: (k -> Constraint) -> (k -> Type)\r\n\r\nclass (forall s a. Reifies s (Def cls a) => cls (Lift cls a s)) => ReifiableConstraint cls\r\ninstance (forall s a. Reifies s (Def cls a) => cls (Lift cls a s)) => ReifiableConstraint cls\r\n}}}\r\n\r\ngives an error\r\n\r\n{{{\r\n$ ghci -ignore-dot-ghci Bug.hs\r\nGHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help\r\n[1 of 1] Compiling Main ( /tmp/Bug.hs, interpreted )\r\n\r\n/tmp/Bug.hs:14:10: error:\r\n • Could not deduce: cls (Lift cls a s)\r\n arising from the superclasses of an instance declaration\r\n from the context: forall (s :: k) a.\r\n Reifies s (Def cls a) =>\r\n cls (Lift cls a s)\r\n bound by the instance declaration at /tmp/Bug.hs:14:10-93\r\n or from: Reifies s (Def cls a)\r\n bound by a quantified context at /tmp/Bug.hs:1:1\r\n • In the instance declaration for ‘ReifiableConstraint cls’\r\n |\r\n14 | instance (forall s a. Reifies s (Def cls a) => cls (Lift cls a s)) => ReifiableConstraint cls\r\n | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\r\nFailed, no modules loaded.\r\nPrelude> \r\n}}}\r\n\r\nThis is a rare occasion that the class alias trick fails for me so ~+~yay~+~. But is it intended?","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14841Inconsistent allocation stats2019-07-07T18:15:22ZpatrickdocInconsistent allocation statsI'm looking at Criterion internals, and seeing an inconsistency in the allocations reported by `GCStats` and `RTSStats`. Here is a small reproduction:
```hs
{-# LANGUAGE CPP #-}
module Main where
import GHC.Stats
import System.Mem (per...I'm looking at Criterion internals, and seeing an inconsistency in the allocations reported by `GCStats` and `RTSStats`. Here is a small reproduction:
```hs
{-# LANGUAGE CPP #-}
module Main where
import GHC.Stats
import System.Mem (performGC)
main :: IO ()
main = do
runOldThing 1000
#if __GLASGOW_HASKELL__ >= 802
putStrLn "Running new:"
runThing 1000
#endif
runOldThing :: Int -> IO ()
runOldThing n = loop n 0 >> return ()
where
loop 0 _ = return 0
loop count x = do
performGC
stats <- getGCStats
putStrLn $ show (count `mod` 15) ++ ": " ++ show (bytesAllocated stats - x) ++ " num: " ++ show (numGcs stats)
loop (count-1) (bytesAllocated stats)
#if __GLASGOW_HASKELL__ >= 802
runThing :: Int -> IO ()
runThing = loop
where
loop 0 = return ()
loop n = do
performGC
stats <- getRTSStats
putStrLn $ show (n `mod` 15) ++ ": " ++ show (gcdetails_allocated_bytes (gc stats)) ++ " num: " ++ show (gcs stats)
loop (n-1)
#endif
```
This code just performs a garbage collection and then prints the stats in a loop. Here is a snippet of the output.
```
...
4: 8840 num: 1967
3: 4880 num: 1968
2: 4880 num: 1969
1: 4880 num: 1970
0: 4880 num: 1971
14: 4880 num: 1972
13: 4976 num: 1973
12: 4976 num: 1974
11: 4976 num: 1975
10: 4976 num: 1976
9: 4976 num: 1977
8: 4880 num: 1978
7: 4880 num: 1979
6: 4880 num: 1980
5: 4880 num: 1981
4: 8840 num: 1982
3: 4880 num: 1983
2: 4880 num: 1984
1: 4880 num: 1985
0: 4880 num: 1986
14: 4880 num: 1987
13: 4976 num: 1988
12: 4976 num: 1989
11: 4976 num: 1990
10: 4976 num: 1991
9: 4976 num: 1992
8: 4880 num: 1993
7: 4880 num: 1994
6: 4880 num: 1995
5: 4880 num: 1996
4: 8840 num: 1997
3: 4880 num: 1998
2: 4880 num: 1999
1: 4880 num: 2000
```
On the left, I've included the gc number `mod` 15 to show that exactly every 15 gcs, there is an extra 4k bytes reported. This output was made with 8.2.1.
On 7.8.4, 7.10.3, and 8.0.2 it's every 23. And on 8.4.0.20180204 it's every 14.
I've played around with extra allocations between garbage collections, but the interval remained constant. I tried poking around the rts, but I've been unable to determine if this is a bug or just unavoidable noise.https://gitlab.haskell.org/ghc/ghc/-/issues/14842Layout extensions missing from documentation2022-01-22T03:16:42ZNiklas Hambüchenmail@nh2.meLayout extensions missing from documentationPicking up this issue from
https://mail.haskell.org/pipermail/ghc-devs/2018-February/015373.html
> seems like none of the extensions that alter or relax layout are documented currently. (AlternativeLayoutRule, AlternativeLayoutRuleTran...Picking up this issue from
https://mail.haskell.org/pipermail/ghc-devs/2018-February/015373.html
> seems like none of the extensions that alter or relax layout are documented currently. (AlternativeLayoutRule, AlternativeLayoutRuleTransitional, DoAndIfThenElse, NondecreasingIndentation, RelaxedLayout)https://gitlab.haskell.org/ghc/ghc/-/issues/14843Can't splice a partially applied PromoteTupleT type from Template Haskell2019-07-07T18:15:22ZRyan ScottCan't splice a partially applied PromoteTupleT type from Template Haskell```hs
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE TemplateHaskell #-}
module Bug where
import Language.Haskell.TH.Syntax
type T1 = $(return (PromotedTupleT 2))
type T2 = $([t| '(,) |])
type T3 = $(return (PromotedT (tupleDataName 2)))
```
...```hs
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE TemplateHaskell #-}
module Bug where
import Language.Haskell.TH.Syntax
type T1 = $(return (PromotedTupleT 2))
type T2 = $([t| '(,) |])
type T3 = $(return (PromotedT (tupleDataName 2)))
```
The splices for `T2` and `T3` both work. However, the splice for `T1` causes Template Haskell to have a conniption:
```
$ /opt/ghc/8.2.2/bin/ghci Bug.hs
GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
[1 of 1] Compiling Bug ( Bug.hs, interpreted )
Bug.hs:7:13: error:
• Malformed type PromotedTupleT 2
When splicing a TH type: '(,)
• In the untyped splice: $(return (PromotedTupleT 2))
|
7 | type T1 = $(return (PromotedTupleT 2))
| ^^^^^^^^^^^^^^^^^^^^^^^^^
```
Patch incoming.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 8.2.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":"Can't splice a partially applied PromoteTupleT type from Template Haskell","status":"New","operating_system":"","component":"Template Haskell","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{#!hs\r\n{-# LANGUAGE DataKinds #-}\r\n{-# LANGUAGE TemplateHaskell #-}\r\nmodule Bug where\r\n\r\nimport Language.Haskell.TH.Syntax\r\n\r\ntype T1 = $(return (PromotedTupleT 2))\r\ntype T2 = $([t| '(,) |])\r\ntype T3 = $(return (PromotedT (tupleDataName 2)))\r\n}}}\r\n\r\nThe splices for `T2` and `T3` both work. However, the splice for `T1` causes Template Haskell to have a conniption:\r\n\r\n{{{\r\n$ /opt/ghc/8.2.2/bin/ghci Bug.hs\r\nGHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help\r\nLoaded GHCi configuration from /home/rgscott/.ghci\r\n[1 of 1] Compiling Bug ( Bug.hs, interpreted )\r\n\r\nBug.hs:7:13: error:\r\n • Malformed type PromotedTupleT 2\r\n When splicing a TH type: '(,)\r\n • In the untyped splice: $(return (PromotedTupleT 2))\r\n |\r\n7 | type T1 = $(return (PromotedTupleT 2))\r\n | ^^^^^^^^^^^^^^^^^^^^^^^^^\r\n}}}\r\n\r\nPatch incoming.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/14844SpecConstr also non-recursive top-level functions2022-10-17T16:48:21ZJoachim Breitnermail@joachim-breitner.deSpecConstr also non-recursive top-level functionsIn order to fix the regressions introduced by loopification (#14068), we probably need to get !SpecConstr also do something about non-recursive functions.
In a first iteration, we might want to enable it for non-recursive functions stra...In order to fix the regressions introduced by loopification (#14068), we probably need to get !SpecConstr also do something about non-recursive functions.
In a first iteration, we might want to enable it for non-recursive functions straight-away, and see if it fixes the regressions introduced by Loopification.
But if this turns out to be too slow/too expensive, we should try specializing non-recursive *local* functions *if there is only one call-patterns*. That ought to be a straight win in all cases anyways.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.5 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"SpecConstr also non-recursive function","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"In order to fix the regressions introduced by loopification (#14068), we probably need to get !SpecConstr also do something about non-recursive functions.\r\n\r\nIn a first iteration, we might want to enable it for non-recursive functions straight-away, and see if it fixes the regressions introduced by Loopification.\r\n\r\nBut if this turns out to be too slow/too expensive, we should try specializing non-recursive ''local'' functions ''if there is only one call-patterns''. That ought to be a straight win in all cases anyways.\r\n\r\n\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14845TypeInType, index GADT by constraint witness2019-07-07T18:15:21ZIcelandjackTypeInType, index GADT by constraint witnessJust wondering if it would ever make sense to allow or use constraints like this
```hs
{-# Language PolyKinds, DataKinds, KindSignatures, GADTs, TypeInType, ConstraintKinds #-}
import Data.Kind
data Struct :: (k -> Constraint) -> (k -...Just wondering if it would ever make sense to allow or use constraints like this
```hs
{-# Language PolyKinds, DataKinds, KindSignatures, GADTs, TypeInType, ConstraintKinds #-}
import Data.Kind
data Struct :: (k -> Constraint) -> (k -> Type) where
S :: cls a => Struct cls a
data Foo a where
F :: Foo (S::Struct Eq a)
```
```
$ ghci -ignore-dot-ghci /tmp/test.hs
GHCi, version 8.5.20180105: http://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling Main ( /tmp/test.hs, interpreted )
/tmp/test.hs:9:13: error:
• Illegal constraint in a type: cls0 a0
• In the first argument of ‘Foo’, namely ‘(S :: Struct Eq a)’
In the type ‘Foo (S :: Struct Eq a)’
In the definition of data constructor ‘F’
|
9 | F :: Foo (S::Struct Eq a)
| ^
Failed, no modules loaded.
Prelude>
```
Please close the ticket if it doesn't
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.5 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"TypeInType, index by GADT witnessing constraint","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":["TypeInType"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Just wondering if it would ever make sense to allow or use constraints like this\r\n\r\n{{{#!hs\r\n{-# Language PolyKinds, DataKinds, KindSignatures, GADTs, TypeInType, ConstraintKinds #-}\r\n\r\nimport Data.Kind\r\n\r\ndata Struct :: (k -> Constraint) -> (k -> Type) where\r\n S :: cls a => Struct cls a\r\n\r\ndata Foo a where\r\n F :: Foo (S::Struct Eq a)\r\n}}}\r\n\r\n{{{\r\n$ ghci -ignore-dot-ghci /tmp/test.hs\r\nGHCi, version 8.5.20180105: http://www.haskell.org/ghc/ :? for help\r\n[1 of 1] Compiling Main ( /tmp/test.hs, interpreted )\r\n\r\n/tmp/test.hs:9:13: error:\r\n • Illegal constraint in a type: cls0 a0\r\n • In the first argument of ‘Foo’, namely ‘(S :: Struct Eq a)’\r\n In the type ‘Foo (S :: Struct Eq a)’\r\n In the definition of data constructor ‘F’\r\n |\r\n9 | F :: Foo (S::Struct Eq a)\r\n | ^\r\nFailed, no modules loaded.\r\nPrelude> \r\n}}}\r\n\r\nPlease close the ticket if it doesn't","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/14846Renamer hangs (because of -XInstanceSigs?)2019-07-07T18:15:20ZIcelandjackRenamer hangs (because of -XInstanceSigs?)```hs
{-# Language RankNTypes, TypeInType, EmptyCase, GADTs, FlexibleInstances, ConstraintKinds, UndecidableInstances, AllowAmbiguousTypes, InstanceSigs, ScopedTypeVariables #-}
import Data.Kind
import Data.Proxy
type Cat ob = ob -> ob...```hs
{-# Language RankNTypes, TypeInType, EmptyCase, GADTs, FlexibleInstances, ConstraintKinds, UndecidableInstances, AllowAmbiguousTypes, InstanceSigs, ScopedTypeVariables #-}
import Data.Kind
import Data.Proxy
type Cat ob = ob -> ob -> Type
data Struct :: (k -> Constraint) -> Type where
S :: Proxy (a::k) -> Struct (cls::k -> Constraint)
type Structured a cls = (S ('Proxy :: Proxy a)::Struct cls)
data AStruct :: Struct cls -> Type where
AStruct :: cls a => AStruct (Structured a cls)
class StructI (structured::Struct (cls :: k -> Constraint)) where
struct :: AStruct structured
instance (Structured xx cls ~ structured, cls xx) => StructI structured where
struct :: AStruct (Structured xx cls)
struct = AStruct
data Hom :: Cat k -> Cat (Struct cls) where
class Category (cat::Cat ob) where
i :: StructI a => ríki a a
instance Category ríki => Category (Hom ríki :: Cat (Struct cls)) where
-- Commenting out this instance signature makes the issue go away
i :: forall a. StructI a => Hom ríki a a
i = case struct :: AStruct (Structured a cls) of
```
Running on 8.2.1 and 8.5.20180105 both loop until interrupted
```
$ ghci -ignore-dot-ghci 199.hs
GHCi, version 8.5.20180105: http://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling Main ( 199.hs, interpreted )
^CInterrupted.
>
>
```8.4.2Richard Eisenbergrae@richarde.devRichard Eisenbergrae@richarde.devhttps://gitlab.haskell.org/ghc/ghc/-/issues/14847Inferring dependent kinds for non-recursive types2019-07-07T18:15:20ZSimon Peyton JonesInferring dependent kinds for non-recursive typesConsider this
```
data Proxy k (a :: k) = MkProxy
data Proxy2 k a = MkP (Proxy k a)
```
which is discussed in [a corner of the user manual](http://downloads.haskell.org/~ghc/master/users-guide/glasgow_exts.html#inferring-dependency-in-...Consider this
```
data Proxy k (a :: k) = MkProxy
data Proxy2 k a = MkP (Proxy k a)
```
which is discussed in [a corner of the user manual](http://downloads.haskell.org/~ghc/master/users-guide/glasgow_exts.html#inferring-dependency-in-datatype-declarations).
Surprisingly, we reject `Proxy2` -- but there is nothing difficult about inferring its kind. There would be if it was recursive -- but it isn't.
Simple solution: for non-recursive type declarations (we do SCC analysis so we know which these are) do not call `getInitialKinds`; instead, just infer the kind of the definition! Simple.
Warning: is this recursive?
```
data Proxy2 k a where
MkP :: Proxy k a -> Proxy2 k a
```
Presumably no more than the other definition. But currently we need `Proxy2` in the environment during kind inference, because we kind-check the result type. That seems jolly odd and inconsistent. Needs more thought.
Similar questions for
```
data T a where
T :: Int -> T Bool
type family F a where
F Int = True
F _ = False
```
See also:
- #14451
- #12088
- #9427https://gitlab.haskell.org/ghc/ghc/-/issues/14848-XDuplicateRecordFields breaks record expression splices2023-03-30T13:28:39Zdailectic-XDuplicateRecordFields breaks record expression splices```
{-# language TemplateHaskell #-}
{-# language DuplicateRecordFields #-}
module Lib where
import Language.Haskell.TH
import Language.Haskell.TH.Syntax
data A = A {x :: Int, y :: String}
a = A 3 "test"
test = $([e|case a of A {x = b} ...```
{-# language TemplateHaskell #-}
{-# language DuplicateRecordFields #-}
module Lib where
import Language.Haskell.TH
import Language.Haskell.TH.Syntax
data A = A {x :: Int, y :: String}
a = A 3 "test"
test = $([e|case a of A {x = b} -> b|])
```
Without `DuplicateRecordFields` it compiles correctly so `test = 3` but with `DuplicateRecordFields` enabled it gives:
```
• Illegal variable name: ‘$sel:x:A’
When splicing a TH expression:
case Lib.a of
(Lib.A {Lib.$sel:x:A = b_0}) -> b_0
• In the untyped splice: $([| case a of { A {x = b} -> b } |])
```
Additionally, there doesn't seem to be a workaround for munging the name manually, since the `$sel:x:A` name is the one actually in scope, there is no `A.x` like there would be normally, even when the label is not a duplicate.
Is there a way to get around this? Ex: by changing the binding name somehow manually?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.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":"-XDuplicateRecordFields breaks record expression splices","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"\r\n{{{\r\n{-# language TemplateHaskell #-}\r\n{-# language DuplicateRecordFields #-}\r\nmodule Lib where\r\nimport Language.Haskell.TH\r\nimport Language.Haskell.TH.Syntax\r\n\r\ndata A = A {x :: Int, y :: String}\r\na = A 3 \"test\"\r\ntest = $([e|case a of A {x = b} -> b|])\r\n}}}\r\n\r\nWithout `DuplicateRecordFields` it compiles correctly so `test = 3` but with `DuplicateRecordFields` enabled it gives:\r\n\r\n{{{\r\n • Illegal variable name: ‘$sel:x:A’\r\n When splicing a TH expression:\r\n case Lib.a of\r\n (Lib.A {Lib.$sel:x:A = b_0}) -> b_0\r\n • In the untyped splice: $([| case a of { A {x = b} -> b } |])\r\n}}}\r\n\r\nAdditionally, there doesn't seem to be a workaround for munging the name manually, since the `$sel:x:A` name is the one actually in scope, there is no `A.x` like there would be normally, even when the label is not a duplicate.\r\n\r\nIs there a way to get around this? Ex: by changing the binding name somehow manually?\r\n","type_of_failure":"OtherFailure","blocking":[]} -->sheafsam.derbyshire@gmail.comsheafsam.derbyshire@gmail.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/14849Add Applicative, Semigroup and Monoid instances in GHC.Generics2019-07-07T18:15:20ZlyxiaAdd Applicative, Semigroup and Monoid instances in GHC.GenericsSee https://mail.haskell.org/pipermail/libraries/2018-February/028562.html
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2...See https://mail.haskell.org/pipermail/libraries/2018-February/028562.html
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2.2 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add Applicative, Semigroup and Monoid instances in GHC.Generics","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"See https://mail.haskell.org/pipermail/libraries/2018-February/028562.html","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1lyxialyxiahttps://gitlab.haskell.org/ghc/ghc/-/issues/14850mallocBytes allows underflow2019-07-07T18:15:19ZwyagermallocBytes allows underflowhttps://hackage.haskell.org/package/base-4.10.1.0/docs/src/Foreign.Marshal.Alloc.html\#mallocBytes
This function doesn't complain when passed a negative number. Instead you get something like
`*** Exception: malloc: resource exhausted ...https://hackage.haskell.org/package/base-4.10.1.0/docs/src/Foreign.Marshal.Alloc.html\#mallocBytes
This function doesn't complain when passed a negative number. Instead you get something like
`*** Exception: malloc: resource exhausted (out of memory)`
Which is confusing, and probably not consistent across platforms.
This came up in https://github.com/tel/saltine/issues/42
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.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":"mallocBytes allows underflow","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"https://hackage.haskell.org/package/base-4.10.1.0/docs/src/Foreign.Marshal.Alloc.html#mallocBytes\r\n\r\nThis function doesn't complain when passed a negative number. Instead you get something like\r\n\r\n`*** Exception: malloc: resource exhausted (out of memory)`\r\n\r\nWhich is confusing, and probably not consistent across platforms.\r\n\r\nThis came up in https://github.com/tel/saltine/issues/42\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14851"Pattern match has inaccessible right hand side" with TypeRep2019-09-17T15:41:28ZRichard Eisenbergrae@richarde.dev"Pattern match has inaccessible right hand side" with TypeRepWhen I say
```hs
{-# LANGUAGE PatternSynonyms, ViewPatterns #-}
module Bug where
import Type.Reflection
pattern X arg <- (checkFun -> arg)
checkFun :: TypeRep fun -> a
checkFun = undefined
f x = case (x, True) of
(X _, _)...When I say
```hs
{-# LANGUAGE PatternSynonyms, ViewPatterns #-}
module Bug where
import Type.Reflection
pattern X arg <- (checkFun -> arg)
checkFun :: TypeRep fun -> a
checkFun = undefined
f x = case (x, True) of
(X _, _) -> 5
_ -> 6
g x = case x of
(X _) -> 5
_ -> 6
```
I get
```
Bug.hs:13:11: warning: [-Woverlapping-patterns]
Pattern match has inaccessible right hand side
In a case alternative: (X _, _) -> ...
|
13 | (X _, _) -> 5
| ^^^^^^^^^^^^^
```
I'm troubled by two things:
1. There's nothing inaccessible about my right-hand side.
1. This happens only for `f`, not `g`. If there's no tuple, there's no problem.
Note that this problems requires `TypeRep`. Even another polykinded tycon (like `Proxy`) didn't trigger the problem.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"\"Pattern match has inaccessible right hand side\" with TypeRep","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When I say\r\n\r\n{{{#!hs\r\n{-# LANGUAGE PatternSynonyms, ViewPatterns #-}\r\n\r\nmodule Bug where\r\n\r\nimport Type.Reflection\r\n\r\npattern X arg <- (checkFun -> arg)\r\n\r\ncheckFun :: TypeRep fun -> a\r\ncheckFun = undefined\r\n\r\nf x = case (x, True) of\r\n (X _, _) -> 5\r\n _ -> 6\r\n\r\ng x = case x of\r\n (X _) -> 5\r\n _ -> 6\r\n}}}\r\n\r\nI get\r\n\r\n{{{\r\nBug.hs:13:11: warning: [-Woverlapping-patterns]\r\n Pattern match has inaccessible right hand side\r\n In a case alternative: (X _, _) -> ...\r\n |\r\n13 | (X _, _) -> 5\r\n | ^^^^^^^^^^^^^\r\n}}}\r\n\r\nI'm troubled by two things:\r\n\r\n1. There's nothing inaccessible about my right-hand side.\r\n2. This happens only for `f`, not `g`. If there's no tuple, there's no problem.\r\n\r\nNote that this problems requires `TypeRep`. Even another polykinded tycon (like `Proxy`) didn't trigger the problem.","type_of_failure":"OtherFailure","blocking":[]} -->Sebastian GrafSebastian Grafhttps://gitlab.haskell.org/ghc/ghc/-/issues/14852Implement the "Eq1, Ord1, Read1, Show1 instances in GHC.Generics" proposal2019-07-07T18:15:19ZlyxiaImplement the "Eq1, Ord1, Read1, Show1 instances in GHC.Generics" proposalhttps://mail.haskell.org/pipermail/libraries/2018-February/028570.html
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2.2 ...https://mail.haskell.org/pipermail/libraries/2018-February/028570.html
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2.2 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Implement the \"Eq1, Ord1, Read1, Show1 instances in GHC.Generics\" proposal","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"https://mail.haskell.org/pipermail/libraries/2018-February/028570.html","type_of_failure":"OtherFailure","blocking":[]} -->lyxialyxiahttps://gitlab.haskell.org/ghc/ghc/-/issues/14853Implement the "Semigroup and Monoid instances in Data.Functor.Product and fri...2019-07-07T18:15:19ZlyxiaImplement the "Semigroup and Monoid instances in Data.Functor.Product and friends" proposalhttps://mail.haskell.org/pipermail/libraries/2018-February/028570.html
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2.2 ...https://mail.haskell.org/pipermail/libraries/2018-February/028570.html
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2.2 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Implement the \"Semigroup and Monoid instances in Data.Functor.Product and friends\" proposal","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"https://mail.haskell.org/pipermail/libraries/2018-February/028570.html","type_of_failure":"OtherFailure","blocking":[]} -->lyxialyxiahttps://gitlab.haskell.org/ghc/ghc/-/issues/14854The size of FastString table is suboptimal for large codebases2020-11-10T00:01:37ZniteriaThe size of FastString table is suboptimal for large codebasesContext:
I was profiling a no-op rebuild (build once, do incremental build with nothing changed) of a large code base. It takes `35.829s`, and according to the profile about `20%` of the time is spent in `mkFastStringByteString`.
I run ...Context:
I was profiling a no-op rebuild (build once, do incremental build with nothing changed) of a large code base. It takes `35.829s`, and according to the profile about `20%` of the time is spent in `mkFastStringByteString`.
I run it with `-dfaststring-stats +RTS -s` and got:
```
FastString stats:
size: 4091
entries: 829959
longest chain: 268
has z-encoding: 0%
50,011,906,640 bytes allocated in the heap
7,936,277,664 bytes copied during GC
3,106,526,336 bytes maximum residency (8 sample(s))
123,108,224 bytes maximum slop
10169 MB total memory in use (0 MB lost due to fragmentation)
Tot time (elapsed) Avg pause Max pause
Gen 0 117 colls, 37 par 32.390s 2.293s 0.0196s 0.0911s
Gen 1 8 colls, 3 par 19.722s 2.266s 0.2832s 0.6936s
Parallel GC work balance: 60.62% (serial 0%, perfect 100%)
TASKS: 93 (1 bound, 92 peak workers (92 total), using -N30)
SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled)
INIT time 0.009s ( 0.009s elapsed)
MUT time 277.370s ( 31.261s elapsed)
GC time 52.113s ( 4.558s elapsed)
EXIT time 0.005s ( 0.001s elapsed)
Total time 329.497s ( 35.829s elapsed)
Alloc rate 180,307,295 bytes per MUT second
Productivity 84.2% of total user, 87.3% of total elapsed
```
That's pretty bad, fitting `800k` elements in `4k` buckets is hard.
To confirm this indeed could be improved I changed the size to `2^20` (`1048576`) and also removed division in `hashStr` function (it come up on `perf` profile), like this:
```
hashStr :: Ptr Word8 -> Int -> Int
-- use the Addr to produce a hash value between 0 & m (inclusive)
hashStr (Ptr a#) (I# len#) = loop 0# 0#
where
loop h n | isTrue# (n ==# len#) = I# h
| otherwise = loop h2 (n +# 1#)
where !c = ord# (indexCharOffAddr# a# n)
-- !h2 = (c +# (h *# 128#)) `remInt#`
-- hASH_TBL_SIZE#
-- NOTE: below is multiplication by 127 (a prime) and division by 2^20, it's by no means the best hashing function
!h2 = (c +# ((h `uncheckedIShiftL#` 7#) -# h)) `andI#` hASH_TBL_SIZE_MASK#
```
Here's what I ended up with:
```
FastString stats:
size: 1048576
entries: 829959
longest chain: 8
has z-encoding: 0%
51,012,218,048 bytes allocated in the heap
8,948,377,768 bytes copied during GC
3,543,797,248 bytes maximum residency (8 sample(s))
139,428,352 bytes maximum slop
10502 MB total memory in use (0 MB lost due to fragmentation)
Tot time (elapsed) Avg pause Max pause
Gen 0 115 colls, 39 par 32.261s 2.677s 0.0233s 0.2225s
Gen 1 8 colls, 3 par 21.786s 2.329s 0.2911s 0.5737s
Parallel GC work balance: 48.75% (serial 0%, perfect 100%)
TASKS: 93 (1 bound, 92 peak workers (92 total), using -N30)
SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled)
INIT time 0.008s ( 0.008s elapsed)
MUT time 65.508s ( 23.791s elapsed)
GC time 54.047s ( 5.006s elapsed)
EXIT time 0.007s ( 0.001s elapsed)
Total time 119.570s ( 28.806s elapsed)
Alloc rate 778,712,134 bytes per MUT second
Productivity 54.8% of total user, 82.6% of total elapsed
```
The realtime improvement is nice (`-20%`), but even nicer is the "serial" time improvement, from `329.497s`to `119.570s` (`2.75x` speedup).
This is on modified 8.0.2, but the related code looks about the same on HEAD.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"The size of FastString table is suboptimal for large codebases","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonmar"],"type":"Bug","description":"Context:\r\nI was profiling a no-op rebuild (build once, do incremental build with nothing changed) of a large code base. It takes `35.829s`, and according to the profile about `20%` of the time is spent in `mkFastStringByteString`.\r\n\r\nI run it with `-dfaststring-stats +RTS -s` and got:\r\n{{{\r\nFastString stats:\r\n size: 4091\r\n entries: 829959\r\n longest chain: 268\r\n has z-encoding: 0%\r\n 50,011,906,640 bytes allocated in the heap\r\n 7,936,277,664 bytes copied during GC\r\n 3,106,526,336 bytes maximum residency (8 sample(s))\r\n 123,108,224 bytes maximum slop\r\n 10169 MB total memory in use (0 MB lost due to fragmentation)\r\n\r\n Tot time (elapsed) Avg pause Max pause\r\n Gen 0 117 colls, 37 par 32.390s 2.293s 0.0196s 0.0911s\r\n Gen 1 8 colls, 3 par 19.722s 2.266s 0.2832s 0.6936s\r\n\r\n Parallel GC work balance: 60.62% (serial 0%, perfect 100%)\r\n\r\n TASKS: 93 (1 bound, 92 peak workers (92 total), using -N30)\r\n\r\n SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled)\r\n\r\n INIT time 0.009s ( 0.009s elapsed)\r\n MUT time 277.370s ( 31.261s elapsed)\r\n GC time 52.113s ( 4.558s elapsed)\r\n EXIT time 0.005s ( 0.001s elapsed)\r\n Total time 329.497s ( 35.829s elapsed)\r\n\r\n Alloc rate 180,307,295 bytes per MUT second\r\n\r\n Productivity 84.2% of total user, 87.3% of total elapsed\t\r\n}}}\r\n\r\nThat's pretty bad, fitting `800k` elements in `4k` buckets is hard.\r\n\r\nTo confirm this indeed could be improved I changed the size to `2^20` (`1048576`) and also removed division in `hashStr` function (it come up on `perf` profile), like this:\r\n{{{\r\nhashStr :: Ptr Word8 -> Int -> Int\r\n -- use the Addr to produce a hash value between 0 & m (inclusive)\r\nhashStr (Ptr a#) (I# len#) = loop 0# 0#\r\n where\r\n loop h n | isTrue# (n ==# len#) = I# h\r\n | otherwise = loop h2 (n +# 1#)\r\n where !c = ord# (indexCharOffAddr# a# n)\r\n -- !h2 = (c +# (h *# 128#)) `remInt#`\r\n -- hASH_TBL_SIZE#\r\n -- NOTE: below is multiplication by 127 (a prime) and division by 2^20, it's by no means the best hashing function\r\n !h2 = (c +# ((h `uncheckedIShiftL#` 7#) -# h)) `andI#` hASH_TBL_SIZE_MASK#\r\n}}}\r\n\r\nHere's what I ended up with:\r\n{{{\r\nFastString stats:\r\n size: 1048576\r\n entries: 829959\r\n longest chain: 8\r\n has z-encoding: 0%\r\n 51,012,218,048 bytes allocated in the heap\r\n 8,948,377,768 bytes copied during GC\r\n 3,543,797,248 bytes maximum residency (8 sample(s))\r\n 139,428,352 bytes maximum slop\r\n 10502 MB total memory in use (0 MB lost due to fragmentation)\r\n\r\n Tot time (elapsed) Avg pause Max pause\r\n Gen 0 115 colls, 39 par 32.261s 2.677s 0.0233s 0.2225s\r\n Gen 1 8 colls, 3 par 21.786s 2.329s 0.2911s 0.5737s\r\n\r\n Parallel GC work balance: 48.75% (serial 0%, perfect 100%)\r\n\r\n TASKS: 93 (1 bound, 92 peak workers (92 total), using -N30)\r\n\r\n SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled)\r\n\r\n INIT time 0.008s ( 0.008s elapsed)\r\n MUT time 65.508s ( 23.791s elapsed)\r\n GC time 54.047s ( 5.006s elapsed)\r\n EXIT time 0.007s ( 0.001s elapsed)\r\n Total time 119.570s ( 28.806s elapsed)\r\n\r\n Alloc rate 778,712,134 bytes per MUT second\r\n\r\n Productivity 54.8% of total user, 82.6% of total elapsed\r\n}}}\r\n\r\nThe realtime improvement is nice (`-20%`), but even nicer is the \"serial\" time improvement, from `329.497s`to `119.570s` (`2.75x` speedup).\r\n\r\nThis is on modified 8.0.2, but the related code looks about the same on HEAD.","type_of_failure":"OtherFailure","blocking":[]} -->Zejun WuZejun Wuhttps://gitlab.haskell.org/ghc/ghc/-/issues/14855Implementation of liftA2 for Const has high arity2019-07-07T18:15:18ZlyxiaImplementation of liftA2 for Const has high arity```
instance Monoid m => Applicative (Const m) where
pure _ = Const mempty
liftA2 _ (Const x) (Const y) = Const (x `mappend` y)
(<*>) = coerce (mappend :: m -> m -> m)
```
https://hackage.haskell.org/package/base-4.10.1.0/do...```
instance Monoid m => Applicative (Const m) where
pure _ = Const mempty
liftA2 _ (Const x) (Const y) = Const (x `mappend` y)
(<*>) = coerce (mappend :: m -> m -> m)
```
https://hackage.haskell.org/package/base-4.10.1.0/docs/src/Data.Functor.Const.html\#line-69
`(<*>)` is implemented with a `coerce` but `liftA2` isn't. Would the following not have better inlining behavior?
```
liftA2 _ = coerce (mappend :: m -> m -> m)
```
Going further, should the unused argument also be moved to the RHS? What about `pure`? What are the pros and cons compared to this other alternative:
```
pure = \_ -> Const mempty
liftA2 = \_ -> coerce (mappend :: m -> m -> m)
```
This came up while implementing `Applicative` for `K1` in phab:D4447. `K1` is essentially the same type as `Const` and thus their instances should be identical for the sake of consistency. But it's not clear to me whether `Const`'s `Applicative` instance is already optimal. Is it?https://gitlab.haskell.org/ghc/ghc/-/issues/14856GHC API: Linker failure on loading target multiple times2019-07-07T18:15:18ZMatt WalkerGHC API: Linker failure on loading target multiple timesMinimum Working Example: https://github.com/Fizzixnerd/ghc-bug
`stack exec -- ghc --version`
> The Glorious Glasgow Haskell Compilation System, version 8.2.2
`uname --all`
> Linux \<REDACTED\> 4.14.0-3-amd64 #1 SMP Debian 4.14.13-1 (...Minimum Working Example: https://github.com/Fizzixnerd/ghc-bug
`stack exec -- ghc --version`
> The Glorious Glasgow Haskell Compilation System, version 8.2.2
`uname --all`
> Linux \<REDACTED\> 4.14.0-3-amd64 #1 SMP Debian 4.14.13-1 (2018-01-14) x86_64 GNU/Linux
Description: Loading a dynamic module more than once causes a linker failure with the following message:
'''
/usr/bin/ld.gold: error: cannot find -lghc_2
collect2: error: ld returned 1 exit status
`gcc' failed in phase `Linker'. (Exit code: 1)
- \*\* Exception: ExitFailure 1
'''
`-lghc_2' sometimes is `-lghc_5' or other numbers.
Steps to Reproduce:
1) Clone above repo.
2) `stack build`
3) `stack exec mwe-exe`
The repo code will use the GHC API to load a string from the file contained in scripts/ named `val`. There are three functions defined in src/Lib.hs. `anotherFunc` should behave normally. `someFunc' should display the bad behavior.
Notes:
- When using `intero`: intero must be restarted if this bug is encountered at the prompt, or else you will keep getting it over and over again.
- I could not figure out how to load it up without using the `-dynamic' flag, but that should probably be checked out too.8.4.1https://gitlab.haskell.org/ghc/ghc/-/issues/14857GHC-8.4.1 release notes don't mention 'Div', 'Mod' and other type families2019-07-07T18:15:18ZDmitrii KovanikovGHC-8.4.1 release notes don't mention 'Div', 'Mod' and other type familiesGHC 8.4.1 brought support for `Div`, `Mod` and `Log2` type families for type level natural numbers:
- https://downloads.haskell.org/\~ghc/master/libraries/base/base/GHC-TypeNats.html\#t:Div
I'm actually using this feature in `o-clock` ...GHC 8.4.1 brought support for `Div`, `Mod` and `Log2` type families for type level natural numbers:
- https://downloads.haskell.org/\~ghc/master/libraries/base/base/GHC-TypeNats.html\#t:Div
I'm actually using this feature in `o-clock` package
- https://github.com/serokell/o-clock
But I was told about this feature only by other Haskell developer. And I don't see this change described in release notes for GHC 8.4.1:
- https://downloads.haskell.org/%7Eghc/master/users-guide/8.4.1-notes.html\#base-library
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 8.4.1-alpha3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC-8.4.1 release notes don't mention 'Div', 'Mod' and other type families","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"8.4.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.1-alpha3","keywords":["base,documentation,div,mod,type","families,changelog,release","notes"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"GHC 8.4.1 brought support for `Div`, `Mod` and `Log2` type families for type level natural numbers:\r\n\r\n* https://downloads.haskell.org/~ghc/master/libraries/base/base/GHC-TypeNats.html#t:Div\r\n\r\nI'm actually using this feature in `o-clock` package\r\n\r\n* https://github.com/serokell/o-clock\r\n\r\nBut I was told about this feature only by other Haskell developer. And I don't see this change described in release notes for GHC 8.4.1:\r\n\r\n* https://downloads.haskell.org/%7Eghc/master/users-guide/8.4.1-notes.html#base-library","type_of_failure":"OtherFailure","blocking":[]} -->8.4.1https://gitlab.haskell.org/ghc/ghc/-/issues/14858Typed hole subtitution search fails in the REPL2019-07-07T18:15:18Zpaf31Typed hole subtitution search fails in the REPLIt seems as though type class defaulting might be happening before the search.
This finds only undefined:
`
> _traverse print "abc"
<interactive>:20:1: error:
• Found hole: _traverse :: (() -> IO ()) -> [Char] -> t
Where: ‘...It seems as though type class defaulting might be happening before the search.
This finds only undefined:
`
> _traverse print "abc"
<interactive>:20:1: error:
• Found hole: _traverse :: (() -> IO ()) -> [Char] -> t
Where: ‘t’ is a rigid type variable bound by
the inferred type of it :: t
at <interactive>:20:1-21
Or perhaps ‘_traverse’ is mis-spelled, or not in scope
• In the expression: _traverse
In the expression: _traverse print "abc"
In an equation for ‘it’: it = _traverse print "abc"
• Relevant bindings include it :: t (bound at <interactive>:20:1)
Valid substitutions include
undefined :: forall (a :: TYPE r).
GHC.Stack.Types.HasCallStack =>
a
(imported from ‘Prelude’ (and originally defined in ‘GHC.Err’))
`
Annotating the return type helps, but we still don't find traverse_:
`
> _traverse print "abc" :: IO ()
<interactive>:22:1: error:
• Found hole: _traverse :: (() -> IO ()) -> [Char] -> IO ()
Or perhaps ‘_traverse’ is mis-spelled, or not in scope
• In the expression: _traverse
In the expression: _traverse print "abc" :: IO ()
In an equation for ‘it’: it = _traverse print "abc" :: IO ()
• Relevant bindings include
it :: IO () (bound at <interactive>:22:1)
Valid substitutions include
mempty :: forall a. Monoid a => a
(imported from ‘Prelude’ (and originally defined in ‘GHC.Base’))
undefined :: forall (a :: TYPE r).
GHC.Stack.Types.HasCallStack =>
a
(imported from ‘Prelude’ (and originally defined in ‘GHC.Err’))
`
(note how print seems to have been defaulted to ())
Annotating the type of print helps:
`
> _traverse (print :: Char -> IO ()) "abc" :: IO ()
<interactive>:23:1: error:
• Found hole: _traverse :: (Char -> IO ()) -> [Char] -> IO ()
Or perhaps ‘_traverse’ is mis-spelled, or not in scope
• In the expression: _traverse
In the expression:
_traverse (print :: Char -> IO ()) "abc" :: IO ()
In an equation for ‘it’:
it = _traverse (print :: Char -> IO ()) "abc" :: IO ()
• Relevant bindings include
it :: IO () (bound at <interactive>:23:1)
Valid substitutions include
mempty :: forall a. Monoid a => a
(imported from ‘Prelude’ (and originally defined in ‘GHC.Base’))
undefined :: forall (a :: TYPE r).
GHC.Stack.Types.HasCallStack =>
a
(imported from ‘Prelude’ (and originally defined in ‘GHC.Err’))
foldMap :: forall (t :: * -> *).
Foldable t =>
forall m a. Monoid m => (a -> m) -> t a -> m
(imported from ‘Prelude’
(and originally defined in ‘Data.Foldable’))
mapM_ :: forall (t :: * -> *) (m :: * -> *) a b.
(Foldable t, Monad m) =>
(a -> m b) -> t a -> m ()
(imported from ‘Prelude’
(and originally defined in ‘Data.Foldable’))
traverse_ :: forall (t :: * -> *) (f :: * -> *) a b.
(Foldable t, Applicative f) =>
(a -> f b) -> t a -> f ()
(imported from ‘Data.Foldable’)
`
This was found with 8.4.1-rc.1.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.4.1-alpha3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Typed hole subtitution search fails in the REPL","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"8.4.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.1-alpha3","keywords":["holes","substitutions","typed"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"It seems as though type class defaulting might be happening before the search.\r\n\r\nThis finds only undefined:\r\n\r\n {{{#!text\r\n> _traverse print \"abc\"\r\n\r\n<interactive>:20:1: error:\r\n • Found hole: _traverse :: (() -> IO ()) -> [Char] -> t\r\n Where: ‘t’ is a rigid type variable bound by\r\n the inferred type of it :: t\r\n at <interactive>:20:1-21\r\n Or perhaps ‘_traverse’ is mis-spelled, or not in scope\r\n • In the expression: _traverse\r\n In the expression: _traverse print \"abc\"\r\n In an equation for ‘it’: it = _traverse print \"abc\"\r\n • Relevant bindings include it :: t (bound at <interactive>:20:1)\r\n Valid substitutions include\r\n undefined :: forall (a :: TYPE r).\r\n GHC.Stack.Types.HasCallStack =>\r\n a\r\n (imported from ‘Prelude’ (and originally defined in ‘GHC.Err’))\r\n }}}\r\n\r\nAnnotating the return type helps, but we still don't find traverse_:\r\n\r\n {{{#!text\r\n> _traverse print \"abc\" :: IO ()\r\n\r\n<interactive>:22:1: error:\r\n • Found hole: _traverse :: (() -> IO ()) -> [Char] -> IO ()\r\n Or perhaps ‘_traverse’ is mis-spelled, or not in scope\r\n • In the expression: _traverse\r\n In the expression: _traverse print \"abc\" :: IO ()\r\n In an equation for ‘it’: it = _traverse print \"abc\" :: IO ()\r\n • Relevant bindings include\r\n it :: IO () (bound at <interactive>:22:1)\r\n Valid substitutions include\r\n mempty :: forall a. Monoid a => a\r\n (imported from ‘Prelude’ (and originally defined in ‘GHC.Base’))\r\n undefined :: forall (a :: TYPE r).\r\n GHC.Stack.Types.HasCallStack =>\r\n a\r\n (imported from ‘Prelude’ (and originally defined in ‘GHC.Err’))\r\n }}}\r\n\r\n(note how print seems to have been defaulted to ())\r\n\r\nAnnotating the type of print helps:\r\n\r\n {{{#!text\r\n> _traverse (print :: Char -> IO ()) \"abc\" :: IO ()\r\n\r\n<interactive>:23:1: error:\r\n • Found hole: _traverse :: (Char -> IO ()) -> [Char] -> IO ()\r\n Or perhaps ‘_traverse’ is mis-spelled, or not in scope\r\n • In the expression: _traverse\r\n In the expression:\r\n _traverse (print :: Char -> IO ()) \"abc\" :: IO ()\r\n In an equation for ‘it’:\r\n it = _traverse (print :: Char -> IO ()) \"abc\" :: IO ()\r\n • Relevant bindings include\r\n it :: IO () (bound at <interactive>:23:1)\r\n Valid substitutions include\r\n mempty :: forall a. Monoid a => a\r\n (imported from ‘Prelude’ (and originally defined in ‘GHC.Base’))\r\n undefined :: forall (a :: TYPE r).\r\n GHC.Stack.Types.HasCallStack =>\r\n a\r\n (imported from ‘Prelude’ (and originally defined in ‘GHC.Err’))\r\n foldMap :: forall (t :: * -> *).\r\n Foldable t =>\r\n forall m a. Monoid m => (a -> m) -> t a -> m\r\n (imported from ‘Prelude’\r\n (and originally defined in ‘Data.Foldable’))\r\n mapM_ :: forall (t :: * -> *) (m :: * -> *) a b.\r\n (Foldable t, Monad m) =>\r\n (a -> m b) -> t a -> m ()\r\n (imported from ‘Prelude’\r\n (and originally defined in ‘Data.Foldable’))\r\n traverse_ :: forall (t :: * -> *) (f :: * -> *) a b.\r\n (Foldable t, Applicative f) =>\r\n (a -> f b) -> t a -> f ()\r\n (imported from ‘Data.Foldable’)\r\n }}}\r\n\r\nThis was found with 8.4.1-rc.1.","type_of_failure":"OtherFailure","blocking":[]} -->8.4.1Tao Hesighingnow@gmail.comTao Hesighingnow@gmail.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/14859Allow explicit impredicativity2020-07-16T17:17:27ZSimon Peyton JonesAllow explicit impredicativityIn [this email](https://mail.haskell.org/pipermail/ghc-devs/2016-September/012940.html) I suggested allowing a simple form of impredicativity. With a suitable extension flag (`-XExplicitImpredicativeTypes` perhaps), you woudl be allowed:...In [this email](https://mail.haskell.org/pipermail/ghc-devs/2016-September/012940.html) I suggested allowing a simple form of impredicativity. With a suitable extension flag (`-XExplicitImpredicativeTypes` perhaps), you woudl be allowed:
- To write a polytype in a visible type argument; eg. `f @(forall a. a->a)`
- To write a polytype as an argument of a type in a signature e.g. `f :: [forall a. a->a] -> Int`
*But that’s all*. A unification variable still cannot be unified with a polytype. The only way you can call a polymorphic function at a polytype is to use Visible Type Application (VTA).
So using impredicative types might be tiresome. E.g.
```
type SID = forall a. a->a
xs :: [forall a. a->a]
xs = (:) @SID id ( (:) @SID id ([] @ SID))
```
In short, if you call a function at a polytype, you must use VTA. Simple, easy, predictable; and doubtless annoying. But at least it's possible.
The main motivation is that we are naughtily doing this anyway in the implementation of `GeneralisedNewtypeDeriving` -- see Trac #14070 #14859 ff. If we are doing it under the hood, we could just made it available to programmers.
This is much less ambitious, and much easier to implement, than the proposed [Guarded impredicative polymorphism](https://www.microsoft.com/en-us/research/publication/guarded-impredicative-polymorphism/) (PLDI'18).
This ticket just records the idea, to see what other use-cases people might want to add. Then someone would have to write a GHC proposal.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.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":"Allow explicit impredicativity","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In [https://mail.haskell.org/pipermail/ghc-devs/2016-September/012940.html this email] I suggested allowing a simple form of impredicativity. With a suitable extension flag (`-XExplicitImpredicativeTypes` perhaps), you woudl be allowed:\r\n\r\n* To write a polytype in a visible type argument; eg. `f @(forall a. a->a)`\r\n\r\n* To write a polytype as an argument of a type in a signature e.g. `f :: [forall a. a->a] -> Int`\r\n\r\n''But that’s all''. A unification variable still cannot be unified with a polytype. The only way you can call a polymorphic function at a polytype is to use Visible Type Application (VTA).\r\n\r\nSo using impredicative types might be tiresome. E.g.\r\n{{{\r\n type SID = forall a. a->a\r\n xs :: [forall a. a->a]\r\n xs = (:) @SID id ( (:) @SID id ([] @ SID))\r\n}}}\r\nIn short, if you call a function at a polytype, you must use VTA. Simple, easy, predictable; and doubtless annoying. But at least it's possible.\r\n\r\nThe main motivation is that we are naughtily doing this anyway in the implementation of `GeneralisedNewtypeDeriving` -- see Trac #14070 comment:23 ff. If we are doing it under the hood, we could just made it available to programmers.\r\n\r\nThis is much less ambitious, and much easier to implement, than the proposed [https://www.microsoft.com/en-us/research/publication/guarded-impredicative-polymorphism/ Guarded impredicative polymorphism] (PLDI'18).\r\n\r\nThis ticket just records the idea, to see what other use-cases people might want to add. Then someone would have to write a GHC proposal.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14860QuantifiedConstraints: Can't quantify constraint involving type family2023-07-05T21:01:48ZRyan ScottQuantifiedConstraints: Can't quantify constraint involving type familyThis program fails to typecheck using the `wip/T2893` branch, to my surprise:
```hs
{-# LANGUAGE AllowAmbiguousTypes #-}
{-# LANGUAGE GADTs #-}
{-# LANGUAGE QuantifiedConstraints #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE Undecidabl...This program fails to typecheck using the `wip/T2893` branch, to my surprise:
```hs
{-# LANGUAGE AllowAmbiguousTypes #-}
{-# LANGUAGE GADTs #-}
{-# LANGUAGE QuantifiedConstraints #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE UndecidableInstances #-}
module Bug where
import Data.Proxy
type family Apply (f :: * -> *) a
type instance Apply Proxy a = Proxy a
data ExTyFam f where
MkExTyFam :: Apply f a -> ExTyFam f
instance (forall a. Show (Apply f a)) => Show (ExTyFam f) where
show (MkExTyFam x) = show x
showsPrec = undefined -- Not defining these leads to the oddities observed in
showList = undefined -- https://ghc.haskell.org/trac/ghc/ticket/5927#comment:32
test :: ExTyFam Proxy -> String
test = show
```
This fails with:
```
$ ghc-cq/inplace/bin/ghc-stage2 --interactive Bug.hs
GHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
[1 of 1] Compiling Bug ( Bug.hs, interpreted )
Bug.hs:17:24: error:
• Could not deduce (Show (Apply f a)) arising from a use of ‘show’
from the context: forall a. Show (Apply f a)
bound by the instance declaration at Bug.hs:16:10-57
• In the expression: show x
In an equation for ‘show’: show (MkExTyFam x) = show x
In the instance declaration for ‘Show (ExTyFam f)’
|
17 | show (MkExTyFam x) = show x
| ^^^^^^
```
I would have expected the `(forall a. Show (Apply f a))` quantified constraint to kick in, but it didn't.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"QuantifiedConstraints: Can't quantify constraint involving type family","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":["QuantifiedConstraints","wipT2893"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This program fails to typecheck using the `wip/T2893` branch, to my surprise:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE AllowAmbiguousTypes #-}\r\n{-# LANGUAGE GADTs #-}\r\n{-# LANGUAGE QuantifiedConstraints #-}\r\n{-# LANGUAGE TypeFamilies #-}\r\n{-# LANGUAGE UndecidableInstances #-}\r\nmodule Bug where\r\n\r\nimport Data.Proxy\r\n\r\ntype family Apply (f :: * -> *) a\r\ntype instance Apply Proxy a = Proxy a\r\n\r\ndata ExTyFam f where\r\n MkExTyFam :: Apply f a -> ExTyFam f\r\n\r\ninstance (forall a. Show (Apply f a)) => Show (ExTyFam f) where\r\n show (MkExTyFam x) = show x\r\n showsPrec = undefined -- Not defining these leads to the oddities observed in\r\n showList = undefined -- https://ghc.haskell.org/trac/ghc/ticket/5927#comment:32\r\n\r\ntest :: ExTyFam Proxy -> String\r\ntest = show\r\n}}}\r\n\r\nThis fails with:\r\n\r\n{{{\r\n$ ghc-cq/inplace/bin/ghc-stage2 --interactive Bug.hs\r\nGHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help\r\nLoaded GHCi configuration from /home/rgscott/.ghci\r\n[1 of 1] Compiling Bug ( Bug.hs, interpreted )\r\n\r\nBug.hs:17:24: error:\r\n • Could not deduce (Show (Apply f a)) arising from a use of ‘show’\r\n from the context: forall a. Show (Apply f a)\r\n bound by the instance declaration at Bug.hs:16:10-57\r\n • In the expression: show x\r\n In an equation for ‘show’: show (MkExTyFam x) = show x\r\n In the instance declaration for ‘Show (ExTyFam f)’\r\n |\r\n17 | show (MkExTyFam x) = show x\r\n | ^^^^^^\r\n}}}\r\n\r\nI would have expected the `(forall a. Show (Apply f a))` quantified constraint to kick in, but it didn't.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14861QuantifiedConstraints: Can't use forall'd variable in context2019-07-07T18:15:17ZRyan ScottQuantifiedConstraints: Can't use forall'd variable in contextThis fails to typecheck, to my surprise:
```hs
{-# LANGUAGE AllowAmbiguousTypes #-}
{-# LANGUAGE ConstraintKinds #-}
{-# LANGUAGE GADTs #-}
{-# LANGUAGE KindSignatures #-}
{-# LANGUAGE QuantifiedConstraints #-}
{-# LANGUAGE UndecidableI...This fails to typecheck, to my surprise:
```hs
{-# LANGUAGE AllowAmbiguousTypes #-}
{-# LANGUAGE ConstraintKinds #-}
{-# LANGUAGE GADTs #-}
{-# LANGUAGE KindSignatures #-}
{-# LANGUAGE QuantifiedConstraints #-}
{-# LANGUAGE UndecidableInstances #-}
module Bug where
import Data.Kind
data ECC1 :: (Type -> Constraint) -> (Type -> Type) -> Type -> Type where
ECC1 :: c p => f p -> ECC1 c f p
class Foldable' f where
foldMap' :: Monoid m => (a -> m) -> f a -> m
instance (forall p. c p => Foldable' f) => Foldable' (ECC1 c f) where
foldMap' f (ECC1 x) = foldMap' f x
instance Foldable' [] where
foldMap' = foldMap
test :: ECC1 Show [] Ordering -> Ordering
test = foldMap' id
```
```
$ ghc-cq/inplace/bin/ghc-stage2 --interactive Bug.hs
GHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
[1 of 1] Compiling Bug ( Bug.hs, interpreted )
Bug.hs:18:25: error:
• Could not deduce: c p0 arising from a use of ‘foldMap'’
from the context: forall p. c p => Foldable' f
bound by the instance declaration at Bug.hs:17:10-63
or from: Monoid m
bound by the type signature for:
foldMap' :: forall m a. Monoid m => (a -> m) -> ECC1 c f a -> m
at Bug.hs:18:3-10
or from: c a
bound by a pattern with constructor:
ECC1 :: forall (f :: * -> *) p (c :: * -> Constraint).
c p =>
f p -> ECC1 c f p,
in an equation for ‘foldMap'’
at Bug.hs:18:15-20
• In the expression: foldMap' f x
In an equation for ‘foldMap'’: foldMap' f (ECC1 x) = foldMap' f x
In the instance declaration for ‘Foldable' (ECC1 c f)’
• Relevant bindings include
foldMap' :: (a -> m) -> ECC1 c f a -> m (bound at Bug.hs:18:3)
|
18 | foldMap' f (ECC1 x) = foldMap' f x
| ^^^^^^^^^^^^
```
I would have expected the `(forall p. c p => Foldable' f)` quantified constraint to kick in there.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"QuantifiedConstraints: Can't use forall'd variable in context","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":["QuantifiedConstraints","wipT2893"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This fails to typecheck, to my surprise:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE AllowAmbiguousTypes #-}\r\n{-# LANGUAGE ConstraintKinds #-}\r\n{-# LANGUAGE GADTs #-}\r\n{-# LANGUAGE KindSignatures #-}\r\n{-# LANGUAGE QuantifiedConstraints #-}\r\n{-# LANGUAGE UndecidableInstances #-}\r\nmodule Bug where\r\n\r\nimport Data.Kind\r\n\r\ndata ECC1 :: (Type -> Constraint) -> (Type -> Type) -> Type -> Type where\r\n ECC1 :: c p => f p -> ECC1 c f p\r\n\r\nclass Foldable' f where\r\n foldMap' :: Monoid m => (a -> m) -> f a -> m\r\n\r\ninstance (forall p. c p => Foldable' f) => Foldable' (ECC1 c f) where\r\n foldMap' f (ECC1 x) = foldMap' f x\r\n\r\ninstance Foldable' [] where\r\n foldMap' = foldMap\r\n\r\ntest :: ECC1 Show [] Ordering -> Ordering\r\ntest = foldMap' id\r\n}}}\r\n\r\n{{{\r\n$ ghc-cq/inplace/bin/ghc-stage2 --interactive Bug.hs\r\nGHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help\r\nLoaded GHCi configuration from /home/rgscott/.ghci\r\n[1 of 1] Compiling Bug ( Bug.hs, interpreted )\r\n\r\nBug.hs:18:25: error:\r\n • Could not deduce: c p0 arising from a use of ‘foldMap'’\r\n from the context: forall p. c p => Foldable' f\r\n bound by the instance declaration at Bug.hs:17:10-63\r\n or from: Monoid m\r\n bound by the type signature for:\r\n foldMap' :: forall m a. Monoid m => (a -> m) -> ECC1 c f a -> m\r\n at Bug.hs:18:3-10\r\n or from: c a\r\n bound by a pattern with constructor:\r\n ECC1 :: forall (f :: * -> *) p (c :: * -> Constraint).\r\n c p =>\r\n f p -> ECC1 c f p,\r\n in an equation for ‘foldMap'’\r\n at Bug.hs:18:15-20\r\n • In the expression: foldMap' f x\r\n In an equation for ‘foldMap'’: foldMap' f (ECC1 x) = foldMap' f x\r\n In the instance declaration for ‘Foldable' (ECC1 c f)’\r\n • Relevant bindings include\r\n foldMap' :: (a -> m) -> ECC1 c f a -> m (bound at Bug.hs:18:3)\r\n |\r\n18 | foldMap' f (ECC1 x) = foldMap' f x\r\n | ^^^^^^^^^^^^\r\n}}}\r\n\r\nI would have expected the `(forall p. c p => Foldable' f)` quantified constraint to kick in there.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14862Switching to Cabal 2.2 makes ghc unusable2019-07-07T18:15:17ZAlp MestanogullariSwitching to Cabal 2.2 makes ghc unusableWhen bumping Cabal to 2.2 as done [here](https://phabricator.haskell.org/D4453), we end up with a stage 1 GHC that seemingly cannot build a non-segfaulting program.
For instance, if one builds the following trivial program with a stage ...When bumping Cabal to 2.2 as done [here](https://phabricator.haskell.org/D4453), we end up with a stage 1 GHC that seemingly cannot build a non-segfaulting program.
For instance, if one builds the following trivial program with a stage 1 built from the ghc-8.4 branch + the patch above...
```hs
import System.Exit
main = exitSuccess
```
Then...
```sh
$ ./foo
Segmentation fault
```
So of course, when we proceed and build stage 2, and then build things with stage 2, all the stage2 commands crash.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.1-alpha3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | None |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | bgamari |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Switching to Cabal 2.2 makes ghc unusable","status":"New","operating_system":"","component":"None","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.1-alpha3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["bgamari"],"type":"Bug","description":"When bumping Cabal to 2.2 as done [https://phabricator.haskell.org/D4453 here], we end up with a stage 1 GHC that seemingly cannot build a non-segfaulting program.\r\n\r\nFor instance, if one builds the following trivial program with a stage 1 built from the ghc-8.4 branch + the patch above...\r\n\r\n{{{#!hs\r\nimport System.Exit\r\nmain = exitSuccess\r\n}}}\r\n\r\nThen...\r\n\r\n{{{#!sh\r\n$ ./foo\r\nSegmentation fault\r\n}}}\r\n\r\nSo of course, when we proceed and build stage 2, and then build things with stage 2, all the stage2 commands crash.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Moritz AngermannMoritz Angermannhttps://gitlab.haskell.org/ghc/ghc/-/issues/14863QuantifiedConstraints: Can't deduce `c' from `(a, b)' and `a |- b |- c'2019-07-07T18:15:17ZIcelandjackQuantifiedConstraints: Can't deduce `c' from `(a, b)' and `a |- b |- c'#14833 fixes #14835: we can witness `curryC :: ((a, b) |- c) :- (a |- b |- c)`.
Now for the entirely predictable, how about \*\*un\*\*`curryC`
```hs
{-# Language QuantifiedConstraints, RankNTypes, PolyKinds, ConstraintKinds, Undecidabl...#14833 fixes #14835: we can witness `curryC :: ((a, b) |- c) :- (a |- b |- c)`.
Now for the entirely predictable, how about \*\*un\*\*`curryC`
```hs
{-# Language QuantifiedConstraints, RankNTypes, PolyKinds, ConstraintKinds, UndecidableInstances, GADTs, LiberalTypeSynonyms, TypeOperators, MultiParamTypeClasses, FlexibleInstances #-}
data Dict c where
Dict :: c => Dict c
infixr |-
class (a => b) => (a |- b)
instance (a => b) => (a |- b)
type a :- b = Dict (a |- b)
uncurryC :: forall a b c. (a |- b |- c) :- ((a, b) |- c)
uncurryC = Dict
```
```
$ ghci -ignore-dot-ghci Z.hs
GHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling Main ( Z.hs, interpreted )
Z.hs:13:12: error:
• Could not deduce: c arising from a use of ‘Dict’
from the context: a |- (b |- c)
bound by a quantified context at Z.hs:1:1
or from: (a, b) bound by a quantified context at Z.hs:1:1
• In the expression: Dict
In an equation for ‘uncurryC’: uncurryC = Dict
• Relevant bindings include
uncurryC :: (a |- (b |- c)) :- ((a, b) |- c) (bound at Z.hs:13:1)
|
13 | uncurryC = Dict
| ^^^^
Failed, no modules loaded.
Prelude>
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"QuantifiedConstraints: Can't deduce `c' from `(a, b)' and `a |- b |- c'","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":["QuantifiedConstraints","wipT2893"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"#14833 fixes #14835: we can witness `curryC :: ((a, b) |- c) :- (a |- b |- c)`.\r\n\r\nNow for the entirely predictable, how about **un**`curryC`\r\n\r\n{{{#!hs\r\n{-# Language QuantifiedConstraints, RankNTypes, PolyKinds, ConstraintKinds, UndecidableInstances, GADTs, LiberalTypeSynonyms, TypeOperators, MultiParamTypeClasses, FlexibleInstances #-}\r\n\r\ndata Dict c where\r\n Dict :: c => Dict c\r\n\r\ninfixr |-\r\nclass (a => b) => (a |- b)\r\ninstance (a => b) => (a |- b)\r\n\r\ntype a :- b = Dict (a |- b)\r\n\r\nuncurryC :: forall a b c. (a |- b |- c) :- ((a, b) |- c)\r\nuncurryC = Dict\r\n}}}\r\n\r\n{{{\r\n$ ghci -ignore-dot-ghci Z.hs \r\nGHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help\r\n[1 of 1] Compiling Main ( Z.hs, interpreted )\r\n\r\nZ.hs:13:12: error:\r\n • Could not deduce: c arising from a use of ‘Dict’\r\n from the context: a |- (b |- c)\r\n bound by a quantified context at Z.hs:1:1\r\n or from: (a, b) bound by a quantified context at Z.hs:1:1\r\n • In the expression: Dict\r\n In an equation for ‘uncurryC’: uncurryC = Dict\r\n • Relevant bindings include\r\n uncurryC :: (a |- (b |- c)) :- ((a, b) |- c) (bound at Z.hs:13:1)\r\n |\r\n13 | uncurryC = Dict\r\n | ^^^^\r\nFailed, no modules loaded.\r\nPrelude> \r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/14864Suggestion: Turn on +RTS -xt by default2019-07-07T18:15:17ZryantrinkleSuggestion: Turn on +RTS -xt by defaultI found it quite surprising and difficult to debug that my heap profile showed no leak while the GC stats showed a clear leak. As a user who is somewhat familiar with this stuff, I was quite surprised that those two data sources didn't a...I found it quite surprising and difficult to debug that my heap profile showed no leak while the GC stats showed a clear leak. As a user who is somewhat familiar with this stuff, I was quite surprised that those two data sources didn't agree. I wasn't sure how to determine why they disagreed, since none of the output referenced anything interesting.
I'm not familiar with the reasoning behind disabling -xt by default, but I think it may be easier for users to figure out that they need to \*disable\* it (since they'll be able to see its results in the heap profile) than to figure out that they need to \*enable\* it.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Suggestion: Turn on +RTS -xt by default","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"I found it quite surprising and difficult to debug that my heap profile showed no leak while the GC stats showed a clear leak. As a user who is somewhat familiar with this stuff, I was quite surprised that those two data sources didn't agree. I wasn't sure how to determine why they disagreed, since none of the output referenced anything interesting.\r\n\r\nI'm not familiar with the reasoning behind disabling -xt by default, but I think it may be easier for users to figure out that they need to *disable* it (since they'll be able to see its results in the heap profile) than to figure out that they need to *enable* it.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14865GHC Defeats Manual Worker Wrapper with Unboxed Sum2019-07-07T18:15:16ZAndrew MartinGHC Defeats Manual Worker Wrapper with Unboxed SumHere's the code in question:
```
{-# LANGUAGE BangPatterns #-}
{-# LANGUAGE LambdaCase #-}
{-# LANGUAGE MagicHash #-}
{-# LANGUAGE TypeInType #-}
{-# LANGUAGE UnboxedSums #-}
{-# LANGUAGE UnboxedTuples #-}
{-# OPTIONS_GHC -O2 #-}
modu...Here's the code in question:
```
{-# LANGUAGE BangPatterns #-}
{-# LANGUAGE LambdaCase #-}
{-# LANGUAGE MagicHash #-}
{-# LANGUAGE TypeInType #-}
{-# LANGUAGE UnboxedSums #-}
{-# LANGUAGE UnboxedTuples #-}
{-# OPTIONS_GHC -O2 #-}
module Byte.Array.Window
( findByte
, boxMaybeInt
) where
import Data.Primitive (ByteArray)
import Data.Word (Word8)
import GHC.Types (RuntimeRep,TYPE)
import GHC.Int (Int(I#))
import GHC.Exts (Int#)
import qualified Data.Primitive as PM
type Maybe# (a :: TYPE (r :: RuntimeRep)) = (# (# #) | a #)
boxMaybeInt :: Maybe# Int# -> Maybe Int
boxMaybeInt = \case
(# | a #) -> Just (I# a)
(# (# #) | #) -> Nothing
unboxInt :: Int -> Int#
unboxInt (I# i) = i
-- | Finds the first occurrence of the given byte.
-- TODO: optimize this to search through a whole
-- Word64 at a time if the bytearray is pinned.
findByte :: Int -> Int -> Word8 -> ByteArray -> Maybe Int
findByte !off !len !w !arr = boxMaybeInt (go off) where
go :: Int -> Maybe# Int#
go !ix = if ix < len
then if PM.indexByteArray arr ix == w
then (# | unboxInt ix #)
else go (ix + 1)
else (# (# #) | #)
```
When compiled with GHC 8.5 with `-ddump-simpl -dsuppress-all`, here is the relevant part of the resulting Core:
```
-- RHS size: {terms: 33, types: 13, coercions: 0, joins: 1/1}
$wfindByte
$wfindByte
= \ ww_s38C ww1_s38G ww2_s38K ww3_s38O ->
joinrec {
$wgo_s38v
$wgo_s38v ww4_s38t
= case <# ww4_s38t ww1_s38G of {
__DEFAULT -> Nothing;
1# ->
case indexWord8Array# ww3_s38O ww4_s38t of wild_a36w { __DEFAULT ->
case eqWord# wild_a36w ww2_s38K of {
__DEFAULT -> jump $wgo_s38v (+# ww4_s38t 1#);
1# -> Just (I# ww4_s38t)
}
}
}; } in
jump $wgo_s38v ww_s38C
-- RHS size: {terms: 21, types: 12, coercions: 0, joins: 0/0}
findByte
findByte
= \ w_s38w w1_s38x w2_s38y w3_s38z ->
case w_s38w of { I# ww1_s38C ->
case w1_s38x of { I# ww3_s38G ->
case w2_s38y of { W8# ww5_s38K ->
case w3_s38z of { ByteArray ww7_s38O ->
$wfindByte ww1_s38C ww3_s38G ww5_s38K ww7_s38O
}
}
}
}
```
I expected that the tail recursive `go` helpful function from my original code would still be a function that returns an unboxed sum when optimized and turned into Core. However, it isn't. The call to `boxMaybeInt` gets pushed into `go`. This means that when `findByte` is called and the result cased on, an allocation is going to happen. I think it would be preferable for `boxMaybeInt` to not get pushed into the worker, since `boxMaybeInt (go off)` could be inlined and the allocation of `Maybe` could be prevented (assuming that it was cased on right afterward).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC Defeats Manual Worker Wrapper with Unboxed Sum","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":["UnboxedSums"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Here's the code in question:\r\n\r\n{{{\r\n{-# LANGUAGE BangPatterns #-}\r\n{-# LANGUAGE LambdaCase #-}\r\n{-# LANGUAGE MagicHash #-}\r\n{-# LANGUAGE TypeInType #-}\r\n{-# LANGUAGE UnboxedSums #-}\r\n{-# LANGUAGE UnboxedTuples #-}\r\n\r\n{-# OPTIONS_GHC -O2 #-}\r\n\r\nmodule Byte.Array.Window\r\n ( findByte\r\n , boxMaybeInt\r\n ) where\r\n\r\nimport Data.Primitive (ByteArray)\r\nimport Data.Word (Word8)\r\nimport GHC.Types (RuntimeRep,TYPE)\r\nimport GHC.Int (Int(I#))\r\nimport GHC.Exts (Int#)\r\nimport qualified Data.Primitive as PM\r\n\r\ntype Maybe# (a :: TYPE (r :: RuntimeRep)) = (# (# #) | a #)\r\n\r\nboxMaybeInt :: Maybe# Int# -> Maybe Int\r\nboxMaybeInt = \\case\r\n (# | a #) -> Just (I# a)\r\n (# (# #) | #) -> Nothing\r\n\r\nunboxInt :: Int -> Int#\r\nunboxInt (I# i) = i\r\n\r\n-- | Finds the first occurrence of the given byte.\r\n-- TODO: optimize this to search through a whole\r\n-- Word64 at a time if the bytearray is pinned.\r\nfindByte :: Int -> Int -> Word8 -> ByteArray -> Maybe Int\r\nfindByte !off !len !w !arr = boxMaybeInt (go off) where\r\n go :: Int -> Maybe# Int#\r\n go !ix = if ix < len\r\n then if PM.indexByteArray arr ix == w\r\n then (# | unboxInt ix #)\r\n else go (ix + 1)\r\n else (# (# #) | #)\r\n}}}\r\n\r\nWhen compiled with GHC 8.5 with `-ddump-simpl -dsuppress-all`, here is the relevant part of the resulting Core:\r\n\r\n{{{\r\n-- RHS size: {terms: 33, types: 13, coercions: 0, joins: 1/1}\r\n$wfindByte\r\n$wfindByte\r\n = \\ ww_s38C ww1_s38G ww2_s38K ww3_s38O ->\r\n joinrec {\r\n $wgo_s38v\r\n $wgo_s38v ww4_s38t\r\n = case <# ww4_s38t ww1_s38G of {\r\n __DEFAULT -> Nothing;\r\n 1# ->\r\n case indexWord8Array# ww3_s38O ww4_s38t of wild_a36w { __DEFAULT ->\r\n case eqWord# wild_a36w ww2_s38K of {\r\n __DEFAULT -> jump $wgo_s38v (+# ww4_s38t 1#);\r\n 1# -> Just (I# ww4_s38t)\r\n }\r\n }\r\n }; } in\r\n jump $wgo_s38v ww_s38C\r\n\r\n-- RHS size: {terms: 21, types: 12, coercions: 0, joins: 0/0}\r\nfindByte\r\nfindByte\r\n = \\ w_s38w w1_s38x w2_s38y w3_s38z ->\r\n case w_s38w of { I# ww1_s38C ->\r\n case w1_s38x of { I# ww3_s38G ->\r\n case w2_s38y of { W8# ww5_s38K ->\r\n case w3_s38z of { ByteArray ww7_s38O ->\r\n $wfindByte ww1_s38C ww3_s38G ww5_s38K ww7_s38O\r\n }\r\n }\r\n }\r\n }\r\n}}}\r\n\r\nI expected that the tail recursive `go` helpful function from my original code would still be a function that returns an unboxed sum when optimized and turned into Core. However, it isn't. The call to `boxMaybeInt` gets pushed into `go`. This means that when `findByte` is called and the result cased on, an allocation is going to happen. I think it would be preferable for `boxMaybeInt` to not get pushed into the worker, since `boxMaybeInt (go off)` could be inlined and the allocation of `Maybe` could be prevented (assuming that it was cased on right afterward).","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14866GHC 8.4.1 rc1 segfaults when compiling the influxdb package2019-07-07T18:15:16ZFumiaki KinoshitaGHC 8.4.1 rc1 segfaults when compiling the influxdb packageI tried to build influxdb-1.2.2.3 with GHC 8.4.1 rc1 built with DYNAMIC_GHC_PROGRAMS=NO. Then I got
```
[ 8 of 10] Compiling Database.InfluxDB.Query ( src/Database/InfluxDB/Query.hs, /home/fumieval/hs/influxdb-haskell/dist-newstyle/buil...I tried to build influxdb-1.2.2.3 with GHC 8.4.1 rc1 built with DYNAMIC_GHC_PROGRAMS=NO. Then I got
```
[ 8 of 10] Compiling Database.InfluxDB.Query ( src/Database/InfluxDB/Query.hs, /home/fumieval/hs/influxdb-haskell/dist-newstyle/build/x86_64-linux/ghc-8.4.0.20180224/influxdb-1.2.2.3/build/Database/InfluxDB/Query.p_o )
cabal: Failed to build influxdb-1.2.2.3. The build process segfaulted (i.e.
SIGSEGV).
```
It seems to be related to Template Haskell, as it doesn't happen if I remove `makeLensesWith` in `Query.hs`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.1-alpha3 |
| 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 8.4.1 rc1 segfaults when compiling the influxdb package","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.1-alpha3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I tried to build influxdb-1.2.2.3 with GHC 8.4.1 rc1 built with DYNAMIC_GHC_PROGRAMS=NO. Then I got\r\n\r\n{{{\r\n[ 8 of 10] Compiling Database.InfluxDB.Query ( src/Database/InfluxDB/Query.hs, /home/fumieval/hs/influxdb-haskell/dist-newstyle/build/x86_64-linux/ghc-8.4.0.20180224/influxdb-1.2.2.3/build/Database/InfluxDB/Query.p_o )\r\ncabal: Failed to build influxdb-1.2.2.3. The build process segfaulted (i.e.\r\nSIGSEGV).\r\n}}}\r\n\r\nIt seems to be related to Template Haskell, as it doesn't happen if I remove `makeLensesWith` in `Query.hs`.\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14867Documentation targets are not working2019-07-07T18:15:16ZÖmer Sinan AğacanDocumentation targets are not workingNone of the documentation targets mentioned in the Wiki work: https://ghc.haskell.org/trac/ghc/wiki/Building/StandardTargets\#DocumentationTargets
As far as I can see there's no mention of how to build documentation in the entire wiki.
...None of the documentation targets mentioned in the Wiki work: https://ghc.haskell.org/trac/ghc/wiki/Building/StandardTargets\#DocumentationTargets
As far as I can see there's no mention of how to build documentation in the entire wiki.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"make targets for documentation not working","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"None of the documentation targets mentioned in the Wiki work: https://ghc.haskell.org/trac/ghc/wiki/Building/StandardTargets#DocumentationTargets\r\n\r\nAs far as I can see there's no mention of how to build documentation in the entire wiki.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14868-O -g breaks string literals2019-07-07T18:15:16Ztakano-akio-O -g breaks string literalsWith `foo.hs`:
```hs
main = print (4, "foo")
```
Compile it and run it like:
```
% ghc-stage2 -O -g foo.hs
% ./foo
(4,"\CANq@")
```
Note that the content of the string literal is broken, although the length is preserved.
With `-dcor...With `foo.hs`:
```hs
main = print (4, "foo")
```
Compile it and run it like:
```
% ghc-stage2 -O -g foo.hs
% ./foo
(4,"\CANq@")
```
Note that the content of the string literal is broken, although the length is preserved.
With `-dcore-lint`, the following error is produced:
```
*** Core Lint errors : in result of Simplifier ***
<no location info>: warning:
[RHS of ww2_s3hG :: Addr#]
Recursive or top-level binder has strict demand info: ww2_s3hG
Binder's demand info: <L,U>
```
The offending binding is:
```hs
ww2_s3hG :: Addr#
[LclId,
Unf=Unf{Src=<vanilla>, TopLvl=False, Value=True, ConLike=True,
WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 20 0}]
ww2_s3hG = src<foo.hs:1:18-22> "foo"#
```
Happens with ghc 8.4.1-rc1 and with HEAD (df2c3b33648).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"-O -g breaks string literals","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"With `foo.hs`:\r\n\r\n{{{#!hs\r\nmain = print (4, \"foo\")\r\n}}}\r\n\r\nCompile it and run it like:\r\n\r\n{{{\r\n% ghc-stage2 -O -g foo.hs\r\n% ./foo\r\n(4,\"\\CANq@\")\r\n}}}\r\n\r\nNote that the content of the string literal is broken, although the length is preserved.\r\n\r\nWith `-dcore-lint`, the following error is produced:\r\n\r\n{{{\r\n*** Core Lint errors : in result of Simplifier ***\r\n<no location info>: warning:\r\n [RHS of ww2_s3hG :: Addr#]\r\n Recursive or top-level binder has strict demand info: ww2_s3hG\r\n Binder's demand info: <L,U>\r\n}}}\r\n\r\nThe offending binding is:\r\n\r\n{{{#!hs\r\nww2_s3hG :: Addr#\r\n[LclId,\r\n Unf=Unf{Src=<vanilla>, TopLvl=False, Value=True, ConLike=True,\r\n WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 20 0}]\r\nww2_s3hG = src<foo.hs:1:18-22> \"foo\"#\r\n}}}\r\n\r\nHappens with ghc 8.4.1-rc1 and with HEAD (df2c3b33648).","type_of_failure":"OtherFailure","blocking":[]} -->8.4.2https://gitlab.haskell.org/ghc/ghc/-/issues/14869Documentation for isLiftedTypeKind is incorrect2019-07-07T18:15:15ZRyan ScottDocumentation for isLiftedTypeKind is incorrectI [noticed recently](https://github.com/ghc-proposals/ghc-proposals/pull/32#issuecomment-369252383) that Template Haskell reifies `Constraint` as `Type`:
```
$ ~/Software/ghc2/inplace/bin/ghc-stage2 --interactive
GHCi, version 8.5.20180...I [noticed recently](https://github.com/ghc-proposals/ghc-proposals/pull/32#issuecomment-369252383) that Template Haskell reifies `Constraint` as `Type`:
```
$ ~/Software/ghc2/inplace/bin/ghc-stage2 --interactive
GHCi, version 8.5.20180221: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
λ> :set -XTypeFamilies -XTemplateHaskell
λ> :m + Data.Kind Language.Haskell.TH
λ> type family Foo :: Constraint
λ> putStrLn $(reify ''Foo >>= stringE . pprint)
type family Ghci1.Foo :: *
```
The root of the issue can be traced back to the `isLiftedTypeKind` function, which `TcSplice` uses to distinguish `Type` from `Constraint`. At least, that's what its [documentation](http://git.haskell.org/ghc.git/blob/df2c3b3364834d2fd038192c89348fc50a2e0475:/compiler/types/TyCoRep.hs#l721) claims:
```
-- | This version considers Constraint to be distinct from *. Returns True
-- if the argument is equivalent to Type and False otherwise.
isLiftedTypeKind :: Kind -> Bool
isLiftedTypeKind = is_TYPE is_lifted
where
is_lifted (TyConApp lifted_rep []) = lifted_rep `hasKey` liftedRepDataConKey
is_lifted _ = False
```
However, in practice this claim about treating `Constraint` and `Type` as distinct is false:
```
$ ~/Software/ghc2/inplace/bin/ghc-stage2 --interactive -package ghc
GHCi, version 8.5.20180221: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
λ> :m + TyCoRep TysWiredIn
λ> isLiftedTypeKind liftedTypeKind
True
λ> isLiftedTypeKind constraintKind
True
```
Either we should change the implementation of `isLiftedTypeKind` to match the documentation's claim, or change the documentation.8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/14870Runtime performance regression in 8.42020-01-23T19:26:36ZBen GamariRuntime performance regression in 8.4varosi [reports](https://mail.haskell.org/pipermail/glasgow-haskell-users/2018-February/026701.html) that the code for his project is slower in 8.4.1 than 8.2.2:
> Yesterday I successfully compiled it with GHC 8.4.1-rc1. I got compiled ...varosi [reports](https://mail.haskell.org/pipermail/glasgow-haskell-users/2018-February/026701.html) that the code for his project is slower in 8.4.1 than 8.2.2:
> Yesterday I successfully compiled it with GHC 8.4.1-rc1. I got compiled it
> with 8.2.2 and 8.0.2 as well and ran tests for about a minute each on my
> Intel Core i7 machine on Windows 10 x64.
>
> I got this results:
>
> GHC 8.4.1-rc1
> Average time: 61.87s
>
> GHC 8.2.2
> Average time: 60.09s
>
> GHC 8.0.2
> Average time: 67.07s
We should look into why.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.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":"Runtime performance regression in 8.4","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"varosi [[https://mail.haskell.org/pipermail/glasgow-haskell-users/2018-February/026701.html|reports]] that the code for his project is slower in 8.4.1 than 8.2.2:\r\n\r\n> Yesterday I successfully compiled it with GHC 8.4.1-rc1. I got compiled it\r\n> with 8.2.2 and 8.0.2 as well and ran tests for about a minute each on my\r\n> Intel Core i7 machine on Windows 10 x64.\r\n>\r\n> I got this results:\r\n>\r\n> GHC 8.4.1-rc1\r\n> Average time: 61.87s\r\n>\r\n> GHC 8.2.2\r\n> Average time: 60.09s\r\n>\r\n> GHC 8.0.2\r\n> Average time: 67.07s\r\n>\r\n\r\nWe should look into why.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14871With process substitiution, ghc didn't read filedescriptor.2019-07-07T18:15:14ZoctaltreeWith process substitiution, ghc didn't read filedescriptor.I ran ghc with process substitution as filename but ghc couldn't read the filedescriptor.
I ran this script with bash and zsh, then I got the error.
```sh
#!/bin/sh
H='''
main = putStrLn "Hello, World!
'''
P='''
print("Hello, World!")
'...I ran ghc with process substitution as filename but ghc couldn't read the filedescriptor.
I ran this script with bash and zsh, then I got the error.
```sh
#!/bin/sh
H='''
main = putStrLn "Hello, World!
'''
P='''
print("Hello, World!")
'''
R='''
puts "Hello, World!"
'''
stack ghc -- --version
bash --version
zsh --version
cat --version
python --version
ruby --version
echo '-----------------------'
cat <(echo -n "$H")
echo '-----------------------'
stack ghc <(echo -n "$H")
echo '-----------------------'
python <(echo -n "$P")
ruby <(echo -n "$R")
```
```
The Glorious Glasgow Haskell Compilation System, version 8.2.2
GNU bash, バージョン 4.4.19(1)-release (x86_64-unknown-linux-gnu)
Copyright (C) 2016 Free Software Foundation, Inc.
ライセンス GPLv3+: GNU GPL バージョン 3 またはそれ以降 <http://gnu.org/licenses/gpl.html>
This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
zsh 5.4.2 (x86_64-unknown-linux-gnu)
cat (GNU coreutils) 8.29
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
作者 Torbjorn Granlund および Richard M. Stallman。
Python 3.6.4
ruby 2.5.0p0 (2017-12-25 revision 61468) [x86_64-linux]
-----------------------
main = putStrLn "Hello, World!
-----------------------
target ‘/dev/fd/63’ is not a module name or a source file
-----------------------
Hello, World!
/dev/fd/63: No such file or directory @ realpath_rec - /proc/4024/fd/pipe:[1855404] (Errno::ENOENT)
```
I already reported to ruby.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.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":"With process substitiution, ghc didn't read filedescriptor.","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I ran ghc with process substitution as filename but ghc couldn't read the filedescriptor.\r\nI ran this script with bash and zsh, then I got the error.\r\n{{{#!sh\r\n#!/bin/sh\r\nH='''\r\nmain = putStrLn \"Hello, World!\r\n'''\r\nP='''\r\nprint(\"Hello, World!\")\r\n'''\r\nR='''\r\nputs \"Hello, World!\"\r\n'''\r\n\r\nstack ghc -- --version\r\nbash --version\r\nzsh --version\r\ncat --version\r\npython --version\r\nruby --version\r\necho '-----------------------'\r\ncat <(echo -n \"$H\")\r\necho '-----------------------'\r\nstack ghc <(echo -n \"$H\")\r\necho '-----------------------'\r\npython <(echo -n \"$P\")\r\nruby <(echo -n \"$R\")\r\n}}}\r\n{{{\r\nThe Glorious Glasgow Haskell Compilation System, version 8.2.2\r\nGNU bash, バージョン 4.4.19(1)-release (x86_64-unknown-linux-gnu)\r\nCopyright (C) 2016 Free Software Foundation, Inc.\r\nライセンス GPLv3+: GNU GPL バージョン 3 またはそれ以降 <http://gnu.org/licenses/gpl.html>\r\n\r\nThis is free software; you are free to change and redistribute it.\r\nThere is NO WARRANTY, to the extent permitted by law.\r\nzsh 5.4.2 (x86_64-unknown-linux-gnu)\r\ncat (GNU coreutils) 8.29\r\nCopyright (C) 2017 Free Software Foundation, Inc.\r\nLicense GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.\r\nThis is free software: you are free to change and redistribute it.\r\nThere is NO WARRANTY, to the extent permitted by law.\r\n\r\n作者 Torbjorn Granlund および Richard M. Stallman。\r\nPython 3.6.4\r\nruby 2.5.0p0 (2017-12-25 revision 61468) [x86_64-linux]\r\n-----------------------\r\n\r\nmain = putStrLn \"Hello, World!\r\n-----------------------\r\ntarget ‘/dev/fd/63’ is not a module name or a source file\r\n-----------------------\r\nHello, World!\r\n/dev/fd/63: No such file or directory @ realpath_rec - /proc/4024/fd/pipe:[1855404] (Errno::ENOENT)\r\n}}}\r\n\r\nI already reported to ruby.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14872Hex Literals in GHC Core2019-07-07T18:15:14ZAndrew MartinHex Literals in GHC CoreSometimes, when I'm doing stuff that involves twiddling bits, it would be nicer to see integer literals in hexadecimal when I dump core with `-ddump-simpl`. For example, in a project I'm working on, I've got this:
```
detectNull :: Word...Sometimes, when I'm doing stuff that involves twiddling bits, it would be nicer to see integer literals in hexadecimal when I dump core with `-ddump-simpl`. For example, in a project I'm working on, I've got this:
```
detectNull :: Word -> Word
detectNull x = (x - repeatHexZeroOne) .&. complement x .&. repeatHexEightZero
detectArtifact :: Word -> Word -> Word
detectArtifact x artifact = detectNull (applyArtifact x artifact)
applyArtifact :: Word -> Word -> Word
applyArtifact = xor
repeatHexZeroOne :: Word
repeatHexZeroOne = div maxBound 255
repeatHexEightZero :: Word
repeatHexEightZero = 128 * (div maxBound 255 :: Word)
```
Once everything gets unboxed and constant-folding happens, in GHC core, the places where I used `repeatHexZeroOne` show `72340172838076673##` (on a 64-bit machine). This is accurate, but it would be nice I could give a flag to make it show `0x0101010101010101##` instead. This would make it easier for me to confirm that the arithmetic I used to generate a bit pattern actually generated what I thought it did. Admittedly, we'd probably want leading zeroes to get chopped off so that small integer literals didn't show up with 15 zeroes in front of them. So, realistically, it might show up as `0x101010101010101##`. Or maybe it could always to padded with leading zeroes until the length was a power of two. Anyway, not important, but I thought it would be nice to have. Possible flag name: `-ddump-hex-literals`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | lowest |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Hex Literals in GHC Core","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Sometimes, when I'm doing stuff that involves twiddling bits, it would be nicer to see integer literals in hexadecimal when I dump core with `-ddump-simpl`. For example, in a project I'm working on, I've got this:\r\n\r\n{{{\r\ndetectNull :: Word -> Word\r\ndetectNull x = (x - repeatHexZeroOne) .&. complement x .&. repeatHexEightZero\r\n\r\ndetectArtifact :: Word -> Word -> Word\r\ndetectArtifact x artifact = detectNull (applyArtifact x artifact)\r\n\r\napplyArtifact :: Word -> Word -> Word\r\napplyArtifact = xor\r\n\r\nrepeatHexZeroOne :: Word\r\nrepeatHexZeroOne = div maxBound 255\r\n\r\nrepeatHexEightZero :: Word\r\nrepeatHexEightZero = 128 * (div maxBound 255 :: Word)\r\n}}}\r\n\r\nOnce everything gets unboxed and constant-folding happens, in GHC core, the places where I used `repeatHexZeroOne` show `72340172838076673##` (on a 64-bit machine). This is accurate, but it would be nice I could give a flag to make it show `0x0101010101010101##` instead. This would make it easier for me to confirm that the arithmetic I used to generate a bit pattern actually generated what I thought it did. Admittedly, we'd probably want leading zeroes to get chopped off so that small integer literals didn't show up with 15 zeroes in front of them. So, realistically, it might show up as `0x101010101010101##`. Or maybe it could always to padded with leading zeroes until the length was a power of two. Anyway, not important, but I thought it would be nice to have. Possible flag name: `-ddump-hex-literals`.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Andrew MartinAndrew Martinhttps://gitlab.haskell.org/ghc/ghc/-/issues/14873The well-kinded type invariant (in TcType)2021-09-07T15:47:33ZRyan ScottThe well-kinded type invariant (in TcType)(Originally noticed [here](https://travis-ci.org/goldfirere/singletons/jobs/347945148#L1179).)
The following program typechecks on GHC 8.2.2 on GHC 8.4.1, but panics on GHC HEAD:
```hs
{-# LANGUAGE RankNTypes #-}
{-# LANGUAGE ScopedTyp...(Originally noticed [here](https://travis-ci.org/goldfirere/singletons/jobs/347945148#L1179).)
The following program typechecks on GHC 8.2.2 on GHC 8.4.1, but panics on GHC HEAD:
```hs
{-# LANGUAGE RankNTypes #-}
{-# LANGUAGE ScopedTypeVariables #-}
{-# LANGUAGE TypeApplications #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE TypeInType #-}
{-# LANGUAGE TypeOperators #-}
module Bug where
import Data.Kind (Type)
data family Sing (a :: k)
newtype instance Sing (f :: k1 ~> k2) =
SLambda { applySing :: forall t. Sing t -> Sing (Apply f t) }
data TyFun :: Type -> Type -> Type
type a ~> b = TyFun a b -> Type
infixr 0 ~>
type family Apply (f :: k1 ~> k2) (x :: k1) :: k2
class SingI (a :: k) where
sing :: Sing a
data ColSym1 :: f a -> a ~> Bool
type instance Apply (ColSym1 x) y = Col x y
class PColumn (f :: Type -> Type) where
type Col (x :: f a) (y :: a) :: Bool
class SColumn (f :: Type -> Type) where
sCol :: forall (x :: f a) (y :: a).
Sing x -> Sing y -> Sing (Col x y :: Bool)
instance (SColumn f, SingI x) => SingI (ColSym1 (x :: f a) :: a ~> Bool) where
sing = SLambda (sCol (sing @_ @x))
```
```
$ /opt/ghc/head/bin/ghc Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
ghc: panic! (the 'impossible' happened)
(GHC version 8.5.20180201 for x86_64-unknown-linux):
piResultTy
k_aZU[tau:1]
(a_aW8[sk:1] |> <*>_N)
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable
pprPanic, called at compiler/types/Type.hs:947:35 in ghc:Type
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC HEAD regression (piResultTy)","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"(Originally noticed [https://travis-ci.org/goldfirere/singletons/jobs/347945148#L1179 here].)\r\n\r\nThe following program typechecks on GHC 8.2.2 on GHC 8.4.1, but panics on GHC HEAD:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE RankNTypes #-}\r\n{-# LANGUAGE ScopedTypeVariables #-}\r\n{-# LANGUAGE TypeApplications #-}\r\n{-# LANGUAGE TypeFamilies #-}\r\n{-# LANGUAGE TypeInType #-}\r\n{-# LANGUAGE TypeOperators #-}\r\nmodule Bug where\r\n\r\nimport Data.Kind (Type)\r\n\r\ndata family Sing (a :: k)\r\n\r\nnewtype instance Sing (f :: k1 ~> k2) =\r\n SLambda { applySing :: forall t. Sing t -> Sing (Apply f t) }\r\n\r\ndata TyFun :: Type -> Type -> Type\r\ntype a ~> b = TyFun a b -> Type\r\ninfixr 0 ~>\r\ntype family Apply (f :: k1 ~> k2) (x :: k1) :: k2\r\n\r\nclass SingI (a :: k) where\r\n sing :: Sing a\r\n\r\ndata ColSym1 :: f a -> a ~> Bool\r\ntype instance Apply (ColSym1 x) y = Col x y\r\n\r\nclass PColumn (f :: Type -> Type) where\r\n type Col (x :: f a) (y :: a) :: Bool\r\n\r\nclass SColumn (f :: Type -> Type) where\r\n sCol :: forall (x :: f a) (y :: a).\r\n Sing x -> Sing y -> Sing (Col x y :: Bool)\r\n\r\ninstance (SColumn f, SingI x) => SingI (ColSym1 (x :: f a) :: a ~> Bool) where\r\n sing = SLambda (sCol (sing @_ @x))\r\n}}}\r\n\r\n{{{\r\n$ /opt/ghc/head/bin/ghc Bug.hs\r\n[1 of 1] Compiling Bug ( Bug.hs, Bug.o )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.5.20180201 for x86_64-unknown-linux):\r\n piResultTy\r\n k_aZU[tau:1]\r\n (a_aW8[sk:1] |> <*>_N)\r\n Call stack:\r\n CallStack (from HasCallStack):\r\n callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable\r\n pprPanic, called at compiler/types/Type.hs:947:35 in ghc:Type\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->9.2.1Richard Eisenbergrae@richarde.devRichard Eisenbergrae@richarde.devhttps://gitlab.haskell.org/ghc/ghc/-/issues/14874Trac: TypeError: can't compare datetime.datetime to str2019-07-07T18:15:14ZSimon JakobiTrac: TypeError: can't compare datetime.datetime to strThis problem appears when sorting closed tickets by their "modified" field. [Example](https://ghc.haskell.org/trac/ghc/query?status=closed&col=id&col=changetime&desc=1&order=changetime). The source of the problem appears to be that a few...This problem appears when sorting closed tickets by their "modified" field. [Example](https://ghc.haskell.org/trac/ghc/query?status=closed&col=id&col=changetime&desc=1&order=changetime). The source of the problem appears to be that a few old tickets don't have a "modified" time (changetime). Instead their "changetime" field seems to be set to the empty string.
Apparently similar issues have been known to the Trac developers for a while: https://trac.edgewall.org/ticket/12029.
#### How to Reproduce
While doing a GET operation on `/query`, Trac issued an internal error.
*(please provide additional details here)*
Request parameters:
```
{u'col': [u'id', u'changetime'],
u'desc': u'1',
u'order': u'changetime',
u'page': u'2',
u'status': u'closed'}
```
User agent: `Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/64.0.3282.167 Chrome/64.0.3282.167 Safari/537.36`
#### System Information
*System information not available*
#### Enabled Plugins
*Plugin information not available*
#### Interface Customization
*Interface customization information not available*
#### Python Traceback
```
Traceback (most recent call last):
File "/usr/local/lib/python2.7/dist-packages/trac/web/main.py", line 623, in _dispatch_request
dispatcher.dispatch(req)
File "/usr/local/lib/python2.7/dist-packages/trac/web/main.py", line 239, in dispatch
resp = chosen_handler.process_request(req)
File "/usr/local/lib/python2.7/dist-packages/trac/ticket/query.py", line 1000, in process_request
return self.display_html(req, query)
File "/usr/local/lib/python2.7/dist-packages/trac/ticket/query.py", line 1117, in display_html
data = query.template_data(context, tickets, orig_list, orig_time, req)
File "/usr/local/lib/python2.7/dist-packages/trac/ticket/query.py", line 776, in template_data
elif ticket['changetime'] > orig_time:
TypeError: can't compare datetime.datetime to str
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Trac & Git |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Trac: TypeError: can't compare datetime.datetime to str","status":"New","operating_system":"","component":"Trac & Git","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"hvr"},"version":"","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This problem appears when sorting closed tickets by their \"modified\" field. [https://ghc.haskell.org/trac/ghc/query?status=closed&col=id&col=changetime&desc=1&order=changetime Example]. The source of the problem appears to be that a few old tickets don't have a \"modified\" time (changetime). Instead their \"changetime\" field seems to be set to the empty string.\r\n\r\nApparently similar issues have been known to the Trac developers for a while: https://trac.edgewall.org/ticket/12029.\r\n\r\n==== How to Reproduce ====\r\n\r\nWhile doing a GET operation on `/query`, Trac issued an internal error.\r\n\r\n''(please provide additional details here)''\r\n\r\nRequest parameters:\r\n{{{\r\n{u'col': [u'id', u'changetime'],\r\n u'desc': u'1',\r\n u'order': u'changetime',\r\n u'page': u'2',\r\n u'status': u'closed'}\r\n}}}\r\n\r\nUser agent: `Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/64.0.3282.167 Chrome/64.0.3282.167 Safari/537.36`\r\n\r\n==== System Information ====\r\n''System information not available''\r\n\r\n==== Enabled Plugins ====\r\n''Plugin information not available''\r\n\r\n==== Interface Customization ====\r\n''Interface customization information not available''\r\n\r\n==== Python Traceback ====\r\n{{{\r\nTraceback (most recent call last):\r\n File \"/usr/local/lib/python2.7/dist-packages/trac/web/main.py\", line 623, in _dispatch_request\r\n dispatcher.dispatch(req)\r\n File \"/usr/local/lib/python2.7/dist-packages/trac/web/main.py\", line 239, in dispatch\r\n resp = chosen_handler.process_request(req)\r\n File \"/usr/local/lib/python2.7/dist-packages/trac/ticket/query.py\", line 1000, in process_request\r\n return self.display_html(req, query)\r\n File \"/usr/local/lib/python2.7/dist-packages/trac/ticket/query.py\", line 1117, in display_html\r\n data = query.template_data(context, tickets, orig_list, orig_time, req)\r\n File \"/usr/local/lib/python2.7/dist-packages/trac/ticket/query.py\", line 776, in template_data\r\n elif ticket['changetime'] > orig_time:\r\nTypeError: can't compare datetime.datetime to str\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->Herbert Valerio Riedelhvr@gnu.orgHerbert Valerio Riedelhvr@gnu.org