GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T19:05:17Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/3119Make ghc-6.10 use a non-executable stack (by bumping libffi)2019-07-07T19:05:17Zkolmodin@dtek.chalmers.seMake ghc-6.10 use a non-executable stack (by bumping libffi)Attached patch:
```
Mon Mar 23 08:08:32 CET 2009 Lennart Kolmodin <kolmodin@gentoo.org>
* Replace libffi 3.0.4 with libffi 3.0.8
Use the latest version of libffi, which compiles with a non-executable
stack. libffi 3.0.4 was the s...Attached patch:
```
Mon Mar 23 08:08:32 CET 2009 Lennart Kolmodin <kolmodin@gentoo.org>
* Replace libffi 3.0.4 with libffi 3.0.8
Use the latest version of libffi, which compiles with a non-executable
stack. libffi 3.0.4 was the single piece of ghc using the executable stack,
forcing the whole toolchain to use executable stacks (including all
executables it compiled).
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.1 |
| 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":"Make ghc-6.10 use a non-executable stack (by bumping libffi)","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Attached patch:\r\n\r\n{{{\r\nMon Mar 23 08:08:32 CET 2009 Lennart Kolmodin <kolmodin@gentoo.org>\r\n * Replace libffi 3.0.4 with libffi 3.0.8\r\n Use the latest version of libffi, which compiles with a non-executable\r\n stack. libffi 3.0.4 was the single piece of ghc using the executable stack,\r\n forcing the whole toolchain to use executable stacks (including all\r\n executables it compiled).\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3117via C compilation of module importing log1p from <math.h> fails.2023-01-30T15:43:00ZBertram Felgenhauervia C compilation of module importing log1p from <math.h> fails.This module fails to compile:
```
{-# LANGUAGE ForeignFunctionInterface #-}
{-# OPTIONS_GHC -fvia-C #-}
foreign import ccall unsafe "math.h log1p" log1p :: Double -> Double
main = print (log1p 1)
```
With errors like these:
```
/tmp...This module fails to compile:
```
{-# LANGUAGE ForeignFunctionInterface #-}
{-# OPTIONS_GHC -fvia-C #-}
foreign import ccall unsafe "math.h log1p" log1p :: Double -> Double
main = print (log1p 1)
```
With errors like these:
```
/tmp/ghc25313_0/ghc25313_0.hc: In function 'svD_entry':
/tmp/ghc25313_0/ghc25313_0.hc:66:0:
error: 'log1p' redeclared as different kind of symbol
/usr/include/bits/mathcalls.h:132:0:
error: previous declaration of 'log1p' was here
```
This is affecting the `logfloat` package on hackage.
The reason is that `ghc` doesn't generate proper prototypes for foreign imports, but that's probably ok as long as no conflicting prototypes are defined for the same function.
To accomplish this, `ghc` treats functions from `math.h` specially, but a number of these functions like `log1p` are not recognized. See `compiler/cmm/CLabel.hs`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"via C compilation of module importing log1p from <math.h> fails.","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This module fails to compile:\r\n{{{\r\n{-# LANGUAGE ForeignFunctionInterface #-}\r\n{-# OPTIONS_GHC -fvia-C #-}\r\n\r\nforeign import ccall unsafe \"math.h log1p\" log1p :: Double -> Double\r\n\r\nmain = print (log1p 1)\r\n}}}\r\nWith errors like these:\r\n{{{\r\n/tmp/ghc25313_0/ghc25313_0.hc: In function 'svD_entry':\r\n\r\n/tmp/ghc25313_0/ghc25313_0.hc:66:0:\r\n error: 'log1p' redeclared as different kind of symbol\r\n\r\n/usr/include/bits/mathcalls.h:132:0:\r\n error: previous declaration of 'log1p' was here\r\n}}}\r\nThis is affecting the {{{logfloat}}} package on hackage.\r\n\r\nThe reason is that {{{ghc}}} doesn't generate proper prototypes for foreign imports, but that's probably ok as long as no conflicting prototypes are defined for the same function.\r\n\r\nTo accomplish this, {{{ghc}}} treats functions from {{{math.h}}} specially, but a number of these functions like {{{log1p}}} are not recognized. See {{{compiler/cmm/CLabel.hs}}}.","type_of_failure":"OtherFailure","blocking":[]} -->6.10.2Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3102The impossible happened with implicit parameters2019-07-07T19:05:23ZAshley YakeleyThe impossible happened with implicit parameters```
{-# OPTIONS -XImplicitParams -XRankNTypes #-}
module Bug where
t :: forall a. ((?p :: Int) => a) -> String
t _ = "Hello"
f :: (forall a. a -> String) -> Int
f _ = 3
result :: Int
result = f t
```
```
$ ghc -c Bug.hs
ghc: panic! (...```
{-# OPTIONS -XImplicitParams -XRankNTypes #-}
module Bug where
t :: forall a. ((?p :: Int) => a) -> String
t _ = "Hello"
f :: (forall a. a -> String) -> Int
f _ = 3
result :: Int
result = f t
```
```
$ ghc -c Bug.hs
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.1 for x86_64-unknown-linux):
TcTyFuns.flattenType: unexpected PredType
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"The impossible happened with implicit parameters","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\n{-# OPTIONS -XImplicitParams -XRankNTypes #-}\r\nmodule Bug where\r\n\r\nt :: forall a. ((?p :: Int) => a) -> String\r\nt _ = \"Hello\"\r\n\r\nf :: (forall a. a -> String) -> Int\r\nf _ = 3\r\n\r\nresult :: Int\r\nresult = f t\r\n}}}\r\n\r\n{{{\r\n$ ghc -c Bug.hs\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 6.10.1 for x86_64-unknown-linux):\r\n\tTcTyFuns.flattenType: unexpected PredType\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3101GHC crashes on synonym family in a rank-n type2019-07-07T19:05:23ZMartijnVanSteenbergenGHC crashes on synonym family in a rank-n type```
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE RankNTypes #-}
module Boom where
type family F a :: *
data Boom = Boom (forall a. F a)
deriving Show
```
When loading the above compilation unit into GHCi, it crashes with:
```
ghc: p...```
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE RankNTypes #-}
module Boom where
type family F a :: *
data Boom = Boom (forall a. F a)
deriving Show
```
When loading the above compilation unit into GHCi, it crashes with:
```
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.1 for i386-apple-darwin):
TcTyFuns.flattenType: synonym family in a rank-n type
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC crashes on synonym family in a rank-n type","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\n{-# LANGUAGE TypeFamilies #-}\r\n{-# LANGUAGE RankNTypes #-}\r\n\r\nmodule Boom where\r\n\r\ntype family F a :: *\r\n\r\ndata Boom = Boom (forall a. F a)\r\n deriving Show\r\n}}}\r\n\r\nWhen loading the above compilation unit into GHCi, it crashes with:\r\n\r\n{{{\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 6.10.1 for i386-apple-darwin):\r\n\tTcTyFuns.flattenType: synonym family in a rank-n type\r\n}}}\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3100GHC Panic "reifyType PredTy" in HAppS.Data.IxSet.inferIxSet2019-07-07T19:05:24ZmightybyteGHC Panic "reifyType PredTy" in HAppS.Data.IxSet.inferIxSet```
Exception when trying to run compile-time code:
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.1 for x86_64-unknown-linux):
reifyType PredTy
```
Code reproducing this bug can be found at:
http://hpaste.org/fastcgi...```
Exception when trying to run compile-time code:
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.1 for x86_64-unknown-linux):
reifyType PredTy
```
Code reproducing this bug can be found at:
http://hpaste.org/fastcgi/hpaste.fcgi/view?id=2419
Marked as critical because I haven't found a workaround yet.6.12 branchIan Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3097Parser doesn't support doc comments on type aliases2019-07-07T19:05:25ZwaernParser doesn't support doc comments on type aliasesI want to add comments to type synonyms in order to fix the following Haddock bug, but I need some help.
> http://trac.haskell.org/haddock/ticket/9
In the parser, the rule for type synonyms is:
```
'type' type '=' ctype ...I want to add comments to type synonyms in order to fix the following Haddock bug, but I need some help.
> http://trac.haskell.org/haddock/ticket/9
In the parser, the rule for type synonyms is:
```
'type' type '=' ctype
```
Types with comments are already defined as `ctypedoc` and used for top-level types.
So it is tempting to just change `ctype` in the above line to `ctypedoc`. Indeed, I think originally `ctypedoc` was defined exactly as `ctype`, modulo comments. However, since then `ctype` has changed.
The differences are:
- `ctype` disallows foralls/contexts after a contex implication (=\>).
- `ctype` allows implicit parameters outside contexts. Seems to be disallowed by GHC later (after parsing).
- `ctype` allows type equalities (\~) outside contexts. Seems to be disallowed later also.
I haven't seen any further differences (besides comments).
Can I just change type synonyms to use `ctypedoc` without any other changes? Or do we need the features of `ctype` there? If so, then changing `ctypedoc` into just a commented version of `ctype` would not work as a solution, since then syntax like this (from base:GHC/Desugar.hs) breaks:
```
(>>>) :: forall arr. Arrow arr => forall a b c. arr a b -> arr b c -> arr a c
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Parser doesn't support doc comments on type aliases","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":["Haddock"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I want to add comments to type synonyms in order to fix the following Haddock bug, but I need some help.\r\n\r\n http://trac.haskell.org/haddock/ticket/9\r\n\r\nIn the parser, the rule for type synonyms is:\r\n{{{\r\n'type' type '=' ctype \r\n}}}\r\n\r\nTypes with comments are already defined as `ctypedoc` and used for top-level types.\r\n\r\nSo it is tempting to just change `ctype` in the above line to `ctypedoc`. Indeed, I think originally `ctypedoc` was defined exactly as `ctype`, modulo comments. However, since then `ctype` has changed.\r\n\r\nThe differences are:\r\n\r\n * `ctype` disallows foralls/contexts after a contex implication (=>).\r\n * `ctype` allows implicit parameters outside contexts. Seems to be disallowed by GHC later (after parsing).\r\n * `ctype` allows type equalities (~) outside contexts. Seems to be disallowed later also.\r\n\r\nI haven't seen any further differences (besides comments).\r\n\r\nCan I just change type synonyms to use `ctypedoc` without any other changes? Or do we need the features of `ctype` there? If so, then changing `ctypedoc` into just a commented version of `ctype` would not work as a solution, since then syntax like this (from base:GHC/Desugar.hs) breaks:\r\n{{{\r\n(>>>) :: forall arr. Arrow arr => forall a b c. arr a b -> arr b c -> arr a c\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->6.10 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/3095ghc panic during parsing2019-07-07T19:05:25Zphilip.weaver@gmail.comghc panic during parsingFor the following piece of code
```
class Bla (forall x . x) where
```
the ghc parser yields the appropriate error
```
Forall type not allowed as type parameter
```
However, if you change the code to this
```
class Bla (forall x . x...For the following piece of code
```
class Bla (forall x . x) where
```
the ghc parser yields the appropriate error
```
Forall type not allowed as type parameter
```
However, if you change the code to this
```
class Bla (forall x . x :: *) where
```
Then ghc does this:
```
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.1 for i386-apple-darwin):
parser/RdrHsSyn.lhs:(525,4)-(548,64): Non-exhaustive patterns in function collect
```
This is reproducible on ghc-6.8.3 and ghc-6.10.1.
I have only tried it on Mac OS X, x86.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Parser) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghc panic during parsing","status":"New","operating_system":"","component":"Compiler (Parser)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"For the following piece of code\r\n{{{\r\nclass Bla (forall x . x) where\r\n}}}\r\n\r\nthe ghc parser yields the appropriate error\r\n{{{\r\nForall type not allowed as type parameter\r\n}}}\r\n\r\nHowever, if you change the code to this\r\n{{{\r\nclass Bla (forall x . x :: *) where\r\n}}}\r\n\r\nThen ghc does this:\r\n{{{\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 6.10.1 for i386-apple-darwin):\r\n\tparser/RdrHsSyn.lhs:(525,4)-(548,64): Non-exhaustive patterns in function collect\r\n}}}\r\n\r\nThis is reproducible on ghc-6.8.3 and ghc-6.10.1.\r\n\r\nI have only tried it on Mac OS X, x86.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3093-osuf and stub files results in incorrect extension2019-07-07T19:05:26ZNeil Mitchell-osuf and stub files results in incorrect extensionUsing the example from the manual 9.2.1 on stub files:
```
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.10.1
$ ghc --make Foo.hs -fffi -osuf foo.bar
[1 of 1] Compiling Foo ( Foo.hs, Foo.foo.ba...Using the example from the manual 9.2.1 on stub files:
```
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.10.1
$ ghc --make Foo.hs -fffi -osuf foo.bar
[1 of 1] Compiling Foo ( Foo.hs, Foo.foo.bar )
```
This generates the file `Foo.foo_stub.bar`, which is clearly wrong. I'd have expected `Foo_stub.foo.bar`. Note that the command works if no . is placed in the suffix.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ndmitchell@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"-osuf and stub files results in incorrect extension","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ndmitchell@gmail.com"],"type":"Bug","description":"Using the example from the manual 9.2.1 on stub files:\r\n\r\n{{{\r\n$ ghc --version\r\nThe Glorious Glasgow Haskell Compilation System, version 6.10.1\r\n\r\n$ ghc --make Foo.hs -fffi -osuf foo.bar\r\n[1 of 1] Compiling Foo ( Foo.hs, Foo.foo.bar )\r\n}}}\r\n\r\nThis generates the file {{{Foo.foo_stub.bar}}}, which is clearly wrong. I'd have expected {{{Foo_stub.foo.bar}}}. Note that the command works if no . is placed in the suffix.","type_of_failure":"OtherFailure","blocking":[]} -->6.10.2Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3092algebraic data types can be extended by data instance declarations2019-07-07T19:05:26ZWolfgang Jeltschalgebraic data types can be extended by data instance declarationsThe following program is accepted by GHC:
```
{-# LANGUAGE TypeFamilies #-}
data T a = C
data instance T Int = CInt
data instance T Bool = CBool
```
I think, it shouldn’t.
<details><summary>Trac metadata</summary>
| Trac field ...The following program is accepted by GHC:
```
{-# LANGUAGE TypeFamilies #-}
data T a = C
data instance T Int = CInt
data instance T Bool = CBool
```
I think, it shouldn’t.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | g9ks157k@acme.softbase.org |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"algebraic data types can be extended by data instance declarations","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["g9ks157k@acme.softbase.org"],"type":"Bug","description":"The following program is accepted by GHC:\r\n{{{\r\n{-# LANGUAGE TypeFamilies #-}\r\n\r\ndata T a = C\r\n\r\ndata instance T Int = CInt\r\n\r\ndata instance T Bool = CBool\r\n}}}\r\nI think, it shouldn’t.","type_of_failure":"OtherFailure","blocking":[]} -->Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3086Exception if temp path has national symbols2019-07-07T19:05:28ZTonalException if temp path has national symbolsEnvironment: Windows Vista Home Ru + sp1 ghc 6.10.1
Code for reproduced (file tst.hs):
`/x-haskell
import System.Directory
main = do
cwd <- getTemporaryDirectory
putStrLn cwd
setCurrentDirectory cwd
`
Console session:
```
C:\Lan...Environment: Windows Vista Home Ru + sp1 ghc 6.10.1
Code for reproduced (file tst.hs):
`/x-haskell
import System.Directory
main = do
cwd <- getTemporaryDirectory
putStrLn cwd
setCurrentDirectory cwd
`
Console session:
```
C:\Lang\test\haskell\Тест>ghc --make tst.hs
[1 of 1] Compiling Main ( tst.hs, tst.o )
Linking tst.exe ...
C:\Lang\test\haskell\Тест>set TMP=C:\Lang\test\haskell\Тест
C:\Lang\test\haskell\Тест>tst.exe
C:\Lang\test\haskell\╥хёЄ\
tst.exe: SetCurrentDirectory: does not exist (�5 C405BAO =09B8 C:070==K9 D09;.)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/directory |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Exception if temp path has national symbols","status":"New","operating_system":"","component":"libraries/directory","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Environment: Windows Vista Home Ru + sp1 ghc 6.10.1\r\n\r\nCode for reproduced (file tst.hs):\r\n{{{\r\n#!text/x-haskell\r\nimport System.Directory\r\n\r\nmain = do\r\n cwd <- getTemporaryDirectory\r\n putStrLn cwd\r\n setCurrentDirectory cwd\r\n}}}\r\nConsole session:\r\n{{{\r\nC:\\Lang\\test\\haskell\\Тест>ghc --make tst.hs\r\n[1 of 1] Compiling Main ( tst.hs, tst.o )\r\nLinking tst.exe ...\r\n\r\nC:\\Lang\\test\\haskell\\Тест>set TMP=C:\\Lang\\test\\haskell\\Тест\r\nC:\\Lang\\test\\haskell\\Тест>tst.exe\r\nC:\\Lang\\test\\haskell\\╥хёЄ\\\r\ntst.exe: SetCurrentDirectory: does not exist (\u001d5 C405BAO =09B8 C:070==K9 D09;.)\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.10.2Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3079LANGUAGE pragma fails if it falls on a 1024-byte boundary2019-07-07T19:05:29ZDeewiantLANGUAGE pragma fails if it falls on a 1024-byte boundaryPutting too much whitespace and/or comment text before a LANGUAGE pragma seems to cause parsing it to fail. In the following, the closing `}` of the comment is byte 1025. Perhaps the whole thing is expected to fit into the first 1024 byt...Putting too much whitespace and/or comment text before a LANGUAGE pragma seems to cause parsing it to fail. In the following, the closing `}` of the comment is byte 1025. Perhaps the whole thing is expected to fit into the first 1024 bytes or be wholly inside an aligned 1024-byte range?
```
-- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
-- xxxxxxxxxxxxxxxxxxxxxxxx
-- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
-- xxxxxxxxxxxxxxxxxxxxxxx
-- xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
--
--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
--
--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
--
--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
{-# LANGUAGE ScopedTypeVariables #-}
main = return ()
```
Removing absolutely anything prior to the start of the LANGUAGE pragma will make it work: one of the exes, an entire line, any whitespace, whatever.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Parser) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"LANGUAGE pragma fails if preceded by too many comments","status":"New","operating_system":"","component":"Compiler (Parser)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Putting too much whitespace and/or comment text before a LANGUAGE pragma seems to cause parsing it to fail. In the following, the closing `}` of the comment is byte 1025. Perhaps the whole thing is expected to fit into the first 1024 bytes or be wholly inside an aligned 1024-byte range?\r\n\r\n{{{\r\n-- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\r\n-- xxxxxxxxxxxxxxxxxxxxxxxx\r\n-- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\r\n-- xxxxxxxxxxxxxxxxxxxxxxx\r\n-- xxxxxxxxxxxxxxxxxxxxxxxxxxxxx\r\n--\r\n--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\r\n--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\r\n--\r\n--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\r\n--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\r\n--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\r\n--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\r\n--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\r\n--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\r\n--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\r\n--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\r\n--\r\n--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\r\n\r\n{-# LANGUAGE ScopedTypeVariables #-}\r\nmain = return ()\r\n}}}\r\n\r\nRemoving absolutely anything prior to the start of the LANGUAGE pragma will make it work: one of the exes, an entire line, any whitespace, whatever.","type_of_failure":"OtherFailure","blocking":[]} -->6.10.2Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3069misspelled word in description of syntax extensions: s/enerated/enumerated/2019-07-07T19:05:32Znr@eecs.harvard.edumisspelled word in description of syntax extensions: s/enerated/enumerated/In http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html there is a misspelling.
s/enerated/enumerated/
as in `the enumerated sequence [Monday..]`
A quick wander about the Wiki didn't lead me to the place where the...In http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html there is a misspelling.
s/enerated/enumerated/
as in `the enumerated sequence [Monday..]`
A quick wander about the Wiki didn't lead me to the place where the master source for GHC doco is stored. If someone can tell me I can fix this sort of thing myself. (And in fact if someone wants to email me now, I can retire this ticket myself.)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 6.11 |
| 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":"misspelled word in description of syntax extensions: s/enerated/enumerated/","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html there is a misspelling.\r\n\r\ns/enerated/enumerated/\r\n\r\nas in {{{the enumerated sequence [Monday..]}}}\r\n\r\nA quick wander about the Wiki didn't lead me to the place where the master source for GHC doco is stored. If someone can tell me I can fix this sort of thing myself. (And in fact if someone wants to email me now, I can retire this ticket myself.)","type_of_failure":"OtherFailure","blocking":[]} -->Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3067GHCi panics with 'initTc:LIE' while :stepping on code with funny types2019-07-07T19:05:32ZmnislaihGHCi panics with 'initTc:LIE' while :stepping on code with funny typesThis is due to runtime type reconstruction not dealing correctly with type functions.
I managed to come up a minimal example.
```
{-# LANGUAGE TypeFamilies #-}
type family Id x
type instance Id Int = Int
type instance Id Bool = Bool
...This is due to runtime type reconstruction not dealing correctly with type functions.
I managed to come up a minimal example.
```
{-# LANGUAGE TypeFamilies #-}
type family Id x
type instance Id Int = Int
type instance Id Bool = Bool
class Convert x y where convert :: x -> y
instance Convert x x where convert = id
f :: Convert a (Id a) => a -> Id a
f x = convert x
g :: Convert a (Id a) => a -> Id a
g x = let x' = f x in x'
}
{{{
[1 of 1] Compiling Main ( ../code/debuggerExamples/lie.hs, interpreted )
Ok, modules loaded: Main.
*Main GOA> :step g False
:step g False
Stopped at ../code/debuggerExamples/lie.hs:15:0-23
_result :: Id a = _
14 g :: Convert a (Id a) => a -> Id a
15 g x = let x' = f x in x'
^^^^^^^^^^^^^^^^^^^^^^^^
[../code/debuggerExamples/lie.hs:15:0-23] *Main GOA> :step
:step
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.1 for i386-apple-darwin):
initTc:LIE
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHCi panics with 'initTc:LIE' while :stepping on code with funny types","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This is due to runtime type reconstruction not dealing correctly with type functions.\r\n\r\nI managed to come up a minimal example.\r\n{{{\r\n{-# LANGUAGE TypeFamilies #-}\r\n\r\ntype family Id x\r\ntype instance Id Int = Int\r\ntype instance Id Bool = Bool\r\n\r\nclass Convert x y where convert :: x -> y\r\ninstance Convert x x where convert = id\r\n\r\nf :: Convert a (Id a) => a -> Id a\r\nf x = convert x\r\n\r\ng :: Convert a (Id a) => a -> Id a\r\ng x = let x' = f x in x'\r\n}\r\n{{{\r\n[1 of 1] Compiling Main ( ../code/debuggerExamples/lie.hs, interpreted )\r\nOk, modules loaded: Main.\r\n*Main GOA> :step g False\r\n:step g False\r\nStopped at ../code/debuggerExamples/lie.hs:15:0-23\r\n_result :: Id a = _\r\n14 g :: Convert a (Id a) => a -> Id a\r\n15 g x = let x' = f x in x'\r\n ^^^^^^^^^^^^^^^^^^^^^^^^\r\n[../code/debuggerExamples/lie.hs:15:0-23] *Main GOA> :step\r\n:step\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 6.10.1 for i386-apple-darwin):\r\n\tinitTc:LIE\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3039strange space usage2019-07-07T19:05:45ZIan Lynagh <igloo@earth.li>strange space usageThis program:
```
module Main (main) where
import System.IO.Unsafe
main :: IO ()
main = do writeFile "wibbleflibble" (replicate 100 'z')
bs <- getCs $ g $ replicate 1000000 "flibble"
print $ last bs
getCs :: [File...This program:
```
module Main (main) where
import System.IO.Unsafe
main :: IO ()
main = do writeFile "wibbleflibble" (replicate 100 'z')
bs <- getCs $ g $ replicate 1000000 "flibble"
print $ last bs
getCs :: [FilePath] -> IO String
getCs [] = return ""
getCs (c : cs) = do x <- readFile c
xs <- unsafeInterleaveIO $ getCs cs
return (x ++ xs)
g :: [FilePath] -> [FilePath]
g is = map f is
f :: FilePath -> FilePath
f fn = "wibble" ++ fn
```
when run:
```
$ ghc -fforce-recomp -Wall --make -O2 -prof -auto-all z.hs -o z
$ ./z +RTS -h -p
```
shows that around 100k is used by `f` (`h.png`). Running with
```
$ ./z +RTS -hcf -hy -p
```
shows that it is all of type `[]` (`hcf_hy.png`). That seems like a large amount of space for a 13 character filename, so it smells to me like something is wrong somewhere.
If we inline `g`:
```
module Main (main) where
import System.IO.Unsafe
main :: IO ()
main = do writeFile "wibbleflibble" (replicate 100 'z')
bs <- getCs $ map f $ replicate 1000000 "flibble"
print $ last bs
getCs :: [FilePath] -> IO String
getCs [] = return ""
getCs (c : cs) = do x <- readFile c
xs <- unsafeInterleaveIO $ getCs cs
return (x ++ xs)
f :: FilePath -> FilePath
f fn = "wibble" ++ fn
```
then it all disappears (`h2.png`).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"strange space usage","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This program:\r\n{{{\r\nmodule Main (main) where\r\n\r\nimport System.IO.Unsafe\r\n\r\nmain :: IO ()\r\nmain = do writeFile \"wibbleflibble\" (replicate 100 'z')\r\n bs <- getCs $ g $ replicate 1000000 \"flibble\"\r\n print $ last bs\r\n\r\ngetCs :: [FilePath] -> IO String\r\ngetCs [] = return \"\"\r\ngetCs (c : cs) = do x <- readFile c\r\n xs <- unsafeInterleaveIO $ getCs cs\r\n return (x ++ xs)\r\n\r\ng :: [FilePath] -> [FilePath]\r\ng is = map f is\r\n\r\nf :: FilePath -> FilePath \r\nf fn = \"wibble\" ++ fn\r\n}}}\r\nwhen run:\r\n{{{\r\n$ ghc -fforce-recomp -Wall --make -O2 -prof -auto-all z.hs -o z\r\n$ ./z +RTS -h -p\r\n}}}\r\nshows that around 100k is used by `f` (`h.png`). Running with\r\n{{{\r\n$ ./z +RTS -hcf -hy -p\r\n}}}\r\nshows that it is all of type `[]` (`hcf_hy.png`). That seems like a large amount of space for a 13 character filename, so it smells to me like something is wrong somewhere.\r\n\r\nIf we inline `g`:\r\n{{{\r\nmodule Main (main) where\r\n\r\nimport System.IO.Unsafe\r\n\r\nmain :: IO ()\r\nmain = do writeFile \"wibbleflibble\" (replicate 100 'z')\r\n bs <- getCs $ map f $ replicate 1000000 \"flibble\"\r\n print $ last bs\r\n\r\ngetCs :: [FilePath] -> IO String\r\ngetCs [] = return \"\"\r\ngetCs (c : cs) = do x <- readFile c\r\n xs <- unsafeInterleaveIO $ getCs cs\r\n return (x ++ xs)\r\n\r\nf :: FilePath -> FilePath \r\nf fn = \"wibble\" ++ fn\r\n}}}\r\nthen it all disappears (`h2.png`).\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.10.2Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3035:steplocal and :stepmodule should not polute trace history2019-07-07T19:05:47Zphercek:steplocal and :stepmodule should not polute trace history:steplocal and :stepmodule should not extend trace history with records which represent breakpoints outside the scopes in which :steplocal and :stepmodule are actually stopping.
For some discussion related to this see
http://www.haskell...:steplocal and :stepmodule should not extend trace history with records which represent breakpoints outside the scopes in which :steplocal and :stepmodule are actually stopping.
For some discussion related to this see
http://www.haskell.org/pipermail/glasgow-haskell-users/2009-February/016576.html
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":":steplocal and :stepmodule should not polute trace history","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":["debugger"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":":steplocal and :stepmodule should not extend trace history with records which represent breakpoints outside the scopes in which :steplocal and :stepmodule are actually stopping.\r\n\r\nFor some discussion related to this see\r\nhttp://www.haskell.org/pipermail/glasgow-haskell-users/2009-February/016576.html","type_of_failure":"OtherFailure","blocking":[]} -->Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3017Type inference is broken when dealing with tuple type synonyms2019-07-07T19:05:51Zstraka.milanType inference is broken when dealing with tuple type synonymsI have GHC 6.10.1 built from the sources. In the whole bugreport, suppose we have
```
{-# LANGUAGE TypeFamilies #-}
class Coll c where
type Elem c
empty :: c
insert :: Elem c -> c -> c
data ListColl a = L [a]
instance Coll (List...I have GHC 6.10.1 built from the sources. In the whole bugreport, suppose we have
```
{-# LANGUAGE TypeFamilies #-}
class Coll c where
type Elem c
empty :: c
insert :: Elem c -> c -> c
data ListColl a = L [a]
instance Coll (ListColl a) where
type Elem (ListColl a) = a
empty = L []
insert x (L xs) = L (x:xs)
emptyL :: ListColl a
emptyL = empty
```
GHCI says
```
test1 c = insert 0 c
test2 c = insert (0, 0) c
*Main> :t test1
test1 :: (Num (Elem c), Coll c) => c -> c
*Main> :t test2
test2 :: ((Integer, Integer) ~ Elem c, Coll c) => c -> c
```
Shouldn't be the type of test2 be something like
`test2 :: (Num a, Num b, (a, b) ~ (Elem c), Coll c) => c -> c`
?
When trying
```
test1 c = insert 0 c
test2 c = insert (0, 0) c
test3 :: ListColl (Float, Float)
test3 = test2 emptyL
```
we get
```
*Main> :t test2
test2 : ((Float, Float) ~ Elem c, Coll c) => c -> c
```
and
```
test1 c = insert 0 c
test2 c = insert (0, 0) c
test3 :: ListColl (Float, Float)
test3 = test2 emptyL
test3':: ListColl (Int, Int)
test3'= test2 emptyL
Couldn't match expected type `Int' against inferred type `Float'
Expected type: Elem (ListColl (Int, Int))
Inferred type: (Float, Float)
When generalising the type(s) for `test3''
Failed, modules loaded: none.
```
and
```
test1 c = insert 0 c
test2 c = insert (0, 0) c
test4::(Num a, Num b) => ListColl (a, b)
test4 = test2 empty
Inferred type is less polymorphic than expected
Quantified type variable `b' escapes
Quantified type variable `a' escapes
When trying to generalise the type inferred for `test4'
Signature type: forall a b. (Num a, Num b) => ListColl (a, b)
Type to generalise: ListColl (a, b)
In the type signature for `test4'
When generalising the type(s) for `test4'
Failed, modules loaded: none.
```
When adding explicit type signature
`test2 :: (Num a, Num b, (a, b) ~ (Elem c), Coll c) => c -> c`
all above examples works correctly, even if GHCI still says
```
:t test2
*Main> :t test2
test2 :: ((Integer, Integer) ~ Elem c, Coll c) => c -> c
```
Last weird thing is
```
test5 _ = insert 0 emptyL
*Main> :t test5
test5 :: (Num a) => t -> ListColl a
test6 _ = insert (0,0) emptyL
Ambiguous type variable `t' in the constraint:
`Num t'
arising from the literal `0'
at /work/skola/haskell/grafy/Bug.hs:32:18
Probable fix: add a type signature that fixes these type variable(s)
Ambiguous type variable `t1' in the constraint:
`Num t1'
arising from the literal `0'
at /work/skola/haskell/grafy/Bug.hs:32:21
Probable fix: add a type signature that fixes these type variable(s)
Failed, modules loaded: none.
```
but adding
```
test6 :: (Num a, Num b, (a, b) ~ (Elem (ListColl c)), Coll (ListColl c)) => foo -> (ListColl c)
test6 _ = insert (0,0) emptyL
```
once again solves the problem.
Is this really a bug or just a feature :) I understand that in t1 \~ t2, the t1 and t2 can be arbitraty monotypes, so (a, b) should work, even with Num a and Num b, right?
Cheers,
Milan Straka
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"Type inference is broken when dealing with tuple type synonyms","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I have GHC 6.10.1 built from the sources. In the whole bugreport, suppose we have\r\n{{{\r\n{-# LANGUAGE TypeFamilies #-}\r\n\r\nclass Coll c where\r\n type Elem c\r\n empty :: c\r\n insert :: Elem c -> c -> c\r\n\r\ndata ListColl a = L [a]\r\ninstance Coll (ListColl a) where\r\n type Elem (ListColl a) = a\r\n empty = L []\r\n insert x (L xs) = L (x:xs)\r\nemptyL :: ListColl a\r\nemptyL = empty\r\n}}}\r\n\r\nGHCI says\r\n{{{\r\ntest1 c = insert 0 c\r\ntest2 c = insert (0, 0) c\r\n\r\n*Main> :t test1\r\ntest1 :: (Num (Elem c), Coll c) => c -> c\r\n*Main> :t test2\r\ntest2 :: ((Integer, Integer) ~ Elem c, Coll c) => c -> c\r\n}}}\r\n\r\nShouldn't be the type of test2 be something like\r\n{{{test2 :: (Num a, Num b, (a, b) ~ (Elem c), Coll c) => c -> c}}}\r\n?\r\n\r\nWhen trying\r\n{{{\r\ntest1 c = insert 0 c\r\ntest2 c = insert (0, 0) c\r\ntest3 :: ListColl (Float, Float)\r\ntest3 = test2 emptyL\r\n}}}\r\nwe get\r\n{{{\r\n*Main> :t test2\r\ntest2 : ((Float, Float) ~ Elem c, Coll c) => c -> c\r\n}}}\r\n\r\nand\r\n{{{\r\ntest1 c = insert 0 c\r\ntest2 c = insert (0, 0) c\r\ntest3 :: ListColl (Float, Float)\r\ntest3 = test2 emptyL\r\ntest3':: ListColl (Int, Int)\r\ntest3'= test2 emptyL\r\n\r\n Couldn't match expected type `Int' against inferred type `Float'\r\n Expected type: Elem (ListColl (Int, Int))\r\n Inferred type: (Float, Float)\r\n When generalising the type(s) for `test3''\r\nFailed, modules loaded: none.\r\n}}}\r\nand\r\n{{{\r\ntest1 c = insert 0 c\r\ntest2 c = insert (0, 0) c\r\ntest4::(Num a, Num b) => ListColl (a, b)\r\ntest4 = test2 empty\r\n\r\n Inferred type is less polymorphic than expected\r\n Quantified type variable `b' escapes\r\n Quantified type variable `a' escapes\r\n When trying to generalise the type inferred for `test4'\r\n Signature type: forall a b. (Num a, Num b) => ListColl (a, b)\r\n Type to generalise: ListColl (a, b)\r\n In the type signature for `test4'\r\n When generalising the type(s) for `test4'\r\nFailed, modules loaded: none.\r\n}}}\r\n\r\nWhen adding explicit type signature\r\n{{{test2 :: (Num a, Num b, (a, b) ~ (Elem c), Coll c) => c -> c}}}\r\nall above examples works correctly, even if GHCI still says\r\n{{{\r\n:t test2\r\n*Main> :t test2\r\ntest2 :: ((Integer, Integer) ~ Elem c, Coll c) => c -> c\r\n}}}\r\n\r\nLast weird thing is\r\n{{{\r\ntest5 _ = insert 0 emptyL\r\n*Main> :t test5\r\ntest5 :: (Num a) => t -> ListColl a\r\n\r\ntest6 _ = insert (0,0) emptyL\r\n Ambiguous type variable `t' in the constraint:\r\n `Num t'\r\n arising from the literal `0'\r\n at /work/skola/haskell/grafy/Bug.hs:32:18\r\n Probable fix: add a type signature that fixes these type variable(s)\r\n\r\n Ambiguous type variable `t1' in the constraint:\r\n `Num t1'\r\n arising from the literal `0'\r\n at /work/skola/haskell/grafy/Bug.hs:32:21\r\n Probable fix: add a type signature that fixes these type variable(s)\r\nFailed, modules loaded: none.\r\n}}}\r\nbut adding\r\n{{{\r\ntest6 :: (Num a, Num b, (a, b) ~ (Elem (ListColl c)), Coll (ListColl c)) => foo -> (ListColl c)\r\ntest6 _ = insert (0,0) emptyL\r\n}}}\r\nonce again solves the problem.\r\n\r\nIs this really a bug or just a feature :) I understand that in t1 ~ t2, the t1 and t2 can be arbitraty monotypes, so (a, b) should work, even with Num a and Num b, right?\r\n\r\nCheers,\r\nMilan Straka","type_of_failure":"OtherFailure","blocking":[]} -->Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/2993Precedence errors are reported for undefined operators2019-07-07T19:05:58ZOlathePrecedence errors are reported for undefined operatorsI found a misleading error message.
If I add the import for (\<$\>), but I forget to save the file
```
-- other imports
-- import Control.Applicative ((<$>))
main = print $ (+1).(+2) <$> Just 5
```
I get the error
```
precedence ...I found a misleading error message.
If I add the import for (\<$\>), but I forget to save the file
```
-- other imports
-- import Control.Applicative ((<$>))
main = print $ (+1).(+2) <$> Just 5
```
I get the error
```
precedence parsing error
cannot mix `(.)' [infixr 9] and `(<$>)' [infixl 9] in the same infix expression
```
which is rather hard to debug, since it makes it seem that the problem is either with Control.Applicative's precedence definitions or that I've somehow imported (\<$\>) with a different precedence from somewhere else.
It would be nice if it would report instead that (\<$\>) wasn't defined yet.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.1 |
| 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":"Precedence errors are reported for undefined operators","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"I found a misleading error message.\r\n\r\nIf I add the import for (<$>), but I forget to save the file\r\n{{{\r\n-- other imports\r\n-- import Control.Applicative ((<$>))\r\nmain = print $ (+1).(+2) <$> Just 5\r\n}}}\r\nI get the error\r\n{{{\r\n precedence parsing error\r\n cannot mix `(.)' [infixr 9] and `(<$>)' [infixl 9] in the same infix expression\r\n}}}\r\nwhich is rather hard to debug, since it makes it seem that the problem is either with Control.Applicative's precedence definitions or that I've somehow imported (<$>) with a different precedence from somewhere else.\r\n\r\nIt would be nice if it would report instead that (<$>) wasn't defined yet.","type_of_failure":"OtherFailure","blocking":[]} -->Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/2992GHCi Memory Leak in Windows Vista2019-07-07T19:05:59ZAndirGHCi Memory Leak in Windows VistaIf use ghci.exe and separating compiling via ghc.exe, memory leak in ghci occurred. After exhausting available memory Vista has no any respond.
Steps for reproduce:
- Run GHCi: process list has 2 processes: ghci.exe (a), ghc.exe (b),
-...If use ghci.exe and separating compiling via ghc.exe, memory leak in ghci occurred. After exhausting available memory Vista has no any respond.
Steps for reproduce:
- Run GHCi: process list has 2 processes: ghci.exe (a), ghc.exe (b),
- Run separated compilation process 20 times:
Command Line:
```
for /L %i in (1,1,20) do ghc -fforce-recomp -O --make "problem.hs" -o "problem.exe"
```
Sample Haskell Program listing (problem.hs):
```
main :: IO ()
main = do
print $ [x | x <- [1..]]
putStrLn "Hello, world!"
```
- In process list (taskmgr.exe) you can see processor activity and increased value of "Memory (Private Working Set)" for process (b).
- As run result "Memory (Private Working Set)" increased about 100Mb.6.10.2Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/2985Bogus superclass dictionary with equality constraints2019-07-07T19:06:00ZSimon Peyton JonesBogus superclass dictionary with equality constraints```
{-# LANGUAGE TypeFamilies, UndecidableInstances #-}
{-# OPTIONS -fglasgow-exts -Wnot #-}
module Main where
instance (Num a, Num b, a ~ b) => Num (a,b) where
x * _ = x
test1 = (1,1) * (2,2)
main = print test1
```
Running th...```
{-# LANGUAGE TypeFamilies, UndecidableInstances #-}
{-# OPTIONS -fglasgow-exts -Wnot #-}
module Main where
instance (Num a, Num b, a ~ b) => Num (a,b) where
x * _ = x
test1 = (1,1) * (2,2)
main = print test1
```
Running this program produces `<<loop>>`. Reason is that the `Num (a,b)` dictionary gets an `Eq` superclass dictionary that is essentially bottom. I'm not sure why, but it's a bad bug.
See http://article.gmane.org/gmane.comp.lang.haskell.general/16796
Simon
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"Bogus superclass dictionary with equality constraints","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"6.10.2","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\n{-# LANGUAGE TypeFamilies, UndecidableInstances #-}\r\n{-# OPTIONS -fglasgow-exts -Wnot #-}\r\n\r\nmodule Main where\r\n\r\ninstance (Num a, Num b, a ~ b) => Num (a,b) where\r\n x * _ = x \r\n\r\ntest1 = (1,1) * (2,2)\r\n\r\nmain = print test1\r\n}}}\r\nRunning this program produces `<<loop>>`. Reason is that the `Num (a,b)` dictionary gets an `Eq` superclass dictionary that is essentially bottom. I'm not sure why, but it's a bad bug.\r\n\r\nSee http://article.gmane.org/gmane.comp.lang.haskell.general/16796\r\n\r\n\r\n\r\nSimon\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.10.2Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/2980Data.Generics reports wrong package?2019-07-07T19:06:01ZMartijnData.Generics reports wrong package?On a Windows XP machine, importing the Data.Generics packages gives the following confusing error message:
Could not find module \`Data.Generics':
> it is a member of package base-3.0.3.0, which is hidden
After adding the package 's...On a Windows XP machine, importing the Data.Generics packages gives the following confusing error message:
Could not find module \`Data.Generics':
> it is a member of package base-3.0.3.0, which is hidden
After adding the package 'syb' to the dependencies, everything went fine. The documentation of Generics also states base as its package.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries (other) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Data.Generics reports wrong package?","status":"New","operating_system":"","component":"libraries (other)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"On a Windows XP machine, importing the Data.Generics packages gives the following confusing error message:\r\n\r\n Could not find module `Data.Generics':\r\n it is a member of package base-3.0.3.0, which is hidden\r\n\r\nAfter adding the package 'syb' to the dependencies, everything went fine. The documentation of Generics also states base as its package.","type_of_failure":"OtherFailure","blocking":[]} -->6.10.2Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>