GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:14:27Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/15061print022 testcase fails on i3862019-07-07T18:14:27ZBen Gamariprint022 testcase fails on i386CircleCI's i386 way is showing this failure of `print002` in the `ghci` way,
```
Actual stderr output differs from expected:
--- /dev/null 2018-04-18 16:05:23.479353000 +0000
+++ ./ghci.debugger/scripts/print022.run/print022.run.stderr....CircleCI's i386 way is showing this failure of `print002` in the `ghci` way,
```
Actual stderr output differs from expected:
--- /dev/null 2018-04-18 16:05:23.479353000 +0000
+++ ./ghci.debugger/scripts/print022.run/print022.run.stderr.normalised 2018-04-19 13:53:47.685662431 +0000
@@ -0,0 +1 @@
+*** Exception: Prelude.chr: bad argument: 1493110744
*** unexpected failure for print022(ghci)
```
This is a bit frightening as it suggests that there is memory unsafety here.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"print022 testcase fails on i386","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"CircleCI's i386 way is showing this failure of `print002` in the `ghci` way,\r\n{{{\r\nActual stderr output differs from expected:\r\n--- /dev/null\t2018-04-18 16:05:23.479353000 +0000\r\n+++ ./ghci.debugger/scripts/print022.run/print022.run.stderr.normalised\t2018-04-19 13:53:47.685662431 +0000\r\n@@ -0,0 +1 @@\r\n+*** Exception: Prelude.chr: bad argument: 1493110744\r\n*** unexpected failure for print022(ghci)\r\n}}}\r\n\r\nThis is a bit frightening as it suggests that there is memory unsafety here.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Ömer Sinan AğacanÖmer Sinan Ağacanhttps://gitlab.haskell.org/ghc/ghc/-/issues/14713GHCi doesn't load project.2019-07-07T18:15:54Zrecursion-ninjaGHCi doesn't load project.I got the following output when trying to load my Haskell project into GHCi using stack:
```
GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help
ghc: panic! (the 'impossible' happened)
(GHC version 8.2.2 for x86_64-unknown-l...I got the following output when trying to load my Haskell project into GHCi using stack:
```
GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help
ghc: panic! (the 'impossible' happened)
(GHC version 8.2.2 for x86_64-unknown-linux):
Loading temp shared object failed: /tmp/ghc3372_0/libghc_13.so: undefined symbol: numStates_g
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
No other informative output was displayed. Output says report the defect, so you get a "bug report."
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHCi doesn't load project.","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I got the following output when trying to load my Haskell project into GHCi using stack:\r\n\r\n\r\n{{{\r\nGHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.2.2 for x86_64-unknown-linux):\r\n\tLoading temp shared object failed: /tmp/ghc3372_0/libghc_13.so: undefined symbol: numStates_g\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nNo other informative output was displayed. Output says report the defect, so you get a \"bug report.\"","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15661Nullary constraint in GHCi breaks `:t` command2024-01-21T16:33:56ZtaktoaNullary constraint in GHCi breaks `:t` commandIf you create a value whose type has a nullary constraint (i.e.: a constraint that does not reference any of the type variables in scope) and then try to run `:t` on it, GHCi attempts to run instance resolution and fails before printing ...If you create a value whose type has a nullary constraint (i.e.: a constraint that does not reference any of the type variables in scope) and then try to run `:t` on it, GHCi attempts to run instance resolution and fails before printing the type.
Expected output:
```
GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help
Prelude> :set -XFlexibleContexts
Prelude> data Foo = Foo
Prelude> let x :: (Show Foo) => () ; x = ()
Prelude> :t x
x :: Show Foo => ()
```
Actual output:
```
GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help
Prelude> :set -XFlexibleContexts
Prelude> data Foo = Foo
Prelude> let x :: (Show Foo) => () ; x = ()
Prelude> :t x
<interactive>:1:1: error:
No instance for (Show Foo) arising from a use of ‘x’
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Nullary constraint in GHCi breaks `:t` command","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"If you create a value whose type has a nullary constraint (i.e.: a constraint that does not reference any of the type variables in scope) and then try to run `:t` on it, GHCi attempts to run instance resolution and fails before printing the type.\r\n\r\nExpected output:\r\n\r\n{{{\r\nGHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help\r\nPrelude> :set -XFlexibleContexts\r\nPrelude> data Foo = Foo\r\nPrelude> let x :: (Show Foo) => () ; x = ()\r\nPrelude> :t x\r\nx :: Show Foo => ()\r\n}}}\r\n\r\nActual output:\r\n\r\n{{{\r\nGHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help\r\nPrelude> :set -XFlexibleContexts\r\nPrelude> data Foo = Foo\r\nPrelude> let x :: (Show Foo) => () ; x = ()\r\nPrelude> :t x\r\n\r\n<interactive>:1:1: error:\r\n No instance for (Show Foo) arising from a use of ‘x’\r\n}}}\r\n\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15556Inconsistent kind output for (->)2019-07-07T18:04:09ZcvladInconsistent kind output for (->)The kind for (-\>) seems to be (uniquely?) verbose in ghc \>= 8.2.2:
`(->) :: TYPE q -> TYPE r -> *`
Unlike all other things I was able to check. Is this intended?
<details><summary>Trac metadata</summary>
| Trac field | ...The kind for (-\>) seems to be (uniquely?) verbose in ghc \>= 8.2.2:
`(->) :: TYPE q -> TYPE r -> *`
Unlike all other things I was able to check. Is this intended?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Inconsistent kind output for (->)","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The kind for (->) seems to be (uniquely?) verbose in ghc >= 8.2.2:\r\n\r\n{{{(->) :: TYPE q -> TYPE r -> *}}}\r\n\r\nUnlike all other things I was able to check. Is this intended?\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15540GHCi does not follow the XDG Base Directory Specification2021-04-01T11:23:17ZRichard SzibeleGHCi does not follow the XDG Base Directory SpecificationHello,
GHCi does not follow the XDG Base Directory Specification by default on GNU/Linux based operating systems.
It creates for instance the file $HOME/.ghc/ghci_history which belongs in $XDG_CACHE_HOME/ghc/ , or $HOME/.cache/ghc/ if ...Hello,
GHCi does not follow the XDG Base Directory Specification by default on GNU/Linux based operating systems.
It creates for instance the file $HOME/.ghc/ghci_history which belongs in $XDG_CACHE_HOME/ghc/ , or $HOME/.cache/ghc/ if $XDG_CACHE_HOME is not set.
$ ghci --version
The Glorious Glasgow Haskell Compilation System, version 8.0.2
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHCi does not follow the XDG Base Directory Specification","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Hello,\r\n\r\nGHCi does not follow the XDG Base Directory Specification by default on GNU/Linux based operating systems.\r\n\r\nIt creates for instance the file $HOME/.ghc/ghci_history which belongs in $XDG_CACHE_HOME/ghc/ , or $HOME/.cache/ghc/ if $XDG_CACHE_HOME is not set.\r\n\r\n$ ghci --version\r\nThe Glorious Glasgow Haskell Compilation System, version 8.0.2","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15516ghci: dynamic linking fails on osx2022-05-15T03:33:26Zkfizghci: dynamic linking fails on osx```
ghc: panic! (the 'impossible' happened)
(GHC version 8.4.3 for x86_64-apple-darwin):
Loading temp shared object failed: dlopen(/var/folders/vj/cm0c8jrs739_t411zdcx72240000gp/T/ghc24522_0/libghc_9.dylib, 5): Symbol not found: _Data...```
ghc: panic! (the 'impossible' happened)
(GHC version 8.4.3 for x86_64-apple-darwin):
Loading temp shared object failed: dlopen(/var/folders/vj/cm0c8jrs739_t411zdcx72240000gp/T/ghc24522_0/libghc_9.dylib, 5): Symbol not found: _DataziCsvUtils_rowBy_closure
Referenced from: /var/folders/vj/cm0c8jrs739_t411zdcx72240000gp/T/ghc24522_0/libghc_9.dylib
Expected in: flat namespace
in /var/folders/vj/cm0c8jrs739_t411zdcx72240000gp/T/ghc24522_0/libghc_9.dylib
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15446compiling files in ghci on MacOS eventually results in malformed mach-o: load...2019-07-07T18:04:51Zgeorge.colpittscompiling files in ghci on MacOS eventually results in malformed mach-o: load commands size (32800) > 32768compiling files in ghci on MacOS eventually results in a panic with error:
```
malformed mach-o: load commands size (32800) > 32768
```
I can reproduce this problem by repeatedly compiling (and loading) a file and then deleting the .o ...compiling files in ghci on MacOS eventually results in a panic with error:
```
malformed mach-o: load commands size (32800) > 32768
```
I can reproduce this problem by repeatedly compiling (and loading) a file and then deleting the .o file. I understand that this an OS limitation but why does repeatedly doing the same thing results in this? i.e. why don't I get it on the first compile (and load). It seems that successive loads are being appended to something eventually resulting in the error.
To duplicate:
ghci -ignore-dot-ghci -fobject-code \< ghci.sh \>& ghci.out &
If you look for the first "panic" in the .out file you'll see
```
Prelude Main> ghc: panic! (the 'impossible' happened)
(GHC version 8.6.0.20180714 for x86_64-apple-darwin):
Loading temp shared object failed: dlopen(/var/folders/9b/rh4y2gy92hgdb6ktv4df1jv00000gn/T/ghc55569_0/libghc_2084.dylib, 5): no suitable image found. Did find:
/var/folders/9b/rh4y2gy92hgdb6ktv4df1jv00000gn/T/ghc55569_0/libghc_2084.dylib: malformed mach-o: load commands size (32800) > 32768
/var/folders/9b/rh4y2gy92hgdb6ktv4df1jv00000gn/T/ghc55569_0/libghc_2084.dylib: stat() failed with errno=25
```
The critical part being
```
malformed mach-o: load commands size (32800) > 32768
```
My understanding from https://stackoverflow.com/questions/44902695/too-many-commands-dyld-message-malformed-mach-o-load-commands-size is that this has to do with sizeofcmds but if I understand the output of otool -l this is only 512 so I don't understand what is causing the errror.
```
otool -l c.o|head
c.o:
Mach header
magic cputype cpusubtype caps filetype ncmds sizeofcmds flags
0xfeedfacf 16777223 3 0x00 1 4 512 0x00002000
```
This is irritating but perhaps the priority should be low rather than normal.8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15401Weird GHCi bug2019-07-07T18:05:05ZAlexey VagarenkoWeird GHCi bugTake a look at this GHCi session:
```hs
$ ghci
GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help
```
type `do {_}`
```hs
Prelude> do {_} ...Take a look at this GHCi session:
```hs
$ ghci
GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help
```
type `do {_}`
```hs
Prelude> do {_}
<interactive>:1:5: error:
* Found hole: _ :: t
Where: `t' is a rigid type variable bound by
the inferred type of it :: t
at <interactive>:1:1-6
* In a stmt of a 'do' block: _
In the expression: do _
In an equation for `it': it = do _
* Relevant bindings include it :: t (bound at <interactive>:1:1)
Valid substitutions include
undefined :: forall (a :: TYPE r).
GHC.Stack.Types.HasCallStack =>
a
(imported from `Prelude' (and originally defined in `GHC.Err'))
```
looks ok
type `()`
```hs
Prelude> ()
()
```
ok
type `do {_}` again
```hs
Prelude> do {_}
<interactive>:3:5: error:
* Found hole: _ :: t
Where: `t' is a rigid type variable bound by
the inferred type of it :: t
at <interactive>:3:1-6
* In a stmt of a 'do' block: _
In the expression: do _
In an equation for `it': it = do _
* Relevant bindings include it :: t (bound at <interactive>:3:1)
Valid substitutions include
undefined :: forall (a :: TYPE r).
GHC.Stack.Types.HasCallStack =>
a
(imported from `Prelude' (and originally defined in `GHC.Err'))
```
ok, same message
type `()` second type
```hs
Prelude> ()
()
```
ok,
type `do {_}` third time:
```hs
Prelude> do {_}
<interactive>:1:1: error:
GHC internal error: `Ghci1.it' is not in scope during type checking,
but it passed the renamer
tcl_env of environment: []
Prelude>
```
what's happening?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Weird GHCi bug","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Take a look at this GHCi session:\r\n{{{#!hs\r\n$ ghci \r\nGHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help\r\n}}}\r\ntype `do {_}`\r\n{{{#!hs \r\nPrelude> do {_} \r\n \r\n<interactive>:1:5: error: \r\n * Found hole: _ :: t \r\n Where: `t' is a rigid type variable bound by \r\n the inferred type of it :: t \r\n at <interactive>:1:1-6 \r\n * In a stmt of a 'do' block: _ \r\n In the expression: do _ \r\n In an equation for `it': it = do _ \r\n * Relevant bindings include it :: t (bound at <interactive>:1:1) \r\n Valid substitutions include \r\n undefined :: forall (a :: TYPE r). \r\n GHC.Stack.Types.HasCallStack => \r\n a \r\n (imported from `Prelude' (and originally defined in `GHC.Err'))\r\n}}}\r\nlooks ok\r\n\r\ntype `()`\r\n{{{#!hs\r\nPrelude> () \r\n() \r\n}}}\r\nok\r\n\r\ntype `do {_}` again\r\n{{{#!hs\r\nPrelude> do {_} \r\n \r\n<interactive>:3:5: error: \r\n * Found hole: _ :: t \r\n Where: `t' is a rigid type variable bound by \r\n the inferred type of it :: t \r\n at <interactive>:3:1-6 \r\n * In a stmt of a 'do' block: _ \r\n In the expression: do _ \r\n In an equation for `it': it = do _ \r\n * Relevant bindings include it :: t (bound at <interactive>:3:1) \r\n Valid substitutions include \r\n undefined :: forall (a :: TYPE r). \r\n GHC.Stack.Types.HasCallStack => \r\n a \r\n (imported from `Prelude' (and originally defined in `GHC.Err'))\r\n}}}\r\nok, same message\r\n\r\ntype `()` second type\r\n{{{#!hs\r\nPrelude> () \r\n() \r\n}}}\r\nok,\r\n\r\ntype `do {_}` third time:\r\n{{{#!hs\r\nPrelude> do {_} \r\n \r\n<interactive>:1:1: error: \r\n GHC internal error: `Ghci1.it' is not in scope during type checking, \r\nbut it passed the renamer \r\n tcl_env of environment: [] \r\nPrelude> \r\n}}}\r\nwhat's happening?","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15314Internal error during typechecking of a hole in GHCi when there's shadowed id...2019-07-07T18:13:19ZmniipInternal error during typechecking of a hole in GHCi when there's shadowed identifiers```hs
GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help
Prelude> let x = ()
Prelude> let x = ()
Prelude> :t _
<interactive>:1:1: error:
GHC internal error: ‘Ghci1.x’ is not in scope during type checking, but it passed th...```hs
GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help
Prelude> let x = ()
Prelude> let x = ()
Prelude> :t _
<interactive>:1:1: error:
GHC internal error: ‘Ghci1.x’ is not in scope during type checking, but it passed the renamer
tcl_env of environment: []
```
Seems to only happen when there were two identifiers defined with the same name.
As verified by mpickering on IRC this isn't reproducible in 8.2.2.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Internal error during typechecking of a hole in GHCi when there's shadowed identifiers","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{#!hs\r\nGHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help\r\nPrelude> let x = ()\r\nPrelude> let x = ()\r\nPrelude> :t _\r\n\r\n<interactive>:1:1: error:\r\n GHC internal error: ‘Ghci1.x’ is not in scope during type checking, but it passed the renamer\r\n tcl_env of environment: []\r\n}}}\r\n\r\nSeems to only happen when there were two identifiers defined with the same name.\r\n\r\nAs verified by mpickering on IRC this isn't reproducible in 8.2.2.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15259Out-of-scope-variables error still can be deferred in ghci2019-07-07T18:13:35ZTao Hesighingnow@gmail.comOut-of-scope-variables error still can be deferred in ghciDeferring type errors is unhelpful in ghci, since the expression is evaluated immediately. In #11130, we disabled typed holes in ghci as well. The `-fdefer-out-of-scope-variables` should also be disabled in ghci.
<details><summary>Trac ...Deferring type errors is unhelpful in ghci, since the expression is evaluated immediately. In #11130, we disabled typed holes in ghci as well. The `-fdefer-out-of-scope-variables` should also be disabled in ghci.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.5 |
| 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":"Out-of-scope-variables error still can be deferred in ghci","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Deferring type errors is unhelpful in ghci, since the expression is evaluated immediately. In #11130, we disabled typed holes in ghci as well. The `-fdefer-out-of-scope-variables` should also be disabled in ghci.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Tobias Dammerstdammers@gmail.comTobias Dammerstdammers@gmail.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/15240GHCi's :doc doesn't find the documentation for some class methods2019-07-07T18:13:39ZSimon JakobiGHCi's :doc doesn't find the documentation for some class methodsWhile `:doc` reliably finds the docs for classes like Foldable and Monad, it fails for some methods.
```
λ :doc return
Inject a value into the monadic type.
λ :doc foldr
<has no documentation>
λ :doc show
<has no documentation>
```
So...While `:doc` reliably finds the docs for classes like Foldable and Monad, it fails for some methods.
```
λ :doc return
Inject a value into the monadic type.
λ :doc foldr
<has no documentation>
λ :doc show
<has no documentation>
```
So far I haven't been able to see a pattern there.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | alexbiehl, hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHCi's :doc doesn't find the documentation for some class methods","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["alexbiehl","hvr"],"type":"Bug","description":"While `:doc` reliably finds the docs for classes like Foldable and Monad, it fails for some methods.\r\n\r\n{{{\r\nλ :doc return\r\n Inject a value into the monadic type.\r\nλ :doc foldr\r\n<has no documentation>\r\nλ :doc show\r\n<has no documentation>\r\n}}}\r\n\r\nSo far I haven't been able to see a pattern there.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Simon JakobiSimon Jakobihttps://gitlab.haskell.org/ghc/ghc/-/issues/15174got internal error when running a simple but computationally intensive loop2019-08-08T06:42:52Zrgrovergot internal error when running a simple but computationally intensive loopGot the following on the GHCi prompt:
```
λ> main
<interactive>: internal error: Unable to commit 1048576 bytes of memory
(GHC version 8.2.2 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/...Got the following on the GHCi prompt:
```
λ> main
<interactive>: internal error: Unable to commit 1048576 bytes of memory
(GHC version 8.2.2 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Aborted (core dumped)
```
The program being run:
```hs
gaussian mean sigma x =
exp (-0.5 * (x - mean) ^ 2 / sigma ^ 2) / (sigma * sqrt (2 * pi))
integrate :: (Double -> Double) -> (Double, Double) -> Double -> Double
integrate f (low, high) step = step * sum values
where xs = [low, low+step .. high]
values = f <$> xs
main = print $ integrate (gaussian 100 10) (-1 * 1e5, 1e5) 0.001
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"got internal error when running a simple but computationally intensive loop","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Got the following on the GHCi prompt:\r\n{{{\r\nλ> main\r\n<interactive>: internal error: Unable to commit 1048576 bytes of memory\r\n (GHC version 8.2.2 for x86_64_unknown_linux)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\nAborted (core dumped)\r\n}}}\r\n\r\nThe program being run:\r\n\r\n{{{#!hs\r\ngaussian mean sigma x =\r\n exp (-0.5 * (x - mean) ^ 2 / sigma ^ 2) / (sigma * sqrt (2 * pi))\r\n\r\nintegrate :: (Double -> Double) -> (Double, Double) -> Double -> Double\r\nintegrate f (low, high) step = step * sum values\r\n where xs = [low, low+step .. high]\r\n values = f <$> xs\r\n\r\nmain = print $ integrate (gaussian 100 10) (-1 * 1e5, 1e5) 0.001\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15150Difference between 'libicuio' and 'icuio' in the 'extra-libraries' field2019-07-07T18:14:02ZDarwin226Difference between 'libicuio' and 'icuio' in the 'extra-libraries' fieldI'm on Windows and I've recently updated my msys packages. One of them was libicu which I updated from version 58 to version 61. This caused one of my projects to stop building.
I've managed to reproduce the problem by just cloning the ...I'm on Windows and I've recently updated my msys packages. One of them was libicu which I updated from version 58 to version 61. This caused one of my projects to stop building.
I've managed to reproduce the problem by just cloning the text-icu package and trying to open the repl in it. This is the error I get:
```
GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help
ghc.EXE: | C:\Users\darwi\Projects\text-icu\.stack-work\dist\5c8418a7\build\cbits\text_icu.o: unknown symbol `ucnv_getMaxCharSize_61'
linking extra libraries/objects failed
```
A similar error used to happen with icu 58, but I've "fixed" it (see this pull request https://github.com/bos/text-icu/pull/36). This time, however, adding `icuio` to `extra-libraries` doesn't cut it. But adding `libicuio` does the trick!
I'm opening a ticket here because I assume both of those should behave the same.
It's worth noting that if this is a bug, it's not just a GHCi issue. My other project that depends on text-icu just doesn't build (the same error happens during compilation).
Unfortunately I can't test on 8.4 right now.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Difference between 'libicuio' and 'icuio' in the 'extra-libraries' field","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I'm on Windows and I've recently updated my msys packages. One of them was libicu which I updated from version 58 to version 61. This caused one of my projects to stop building. \r\n\r\nI've managed to reproduce the problem by just cloning the text-icu package and trying to open the repl in it. This is the error I get:\r\n\r\n\r\n{{{\r\nGHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help\r\nghc.EXE: | C:\\Users\\darwi\\Projects\\text-icu\\.stack-work\\dist\\5c8418a7\\build\\cbits\\text_icu.o: unknown symbol `ucnv_getMaxCharSize_61'\r\nlinking extra libraries/objects failed\r\n}}}\r\n\r\nA similar error used to happen with icu 58, but I've \"fixed\" it (see this pull request https://github.com/bos/text-icu/pull/36). This time, however, adding `icuio` to `extra-libraries` doesn't cut it. But adding `libicuio` does the trick!\r\n\r\nI'm opening a ticket here because I assume both of those should behave the same.\r\n\r\nIt's worth noting that if this is a bug, it's not just a GHCi issue. My other project that depends on text-icu just doesn't build (the same error happens during compilation).\r\n\r\nUnfortunately I can't test on 8.4 right now.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15111GHCi leaks the first modules loaded2022-01-18T14:24:41ZSimon MarlowGHCi leaks the first modules loadedHow to reproduce the leak:
```
cd nofib/real/veritas
ghci +RTS -S
Prelude> :load Main
*Main> System.Mem.performGC
10554832 32639712 38824584 0.048 0.058 2.317 8.386 0 0 (Gen: 1)
```
Live data is \~38Mb (3rd number). ...How to reproduce the leak:
```
cd nofib/real/veritas
ghci +RTS -S
Prelude> :load Main
*Main> System.Mem.performGC
10554832 32639712 38824584 0.048 0.058 2.317 8.386 0 0 (Gen: 1)
```
Live data is \~38Mb (3rd number). Now unload everything:
```
*Main> :load
Prelude> System.Mem.performGC
4005376 32681280 38850224 0.013 0.048 2.330 29.896 0 0 (Gen: 1)
```
Note the live data didn't go down.
Load the program again:
```
Prelude> :load Main
...
*Main> System.Mem.performGC
16344112 47790304 54799632 0.070 0.074 4.343 82.235 0 0 (Gen: 1)
```
Note the live memory is almost 2x what it was before.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHCi leaks the first modules loaded","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":["ghci"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"How to reproduce the leak:\r\n\r\n{{{\r\ncd nofib/real/veritas\r\nghci +RTS -S\r\nPrelude> :load Main\r\n*Main> System.Mem.performGC\r\n 10554832 32639712 38824584 0.048 0.058 2.317 8.386 0 0 (Gen: 1)\r\n}}}\r\n\r\nLive data is ~38Mb (3rd number). Now unload everything:\r\n\r\n{{{\r\n*Main> :load\r\nPrelude> System.Mem.performGC\r\n 4005376 32681280 38850224 0.013 0.048 2.330 29.896 0 0 (Gen: 1)\r\n}}}\r\n\r\nNote the live data didn't go down.\r\n\r\nLoad the program again:\r\n\r\n{{{\r\nPrelude> :load Main\r\n...\r\n*Main> System.Mem.performGC\r\n 16344112 47790304 54799632 0.070 0.074 4.343 82.235 0 0 (Gen: 1)\r\n}}}\r\n\r\nNote the live memory is almost 2x what it was before.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/15055ghci - improve error on hidden package2019-07-07T18:14:31ZAlexander Kjeldaasghci - improve error on hidden packageA user boldly types:
```
> import Data.Foo
<no location info>: error:
Could not find module ‘Data.Foo’
It is a member of the hidden package ‘package-foo-0.1.0.0@package-foo-0.1.0.0-5Itxx5SAgKEAspB2MHVKqi’.
```
The above error ...A user boldly types:
```
> import Data.Foo
<no location info>: error:
Could not find module ‘Data.Foo’
It is a member of the hidden package ‘package-foo-0.1.0.0@package-foo-0.1.0.0-5Itxx5SAgKEAspB2MHVKqi’.
```
The above error message is rather useless for a newcomer to ghci. After lots of googling, the user figures that `:set -v -package package-foo` seems to solve it.
The original error should be:
```
> import Data.Foo
<no location info>: error:
Could not find module ‘Data.Foo’
It is a member of the hidden package ‘package-foo-0.1.0.0@package-foo-0.1.0.0-5Itxx5SAgKEAspB2MHVKqi’.
Try :set -package package-foo to make it visible.
```
Or something like that.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghci - improve error on hidden package","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"A user boldly types:\r\n\r\n{{{\r\n> import Data.Foo\r\n\r\n<no location info>: error:\r\n Could not find module ‘Data.Foo’\r\n It is a member of the hidden package ‘package-foo-0.1.0.0@package-foo-0.1.0.0-5Itxx5SAgKEAspB2MHVKqi’.\r\n}}}\r\n\r\nThe above error message is rather useless for a newcomer to ghci. After lots of googling, the user figures that `:set -v -package package-foo` seems to solve it.\r\n\r\nThe original error should be:\r\n\r\n{{{\r\n> import Data.Foo\r\n\r\n<no location info>: error:\r\n Could not find module ‘Data.Foo’\r\n It is a member of the hidden package ‘package-foo-0.1.0.0@package-foo-0.1.0.0-5Itxx5SAgKEAspB2MHVKqi’.\r\nTry :set -package package-foo to make it visible.\r\n}}}\r\n\r\nOr something like that.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Chaitanya Koparkarckoparkar@gmail.comChaitanya Koparkarckoparkar@gmail.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/15037Running 1 twice, followed by a typed hole, in GHCi causes internal error2019-07-07T18:14:36ZRyan ScottRunning 1 twice, followed by a typed hole, in GHCi causes internal errorOriginally reported in #14996\##15037. You need GHC HEAD (i.e., more recent than GHC 8.4.1) to trigger this:
```
$ inplace/bin/ghc-stage2 --interactive
GHCi, version 8.5.20180413: http://www.haskell.org/ghc/ :? for help
Loaded GHCi con...Originally reported in #14996\##15037. You need GHC HEAD (i.e., more recent than GHC 8.4.1) to trigger this:
```
$ inplace/bin/ghc-stage2 --interactive
GHCi, version 8.5.20180413: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
λ> 1
1
λ> 1
1
λ> _
<interactive>:1:1: error:
GHC internal error: ‘Ghci1.it’ is not in scope during type checking, but it passed the renamer
tcl_env of environment: []
```
And yes, running `1` //twice// seems to be critical to triggering this bug, for some reason.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.5 |
| 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":"Running 1 twice, followed by a typed hole, in GHCi causes internal error","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":["TypedHoles"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Originally reported in https://ghc.haskell.org/trac/ghc/ticket/14996#comment:2. You need GHC HEAD (i.e., more recent than GHC 8.4.1) to trigger this:\r\n\r\n{{{\r\n$ inplace/bin/ghc-stage2 --interactive\r\nGHCi, version 8.5.20180413: http://www.haskell.org/ghc/ :? for help\r\nLoaded GHCi configuration from /home/rgscott/.ghci\r\nλ> 1\r\n1\r\nλ> 1\r\n1\r\nλ> _\r\n\r\n<interactive>:1:1: error:\r\n GHC internal error: ‘Ghci1.it’ is not in scope during type checking, but it passed the renamer\r\n tcl_env of environment: []\r\n}}}\r\n\r\nAnd yes, running `1` //twice// seems to be critical to triggering this bug, for some reason.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15032GHCi panics when attempting to load archives2019-07-07T18:14:37ZvanessamchaleGHCi panics when attempting to load archivesIf I have the following module:
```hs
module Numeric.Integer ( is_prime_ats
) where
import Foreign.C
foreign import ccall is_prime_ats :: CInt -> CBool
```
and I attempt to open it in GHCi with the fo...If I have the following module:
```hs
module Numeric.Integer ( is_prime_ats
) where
import Foreign.C
foreign import ccall is_prime_ats :: CInt -> CBool
```
and I attempt to open it in GHCi with the following
```
/opt/ghc/bin/ghci-8.4.2 -lnumbertheory -L../dist-newstyle/lib Numeric.Integer
```
(with a file `libnumertheory.a` in `../dist-newstyle/lib`)
I get a panic and a request to open a bug report. I am guessing that at the least this supposed to be a different error message.
```
GHCi, version 8.4.1.20180329: http://www.haskell.org/ghc/ :? for help
ghc: panic! (the 'impossible' happened)
(GHC version 8.4.1.20180329 for x86_64-unknown-linux):
Loading archives not supported
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
If I instead place a shared library (i.e. `libnumbertheory.so`) in `../dist-newstyle/lib`) then this does not panic.8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15007Don't keep shadowed variables in ghci, both renamer and type checker2021-10-07T13:16:12ZTao Hesighingnow@gmail.comDon't keep shadowed variables in ghci, both renamer and type checkerIn #14052, we reverted [D2447](https://phabricator.haskell.org/D2447), then #11547 exists in HEAD again. In [ticket:14052\#comment:151549](https://gitlab.haskell.org//ghc/ghc/issues/14052#note_151549) and [ticket:14052\#comment:140478](h...In #14052, we reverted [D2447](https://phabricator.haskell.org/D2447), then #11547 exists in HEAD again. In [ticket:14052\#comment:151549](https://gitlab.haskell.org//ghc/ghc/issues/14052#note_151549) and [ticket:14052\#comment:140478](https://gitlab.haskell.org//ghc/ghc/issues/14052#note_140478), we decide that shadowed variables shouldn't be keep at all. This ticket is created to track the idea.
The same error of #11547 was also reported in [ticket:14996\#comment:151477](https://gitlab.haskell.org//ghc/ghc/issues/14996#note_151477),
> ```
> $ inplace/bin/ghc-stage2 --interactive
> GHCi, version 8.5.20180403: http://www.haskell.org/ghc/ :? for help
> Prelude> 1
> 1
> Prelude> 1
> 1
> Prelude> _
>
> <interactive>:1:1: error:
> GHC internal error: ‘Ghci1.it’ is not in scope during type > checking, but it passed the renamer
> tcl_env of environment: []
> ```
>
> (giving "1" twice is needed to reproduce the error)
NB: input "1" twice to create shadowed context is necessary to reproduce this bug.8.6.1Tao Hesighingnow@gmail.comTao Hesighingnow@gmail.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/14973Location in GHCi debugger prompt printed twice when default prompt is used2019-07-07T18:14:50ZÖmer Sinan AğacanLocation in GHCi debugger prompt printed twice when default prompt is used(Noticed in #8316)
Test.hs:
```haskell
foo :: [Int]
foo = [ 1 .. 10 ]
```
Reproducer:
```
$ ghc-stage2 --interactive -ignore-dot-ghci Test.hs
GHCi, version 8.5.20180325: http://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling Mai...(Noticed in #8316)
Test.hs:
```haskell
foo :: [Int]
foo = [ 1 .. 10 ]
```
Reproducer:
```
$ ghc-stage2 --interactive -ignore-dot-ghci Test.hs
GHCi, version 8.5.20180325: http://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling Main ( Test.hs, interpreted )
Ok, one module loaded.
*Main> :break foo
Breakpoint 0 activated at Test.hs:2:7-14
*Main> foo
Stopped in Main.foo, Test.hs:2:7-14
_result :: [Int] = _
[Test.hs:2:7-14] [Test.hs:2:7-14] *Main>
```
The `[Test.hs:2:7-14]` part is repeated. Setting the prompt fixes it:
```
$ ghc-stage2 --interactive Test.hs -ignore-dot-ghci
GHCi, version 8.5.20180325: http://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling Main ( Test.hs, interpreted )
Ok, one module loaded.
*Main> :set prompt "> "
> :break foo
Breakpoint 0 activated at Test.hs:2:7-14
> foo
Stopped in Main.foo, Test.hs:2:7-14
_result :: [Int] = _
[Test.hs:2:7-14] >
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.5 |
| 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":"Location in GHCi debugger prompt printed twice when default prompt is used","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":["debugger"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"(Noticed in #8316)\r\n\r\nTest.hs:\r\n\r\n{{{#!haskell\r\nfoo :: [Int]\r\nfoo = [ 1 .. 10 ]\r\n}}}\r\n\r\nReproducer:\r\n\r\n{{{\r\n$ ghc-stage2 --interactive -ignore-dot-ghci Test.hs\r\nGHCi, version 8.5.20180325: http://www.haskell.org/ghc/ :? for help\r\n[1 of 1] Compiling Main ( Test.hs, interpreted )\r\nOk, one module loaded.\r\n*Main> :break foo\r\nBreakpoint 0 activated at Test.hs:2:7-14\r\n*Main> foo\r\nStopped in Main.foo, Test.hs:2:7-14\r\n_result :: [Int] = _\r\n[Test.hs:2:7-14] [Test.hs:2:7-14] *Main>\r\n}}}\r\n\r\nThe `[Test.hs:2:7-14]` part is repeated. Setting the prompt fixes it:\r\n\r\n{{{\r\n$ ghc-stage2 --interactive Test.hs -ignore-dot-ghci\r\nGHCi, version 8.5.20180325: http://www.haskell.org/ghc/ :? for help\r\n[1 of 1] Compiling Main ( Test.hs, interpreted )\r\nOk, one module loaded.\r\n*Main> :set prompt \"> \"\r\n> :break foo\r\nBreakpoint 0 activated at Test.hs:2:7-14\r\n> foo\r\nStopped in Main.foo, Test.hs:2:7-14\r\n_result :: [Int] = _\r\n[Test.hs:2:7-14] >\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/14456Windows runtime linker failure with icuuc2019-07-07T18:16:58ZRyan ScottWindows runtime linker failure with icuucFirst, install `mingw-w64-x86_64-icu` (I'm using version 58.2-2):
```
$ pacman -S mingw-w64-x86_64-icu
```
Now take this file:
```hs
module Main where
import Data.Int
import Foreign
import Foreign.C.String
import Foreign.C.Types
typ...First, install `mingw-w64-x86_64-icu` (I'm using version 58.2-2):
```
$ pacman -S mingw-w64-x86_64-icu
```
Now take this file:
```hs
module Main where
import Data.Int
import Foreign
import Foreign.C.String
import Foreign.C.Types
type UErrorCode = CInt
u_ZERO_ERROR :: UErrorCode
u_ZERO_ERROR = 0
foreign import ccall "ucnv_open_58"
c_ucnv_open :: CString -> Ptr UErrorCode -> IO (Ptr ())
foreign import ccall "ucnv_getMaxCharSize_58"
c_ucnv_getMaxCharSize :: Ptr () -> IO Int8
main :: IO ()
main = with u_ZERO_ERROR $ \status -> do
conv <- c_ucnv_open nullPtr status
c_ucnv_getMaxCharSize conv >>= print
```
GHC is able to compile this successfully:
```
$ ghc -licuuc Bug2.hs
[1 of 1] Compiling Main ( Bug2.hs, Bug2.o )
Linking Bug2.exe ...
$ ./Bug2.exe
1
```
But GHCi is unable to accomplish the same thing:
```
$ runghc -licuuc Bug2.hs
ghc.exe: | C:\Users\RyanGlScott\Documents\Hacking\Haskell\Bug2.o: unknown symbol `ucnv_open_58'
Bug2.hs:
```
Phyx- and I discussed this briefly on IRC. He suspected that the fact that `C:\Windows\System32` now contains its own copy of `icuuc.dll` is contributing to the issue.8.6.1Tamar ChristinaTamar Christina