GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2024-03-19T18:37:09Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/11434Drop bzip2 in favor of xz2024-03-19T18:37:09ZBen GamariDrop bzip2 in favor of xzIn January 2016 it was proposed that we stop providing bzip2 tarballs, instead only offering xz-compressed tarballs. This ticket is to track this process.
Ben Gamari brought this proposal to the [lists](https://mail.haskell.org/pipermai...In January 2016 it was proposed that we stop providing bzip2 tarballs, instead only offering xz-compressed tarballs. This ticket is to track this process.
Ben Gamari brought this proposal to the [lists](https://mail.haskell.org/pipermail/glasgow-haskell-users/2016-January/026123.html|mailing) where there was no objection.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1-rc1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Drop bzip2 in favor of xz","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"8.0.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1-rc1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"In January 2016 it was proposed that we stop providing bzip2 tarballs, instead only offering xz-compressed tarballs. This ticket is to track this process.\r\n\r\nBen Gamari brought this proposal to the [https://mail.haskell.org/pipermail/glasgow-haskell-users/2016-January/026123.html|mailing lists] where there was no objection.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/10542Incorrect Unicode input on Windows Console2024-03-14T23:23:51ZptroevIncorrect Unicode input on Windows ConsoleTo reproduce:
- start a windows console
- change the console's font to a ttf unicode font, like "Lucida Console".
- type "chcp 65001" to set it to the UTF-8 code page.
- start ghci (same error appears when running compiled executable)
- ...To reproduce:
- start a windows console
- change the console's font to a ttf unicode font, like "Lucida Console".
- type "chcp 65001" to set it to the UTF-8 code page.
- start ghci (same error appears when running compiled executable)
- \> import System.IO (or GHC.IO.Handle)
- \> enc \<- mkTextEncoding "UTF8"
- \> hSetEncoding stdin enc
- \> getLine
- \> Фывфыв (or any international unicode sequence)
- \*\* Exception: \<stdin\>: hGetLine: end of file
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | #4471 |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Incorrect Unicode input on Windows Console","status":"New","operating_system":"","component":"Compiler","related":[4471],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":["65001","chcp","cmd","getLine","stdin","utf-8","windows"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"To reproduce:\r\n- start a windows console\r\n- change the console's font to a ttf unicode font, like \"Lucida Console\".\r\n- type \"chcp 65001\" to set it to the UTF-8 code page.\r\n- start ghci (same error appears when running compiled executable)\r\n- > import System.IO (or GHC.IO.Handle)\r\n- > enc <- mkTextEncoding \"UTF8\"\r\n- > hSetEncoding stdin enc\r\n- > getLine\r\n- > Фывфыв (or any international unicode sequence)\r\n*** Exception: <stdin>: hGetLine: end of file\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Tamar ChristinaTamar Christinahttps://gitlab.haskell.org/ghc/ghc/-/issues/10049Lower level memcpy primop2024-03-08T14:46:16ZchadaustinLower level memcpy primopI'm doing some really low-level buffer stuff, and it would be quite helpful if there were lower-level memcpy primitives.
I'm thinking something like:
```hs
copyBytes# :: Addr# -> Addr# -> Int# -> State# s -> State# s
copyBytes dst src ...I'm doing some really low-level buffer stuff, and it would be quite helpful if there were lower-level memcpy primitives.
I'm thinking something like:
```hs
copyBytes# :: Addr# -> Addr# -> Int# -> State# s -> State# s
copyBytes dst src size _ = ...
```
I would expect it to compile, on x86, into "rep movsb", which is frequently optimal on Ivy Bridge and Haswell.
The other memcpy primitives use Array\# or MutableArray\#, and it's not clear how, if all you have is an Addr\#, how to get the corresponding Array\# or MutableArray\#. (Can you just cast?)
It may be appropriate to have corresponding 16-bit and 32-bit operations; "rep movsw" and "rep movsd", respectively.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.4 |
| 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":"Lower level memcpy primop","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"I'm doing some really low-level buffer stuff, and it would be quite helpful if there were lower-level memcpy primitives.\r\n\r\nI'm thinking something like:\r\n\r\n{{{#!hs\r\ncopyBytes# :: Addr# -> Addr# -> Int# -> State# s -> State# s\r\ncopyBytes dst src size _ = ...\r\n}}}\r\n\r\nI would expect it to compile, on x86, into \"rep movsb\", which is frequently optimal on Ivy Bridge and Haswell.\r\n\r\nThe other memcpy primitives use Array# or MutableArray#, and it's not clear how, if all you have is an Addr#, how to get the corresponding Array# or MutableArray#. (Can you just cast?)\r\n\r\nIt may be appropriate to have corresponding 16-bit and 32-bit operations; \"rep movsw\" and \"rep movsd\", respectively.\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/16100T11627a fails sometimes on CI2024-03-06T20:42:17ZMatthew PickeringT11627a fails sometimes on CISee this build - https://gitlab.haskell.org/mpickering/ghc/-/jobs/6459
Causes this panic
```
81384 cd "profiling/should_run/T11627b.run" && ./T11627b +RTS -hd -RTS +RTS -i0 -RTS
81385 Wrong exit code for T11627a(prof_hc_hb)(expected ...See this build - https://gitlab.haskell.org/mpickering/ghc/-/jobs/6459
Causes this panic
```
81384 cd "profiling/should_run/T11627b.run" && ./T11627b +RTS -hd -RTS +RTS -i0 -RTS
81385 Wrong exit code for T11627a(prof_hc_hb)(expected 0 , actual 134 )
81386 Stdout ( T11627a ):
81387 456574
81388 Stderr ( T11627a ):
81389 T11627a: internal error: LDV_recordDead: Failed to find counter for closure 0x42000bf558
81390 (GHC version 8.7.20181227 for x86_64_unknown_linux)
81391 Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"T11627a fails sometimes on CI","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"\r\n\r\nSee this build - https://gitlab.haskell.org/mpickering/ghc/-/jobs/6459\r\n\r\nCauses this panic\r\n\r\n{{{\r\n81384 cd \"profiling/should_run/T11627b.run\" && ./T11627b +RTS -hd -RTS +RTS -i0 -RTS \r\n81385 Wrong exit code for T11627a(prof_hc_hb)(expected 0 , actual 134 ) \r\n81386 Stdout ( T11627a ): \r\n81387 456574 \r\n81388 Stderr ( T11627a ): \r\n81389 T11627a: internal error: LDV_recordDead: Failed to find counter for closure 0x42000bf558\r\n81390 (GHC version 8.7.20181227 for x86_64_unknown_linux) \r\n81391 Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/1Implicit parameters cause strange behavi2024-03-06T16:52:00ZnobodyImplicit parameters cause strange behavi```
ghc-5.00.1 (with glasgow-exts) compiles the following
program:
> foo :: ((?x :: Int) => b) -> Int -> b
> foo s z = s with ?x = z
> main = foo (print ?x) 42
Running the generated code prints nothing. (No output
is produced
even if w...```
ghc-5.00.1 (with glasgow-exts) compiles the following
program:
> foo :: ((?x :: Int) => b) -> Int -> b
> foo s z = s with ?x = z
> main = foo (print ?x) 42
Running the generated code prints nothing. (No output
is produced
even if we add putStr "Hello world\n" before the call
to foo).
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 5.0 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Implicit parameters cause strange behavi","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"5.0","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nghc-5.00.1 (with glasgow-exts) compiles the following\nprogram:\n\n> foo :: ((?x :: Int) => b) -> Int -> b\n> foo s z = s with ?x = z\n> main = foo (print ?x) 42\n\nRunning the generated code prints nothing. (No output\nis produced\neven if we add putStr \"Hello world\\n\" before the call\nto foo).\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/7501Some GHCi options are undocumented2024-03-06T14:34:08ZKrzysztof GogolewskiSome GHCi options are undocumentedThe following commands are missing from the list found in [GHCi documentation](http://www.haskell.org/ghc/dist/current/docs/html/users_guide/ghci-commands.html):
:check, :issafe, :showi, :list, :steplocal, :stepmodule
At least last thr...The following commands are missing from the list found in [GHCi documentation](http://www.haskell.org/ghc/dist/current/docs/html/users_guide/ghci-commands.html):
:check, :issafe, :showi, :list, :steplocal, :stepmodule
At least last three are documented [in debugger documentation](http://www.haskell.org/ghc/dist/current/docs/html/users_guide/ghci-debugger.html), but a link would be nice.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.6.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":"Some GHCi options are undocummented","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following commands are missing from the list found in [http://www.haskell.org/ghc/dist/current/docs/html/users_guide/ghci-commands.html GHCi documentation]:\r\n\r\n:check, :issafe, :showi, :list, :steplocal, :stepmodule\r\n\r\nAt least last three are documented [http://www.haskell.org/ghc/dist/current/docs/html/users_guide/ghci-debugger.html in debugger documentation], but a link would be nice.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/254closure type 540002024-03-06T02:44:47Znobodyclosure type 54000```
>Compiling Elab ( ./Elab.lhs, ./Elab.o )
>ghc-6.2.1: internal error: evacuate: strange closure
type 54000
> Please report this as a bug to glasgow-haskell-
bugs@haskell.org,
> or http://www.sourceforge.net/projects...```
>Compiling Elab ( ./Elab.lhs, ./Elab.o )
>ghc-6.2.1: internal error: evacuate: strange closure
type 54000
> Please report this as a bug to glasgow-haskell-
bugs@haskell.org,
> or http://www.sourceforge.net/projects/ghc/
This is what happened when I tried to compile Elab.lhs
from http://www.dur.ac.uk/CARG/epigram/.
-?-
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 6.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedNoReason |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"closure type 54000 ","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"ResolvedNoReason","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"6.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\n>Compiling Elab ( ./Elab.lhs, ./Elab.o )\n>ghc-6.2.1: internal error: evacuate: strange closure \ntype 54000\n> Please report this as a bug to glasgow-haskell-\nbugs@haskell.org,\n> or http://www.sourceforge.net/projects/ghc/\n\nThis is what happened when I tried to compile Elab.lhs \nfrom http://www.dur.ac.uk/CARG/epigram/.\n\n-?-\n\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/622FFI support in the interpreter2024-03-04T08:49:22ZSimon MarlowFFI support in the interpreter```
GHCi currently doesn't support FFI declarations in interpreted code.
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version ...```
GHCi currently doesn't support FFI declarations in interpreted code.
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | None |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedNoReason |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"FFI support in the interpreter","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"ResolvedNoReason","owner":{"tag":"Unowned"},"version":"None","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"{{{\nGHCi currently doesn't support FFI declarations in interpreted code.\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/198Directory.renameFile broken under windows2024-02-27T23:09:30ZpstrandDirectory.renameFile broken under windows```
According to the library report, renameFile should succed
even if the target file already exists. Under windows it
fails with:
Fail: already exists
Action: renameFile
Reason: File exists
File: foo
(ghc 6.0 and 6.0.1)
The reason...```
According to the library report, renameFile should succed
even if the target file already exists. Under windows it
fails with:
Fail: already exists
Action: renameFile
Reason: File exists
File: foo
(ghc 6.0 and 6.0.1)
The reason seems to be that it uses the rename library
call directly, which indeed fails if the target exists:
http://msdn.microsoft.com/library/default.asp?
url=/library/en-
us/vclib/html/_crt_rename.2c_._wrename.asp
A solution might involve MoveFileEx(old, new,
MOVEFILE_REPLACE_EXISTING) ?
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 6.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | hslibs/posix |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Directory.renameFile broken under windows","status":"New","operating_system":"","component":"hslibs/posix","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"6.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\n\nAccording to the library report, renameFile should succed \neven if the target file already exists. Under windows it \nfails with:\n \nFail: already exists\nAction: renameFile\nReason: File exists\nFile: foo\n\n(ghc 6.0 and 6.0.1)\n\nThe reason seems to be that it uses the rename library \ncall directly, which indeed fails if the target exists:\n\nhttp://msdn.microsoft.com/library/default.asp?\nurl=/library/en-\nus/vclib/html/_crt_rename.2c_._wrename.asp\n\nA solution might involve MoveFileEx(old, new, \nMOVEFILE_REPLACE_EXISTING) ?\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/13869Improved response from GHCi about ":l" or ":r".2024-02-27T13:03:55ZvantoImproved response from GHCi about ":l" or ":r".I inadvertently wrote `:l` instead of `:r` and after typing on "return" GHCi replied\\\\
```
Prelude> :l
Ok, modules loaded: none.
```
It disturbed me for a few moments.
Why OK?
Sorry but again this does not make sense here.
The interp...I inadvertently wrote `:l` instead of `:r` and after typing on "return" GHCi replied\\\\
```
Prelude> :l
Ok, modules loaded: none.
```
It disturbed me for a few moments.
Why OK?
Sorry but again this does not make sense here.
The interpreter does not load anything.
It is better to say\\\\
```
Failed, modules loaded: none.
```
And so after I write\\\\
```
Prelude> :r
Ok, modules loaded: none.
```
Here too it is better to say\\\\
```
Failed, modules loaded: none.
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Improved response from GHCi about \":l\" or \":r\".","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"I inadvertently wrote {{{:l}}} instead of {{{:r}}} and after typing on \"return\" GHCi replied\\\\\r\n\r\n{{{\r\nPrelude> :l\r\nOk, modules loaded: none.\r\n}}}\r\nIt disturbed me for a few moments.\r\nWhy OK?\r\nSorry but again this does not make sense here.\r\nThe interpreter does not load anything.\r\nIt is better to say\\\\\r\n\r\n{{{\r\nFailed, modules loaded: none.\r\n}}}\r\nAnd so after I write\\\\\r\n\r\n{{{\r\nPrelude> :r\r\nOk, modules loaded: none.\r\n}}}\r\nHere too it is better to say\\\\\r\n\r\n{{{\r\nFailed, modules loaded: none.\r\n}}}\r\n\r\n\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->JadeJadehttps://gitlab.haskell.org/ghc/ghc/-/issues/13352Strange requirement for re-exported duplicate record fields2024-02-26T15:52:10ZEric CrockettStrange requirement for re-exported duplicate record fieldsIn the following example,
```haskell
module A(A(..)) where
data A = A {x::Int}
module B(B(..)) where
data B = B {x::Bool}
{-# LANGUAGE DuplicateRecordFields #-}
module C(A(..),B(..)) where
import A(A(..))
import B(B(..))
```
I get an...In the following example,
```haskell
module A(A(..)) where
data A = A {x::Int}
module B(B(..)) where
data B = B {x::Bool}
{-# LANGUAGE DuplicateRecordFields #-}
module C(A(..),B(..)) where
import A(A(..))
import B(B(..))
```
I get an error about `conflicting exports for 'x'`. This doesn't seem right to me: I've got `-XDuplicateRecordFields` exactly where the duplicate occurs.
However, I noticed that the if I move the pragma to A.hs, C.hs compiles without error:
```haskell
{-# LANGUAGE DuplicateRecordFields #-}
module A(A(..)) where
data A = A {x::Int}
module B(B(..)) where
data B = B {x::Bool}
module C(A(..),B(..)) where
import A(A(..))
import B(B(..))
```
This is bizarre because it is asymmetric (I arbitrarily put the pragma in A.hs, but it need not occur in B.hs), and because no duplicate records exist in module A, but they *do* exist in module C, where the pragma isn't needed.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.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":"Strange requirement for re-exported duplicate record fields","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In the following example, \r\n\r\n{{{\r\nmodule A(A(..)) where\r\ndata A = A {x::Int}\r\n\r\nmodule B(B(..)) where\r\ndata B = B {x::Bool}\r\n\r\n{-# LANGUAGE DuplicateRecordFields #-}\r\nmodule C(A(..),B(..)) where\r\nimport A(A(..))\r\nimport B(B(..))\r\n}}}\r\n\r\nI get an error about `conflicting exports for 'x'`. This doesn't seem right to me: I've got `-XDuplicateRecordFields` exactly where the duplicate occurs.\r\n\r\nHowever, I noticed that the if I move the pragma to A.hs, C.hs compiles without error:\r\n\r\n{{{\r\n{-# LANGUAGE DuplicateRecordFields #-}\r\nmodule A(A(..)) where\r\ndata A = A {x::Int}\r\n\r\nmodule B(B(..)) where\r\ndata B = B {x::Bool}\r\n\r\nmodule C(A(..),B(..)) where\r\nimport A(A(..))\r\nimport B(B(..))\r\n}}}\r\n\r\nThis is bizarre because it is asymmetric (I arbitrarily put the pragma in A.hs, but it need not occur in B.hs), and because no duplicate records exist in module A, but they ''do'' exist in module C, where the pragma isn't needed.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->sheafsam.derbyshire@gmail.comsheafsam.derbyshire@gmail.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/12400Suggest misspelling if a type signature has similarly named binding2024-02-21T20:42:21ZIcelandjackSuggest misspelling if a type signature has similarly named bindingDue to clumsy fingers I often run into
```hs
mkBinder :: a
mkBidner = undefined
```
errors with
```
t1ZE.hs:1:1-8: error: …
The type signature for ‘mkBinder’ lacks an accompanying binding
Compilation failed.
```
Maybe it could m...Due to clumsy fingers I often run into
```hs
mkBinder :: a
mkBidner = undefined
```
errors with
```
t1ZE.hs:1:1-8: error: …
The type signature for ‘mkBinder’ lacks an accompanying binding
Compilation failed.
```
Maybe it could mention
```
note: did you mean 'mkBinder'?
```
----
How `clang` does it
```c
#include <stdio.h>
int main(void)
{
prinft("hi");
}
```
```
% clang -Werror c.c
c.c:5:3: error: implicit declaration of function 'prinft' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
prinft("hi");
^
c.c:5:3: note: did you mean 'printf'?
/usr/include/stdio.h:362:12: note: 'printf' declared here
extern int printf (const char *__restrict __format, ...);
^
1 error generated.
```https://gitlab.haskell.org/ghc/ghc/-/issues/12633Support standard syntax for language pragmas in GHCi2024-02-21T19:37:31ZHjulleSupport standard syntax for language pragmas in GHCiIt would be convenient to be able to use the standard (module level) syntax for language pragmas in GHCi
```hs
{-# LANGUAGE Extension #-}
```
instead of just the GHCi specific syntax
```hs
:set -XExtension
```
For example, this would...It would be convenient to be able to use the standard (module level) syntax for language pragmas in GHCi
```hs
{-# LANGUAGE Extension #-}
```
instead of just the GHCi specific syntax
```hs
:set -XExtension
```
For example, this would simplify copy-pasting examples and code into GHCi, especially now that most other module level syntax is supported. It might also reduce confusion for new users, since the syntax is the same in both cases.
If it is not too difficult, I might take on this myself as a good first bug.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Support standard syntax for language pragmas in GHCi","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"It would be convenient to be able to use the standard (module level) syntax for language pragmas in GHCi\r\n\r\n{{{#!hs\r\n{-# LANGUAGE Extension #-}\r\n}}}\r\n\r\ninstead of just the GHCi specific syntax\r\n\r\n{{{#!hs\r\n:set -XExtension\r\n}}}\r\n\r\nFor example, this would simplify copy-pasting examples and code into GHCi, especially now that most other module level syntax is supported. It might also reduce confusion for new users, since the syntax is the same in both cases.\r\n\r\nIf it is not too difficult, I might take on this myself as a good first bug.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/15917GHC seems to re-read source of module to produce fancy error msgs2024-02-20T20:54:05ZHeimdellGHC seems to re-read source of module to produce fancy error msgsI had a module with unused name `txFees` in it. I started compilation and in the same time edited code by renaming `txFees` -\> `_txFees`.
I got the following message:
```
warning: [-Wunused-matches]
Defined but not used: ‘...I had a module with unused name `txFees` in it. I started compilation and in the same time edited code by renaming `txFees` -\> `_txFees`.
I got the following message:
```
warning: [-Wunused-matches]
Defined but not used: ‘txFees’
|
40 | } _txFees
| ^^^^^^
<no location info>: error:
Failing due to -Werror.
```
The screenshot is in the attachment. Notice that message part is about old code (`txFees`), and preview is about new code (`_txFees`).
<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 | @int-index |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC seems to re-read source of module to produce fancy error msgs","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":["re-reading"],"differentials":[],"test_case":"","architecture":"","cc":["@int-index"],"type":"Bug","description":"I had a module with unused name `txFees` in it. I started compilation and in the same time edited code by renaming `txFees` -> `_txFees`.\r\n\r\nI got the following message:\r\n\r\n{{{\r\n warning: [-Wunused-matches]\r\n Defined but not used: ‘txFees’\r\n |\r\n 40 | } _txFees\r\n | ^^^^^^\r\n \r\n <no location info>: error: \r\n Failing due to -Werror.\r\n}}}\r\n\r\nThe screenshot is in the attachment. Notice that message part is about old code (`txFees`), and preview is about new code (`_txFees`).","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/11983Can't use IntPtr or WordPtr in a foreign import2024-02-16T22:04:52ZRyan ScottCan't use IntPtr or WordPtr in a foreign importDespite the [docs claiming](http://hackage.haskell.org/package/base-4.8.2.0/docs/Foreign-Ptr.html#t:IntPtr) that you can use `IntPtr` and `WordPtr` to convert to and from `intptr_t` and `uintptr_t`, you can't actually do so in a `foreign...Despite the [docs claiming](http://hackage.haskell.org/package/base-4.8.2.0/docs/Foreign-Ptr.html#t:IntPtr) that you can use `IntPtr` and `WordPtr` to convert to and from `intptr_t` and `uintptr_t`, you can't actually do so in a `foreign import` as of GHC 7.6. Here's a minimal example:
```hs
-- Example.hs
{-# LANGUAGE ForeignFunctionInterface #-}
module Example where
{-# INCLUDE example.h #-}
import Foreign.Ptr
foreign import ccall "intptr_example"
intPtrExample :: IntPtr -> IO ()
foreign import ccall "uintptr_example"
wordPtrExample :: WordPtr -> IO ()
```
```c
// example.h
#ifndef EXAMPLE_H
#define EXAMPLE_H
#include <stdint.h>
void intptr_example(intptr_t);
void uintptr_example(uintptr_t);
#endif // EXAMPLE_H
```
```c
// example.c
#include <stdint.h>
#include "example.h"
void intptr_example(intptr_t i) {}
void uintptr_example(uintptr_t u) {}
```
This appears to be a consequence of #3008, which prevents `newtype`s from being used as FFI types unless their constructors are exported. #5529 fixed this problem for the datatypes in `Foreign.C.Types` and `System.Posix.Types` by simply exporting their constructors, so I think all that's needed to fix this particular example is to export the constructors for `IntPtr` and `WordPtr`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (FFI) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Can't use IntPtr or WordPtr in a foreign import","status":"New","operating_system":"","component":"Compiler (FFI)","related":[],"milestone":"8.2.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"RyanGlScott"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Despite the [http://hackage.haskell.org/package/base-4.8.2.0/docs/Foreign-Ptr.html#t:IntPtr docs claiming] that you can use `IntPtr` and `WordPtr` to convert to and from `intptr_t` and `uintptr_t`, you can't actually do so in a `foreign import` as of GHC 7.6. Here's a minimal example:\r\n\r\n{{{#!hs\r\n-- Example.hs\r\n{-# LANGUAGE ForeignFunctionInterface #-}\r\nmodule Example where\r\n\r\n{-# INCLUDE example.h #-}\r\n\r\nimport Foreign.Ptr\r\n\r\nforeign import ccall \"intptr_example\"\r\n intPtrExample :: IntPtr -> IO ()\r\nforeign import ccall \"uintptr_example\"\r\n wordPtrExample :: WordPtr -> IO ()\r\n}}}\r\n\r\n{{{#!c\r\n// example.h\r\n#ifndef EXAMPLE_H\r\n#define EXAMPLE_H\r\n\r\n#include <stdint.h>\r\n\r\nvoid intptr_example(intptr_t);\r\nvoid uintptr_example(uintptr_t);\r\n\r\n#endif // EXAMPLE_H\r\n}}}\r\n\r\n{{{#!c\r\n// example.c\r\n#include <stdint.h>\r\n#include \"example.h\"\r\n\r\nvoid intptr_example(intptr_t i) {}\r\nvoid uintptr_example(uintptr_t u) {}\r\n}}}\r\n\r\nThis appears to be a consequence of #3008, which prevents `newtype`s from being used as FFI types unless their constructors are exported. #5529 fixed this problem for the datatypes in `Foreign.C.Types` and `System.Posix.Types` by simply exporting their constructors, so I think all that's needed to fix this particular example is to export the constructors for `IntPtr` and `WordPtr`.","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1Ryan ScottRyan Scotthttps://gitlab.haskell.org/ghc/ghc/-/issues/243-odir changes output name of main module2024-02-15T22:34:36Zmsjogren-odir changes output name of main module```
When the main module is not named Main.hs, ghc -c
Foo.hs normally creates Foo.hi and Foo.o, but if you
add an -odir flag, ghc will instead produce Foo.hi and
Main.o. This seriously breaks building multiple
executables from the same f...```
When the main module is not named Main.hs, ghc -c
Foo.hs normally creates Foo.hi and Foo.o, but if you
add an -odir flag, ghc will instead produce Foo.hi and
Main.o. This seriously breaks building multiple
executables from the same files but with different main
modules.
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 6.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedNoReason |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"-odir changes output name of main module","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"ResolvedNoReason","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"6.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nWhen the main module is not named Main.hs, ghc -c\nFoo.hs normally creates Foo.hi and Foo.o, but if you\nadd an -odir flag, ghc will instead produce Foo.hi and\nMain.o. This seriously breaks building multiple\nexecutables from the same files but with different main\nmodules.\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/8317Optimize tagToEnum# at Core level2024-02-12T22:06:27ZJan Stolarekjan.stolarek@ed.ac.ukOptimize tagToEnum# at Core levelOld comparison primops that returned Bool were implemented by inserting call to `tagToEnum#` in the code generator. This call to `tagToEnum#` was later optimized away by a special case in the code geenrator (see \[\[GhcFile(compiler/code...Old comparison primops that returned Bool were implemented by inserting call to `tagToEnum#` in the code generator. This call to `tagToEnum#` was later optimized away by a special case in the code geenrator (see \[\[GhcFile(compiler/codeGen/StgCmmExpr.hs)\]\], Note \[case on bool\])). Now that we have new comparison primops (see #6135) we no longer insert `tagToEnum#` in the code generator - all uses of `tagToEnum#` come from explicit calls in a source program. But we still have that special case in the code generator to optimize away `tagToEnum#`. We should drop that special case in the code generator and handle scrutinizing of `tagToEnum#` at the Core level by:
1. removing call to `tagToEnum#` in the scrutinee
1. adding calls to `dataToTag#` in case branches
1. constant-folding inserted `dataToTag#`
Here is an example. This Haskell code:
```
if tagToEnum# (a ># b)
then E1
else E2
```
will be translated to this Core:
```
case tagToEnum# (a ># b) of
True -> E1
False -> E2
```
and optimized like this:
```
case a ># b of
dataToTag# True -> E1
dataToTag# False -> E2
```
#### \>
```
case a ># b of
1 -> E1
0 -> E2
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.7 |
| 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":"Optimize tagToEnum# at Core level","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"Old comparison primops that returned Bool were implemented by inserting call to `tagToEnum#` in the code generator. This call to `tagToEnum#` was later optimized away by a special case in the code geenrator (see [[GhcFile(compiler/codeGen/StgCmmExpr.hs)]], Note [case on bool])). Now that we have new comparison primops (see #6135) we no longer insert `tagToEnum#` in the code generator - all uses of `tagToEnum#` come from explicit calls in a source program. But we still have that special case in the code generator to optimize away `tagToEnum#`. We should drop that special case in the code generator and handle scrutinizing of `tagToEnum#` at the Core level by:\r\n\r\n 1. removing call to `tagToEnum#` in the scrutinee\r\n 2. adding calls to `dataToTag#` in case branches\r\n 3. constant-folding inserted `dataToTag#`\r\n\r\nHere is an example. This Haskell code:\r\n{{{\r\nif tagToEnum# (a ># b)\r\nthen E1\r\nelse E2\r\n}}}\r\nwill be translated to this Core:\r\n{{{\r\ncase tagToEnum# (a ># b) of\r\n True -> E1\r\n False -> E2\r\n}}}\r\nand optimized like this:\r\n{{{\r\ncase a ># b of\r\n dataToTag# True -> E1\r\n dataToTag# False -> E2\r\n}}}\r\n====>\r\n{{{\r\ncase a ># b of\r\n 1 -> E1\r\n 0 -> E2\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/11209Please add platform detection support for sh4 (Hitachi SuperH)2024-02-11T18:35:30ZglaubitzPlease add platform detection support for sh4 (Hitachi SuperH)Hello!
I am currently bootstrapping ghc for sh4 in Debian.
In order to get the ghc build scripts detect sh4 as a valid architecture, I had to make local changes to aclocal.m4. With these changes, sh4 is properly detected as an architec...Hello!
I am currently bootstrapping ghc for sh4 in Debian.
In order to get the ghc build scripts detect sh4 as a valid architecture, I had to make local changes to aclocal.m4. With these changes, sh4 is properly detected as an architecture and I can both cross-build for sh4 as well as build ghc on this platform natively.
Please apply the supplied patch so that we do not have to carry this patch in the Debian package \[1\] anymore.
Thanks,
Adrian
> \[1\] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=807108
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Please add platform detection support for sh4 (Hitachi SuperH)","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Hello!\r\n\r\nI am currently bootstrapping ghc for sh4 in Debian.\r\n\r\nIn order to get the ghc build scripts detect sh4 as a valid architecture, I had to make local changes to aclocal.m4. With these changes, sh4 is properly detected as an architecture and I can both cross-build for sh4 as well as build ghc on this platform natively.\r\n\r\nPlease apply the supplied patch so that we do not have to carry this patch in the Debian package [1] anymore.\r\n\r\nThanks,\r\nAdrian\r\n\r\n> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=807108","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/11214Remove JavaScriptFFI from --supported-extensions list2024-02-09T17:32:36ZLuite StegemanRemove JavaScriptFFI from --supported-extensions listGHC supports the `JavaScriptFFI` extension syntactically, but it just rejects all `foreign import javascript` declarations in the typechecker.
Similar to the change in #11102 I think the proper thing to do is to make GHC say that `JavaS...GHC supports the `JavaScriptFFI` extension syntactically, but it just rejects all `foreign import javascript` declarations in the typechecker.
Similar to the change in #11102 I think the proper thing to do is to make GHC say that `JavaScriptFFI` is not supported. Cabal 1.24 can then use this information in dependency resolution. GHCJS would then just add this to the list by itself, since it has its own front end.
<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 | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Remove JavaScriptFFI from --supported-extensions list","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"GHC supports the `JavaScriptFFI` extension syntactically, but it just rejects all `foreign import javascript` declarations in the typechecker.\r\n\r\nSimilar to the change in #11102 I think the proper thing to do is to make GHC say that `JavaScriptFFI` is not supported. Cabal 1.24 can then use this information in dependency resolution. GHCJS would then just add this to the list by itself, since it has its own front end.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/10065Definition of fix lacks commentary2024-02-08T17:32:07ZDavid FeuerDefinition of fix lacks commentaryIn `Data.Function`,
```hs
fix :: (a -> a) -> a
fix f = let x = f x in x
```
It is not immediately obvious why it is defined like this, rather than the more natural
```hs
fix f = f (fix f)
```
There are very good reasons for this; not...In `Data.Function`,
```hs
fix :: (a -> a) -> a
fix f = let x = f x in x
```
It is not immediately obvious why it is defined like this, rather than the more natural
```hs
fix f = f (fix f)
```
There are very good reasons for this; notably, it allows for the definition of circular data structures. But there should be a comment explaining this, preferably in the Haddocks.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------------------ |
| Version | 7.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Core Libraries |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | core-libraries-committee@haskell.org |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Definition of fix lacks commentary","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"dfeuer"},"version":"7.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["core-libraries-committee@haskell.org"],"type":"Bug","description":"In `Data.Function`,\r\n\r\n{{{#!hs\r\nfix :: (a -> a) -> a\r\nfix f = let x = f x in x\r\n}}}\r\n\r\nIt is not immediately obvious why it is defined like this, rather than the more natural\r\n\r\n{{{#!hs\r\nfix f = f (fix f)\r\n}}}\r\n\r\nThere are very good reasons for this; notably, it allows for the definition of circular data structures. But there should be a comment explaining this, preferably in the Haddocks.","type_of_failure":"OtherFailure","blocking":[]} -->David FeuerDavid Feuer