GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-06-26T17:46:37Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/16842References to unloaded CAFs due to stale static flag field2019-06-26T17:46:37ZBen GamariReferences to unloaded CAFs due to stale static flag fieldThis issues is the first item described by @lolotp here: https://gitlab.haskell.org/ghc/ghc/issues/16525#note_192087:
> There are still references to CAFs in the unloaded object code, but these CAFs were put on the revertible caf list (...This issues is the first item described by @lolotp here: https://gitlab.haskell.org/ghc/ghc/issues/16525#note_192087:
> There are still references to CAFs in the unloaded object code, but these CAFs were put on the revertible caf list (which set the static link field to 3) and thus were ignored by GC. Because of that, during the next GC, checkUnload determined that these ObjectCode struct can be freed despite the references into those ObjectCodes still existing. Next GC cycle would trigger crash while GC is trying to evacuate the mentioned CAFs.8.8.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/16832panic: getIdFromTrivialExpr | Type families, generics, fundeps2019-06-19T03:12:30ZSiddharthpanic: getIdFromTrivialExpr | Type families, generics, fundepsThis is on `GHCi, version 8.6.5`, in the file [`WorkingGenerics.hs`](https://github.com/bollu/paper-deltas/blob/master/src/WorkingGenerics.hs)
```
*Main> :load WorkingGenerics
[1 of 1] Compiling WorkingGenerics ( /home/bollu/work/pap...This is on `GHCi, version 8.6.5`, in the file [`WorkingGenerics.hs`](https://github.com/bollu/paper-deltas/blob/master/src/WorkingGenerics.hs)
```
*Main> :load WorkingGenerics
[1 of 1] Compiling WorkingGenerics ( /home/bollu/work/paper-deltas/src/WorkingGenerics.hs, interpreted )
ghc: panic! (the 'impossible' happened)
(GHC version 8.6.5 for x86_64-unknown-linux):
getIdFromTrivialExpr
(case a'_alGi of { })
`cast` (Sym (Nth:2
(Nth:3
(Inst (Sym (N:GDiff[0] (Rep_Void[0])) ; N:GDiff[0]
<Rep Void>_N) (Coh <Void>_N
(Sym (Nth:0
(Sym (N:GDiff[0]
(Rep_Void[0])) ; N:GDiff[0]
<Rep
Void>_N)))))))
:: Rep Void Void
~R# D1 ('MetaData "Void" "WorkingGenerics" "main" 'False) V1 Void)
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable
pprPanic, called at compiler/coreSyn/CoreUtils.hs:977:18 in ghc:CoreUtils
```
How to reproduce:
1. Clone [bollu/paper-deltas](https://github.com/bollu/paper-deltas/)
2. Run `stack ghci`
3. run `:load WorkingGenerics` in `GHCi`
I'm sorry, I have _no idea how to reduce_ this kind of bug.8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/16563ghci does not work if base is hidden2019-08-10T10:49:28ZMichael Snoymanmichael@snoyman.comghci does not work if base is hidden# Summary
Multiple tools (at least cabal and Stack) are capable of creating a situation with `ghci` where it will complain about missing the `System.IO` module, even though `ghci` knows it can be found in `base`.
# Steps to reproduce
...# Summary
Multiple tools (at least cabal and Stack) are capable of creating a situation with `ghci` where it will complain about missing the `System.IO` module, even though `ghci` knows it can be found in `base`.
# Steps to reproduce
```
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.6.4
$ cat ghc-env
clear-package-db
global-package-db
$ GHC_ENVIRONMENT=ghc-env ghci
GHCi, version 8.6.4: http://www.haskell.org/ghc/ :? for help
Loaded package environment from ghc-env
Loaded package environment from ghc-env
<interactive>:1:6: error:
Not in scope: ‘System.IO.hSetBuffering’
No module named ‘System.IO’ is imported.
<interactive>:1:30: error:
Not in scope: ‘System.IO.stdin’
No module named ‘System.IO’ is imported.
<interactive>:1:46: error:
Not in scope: data constructor ‘System.IO.NoBuffering’
No module named ‘System.IO’ is imported.
<interactive>:1:70: error:
Not in scope: ‘System.IO.hSetBuffering’
No module named ‘System.IO’ is imported.
<interactive>:1:94: error:
Not in scope: ‘System.IO.stdout’
No module named ‘System.IO’ is imported.
<interactive>:1:111: error:
Not in scope: data constructor ‘System.IO.NoBuffering’
No module named ‘System.IO’ is imported.
<interactive>:1:135: error:
Not in scope: ‘System.IO.hSetBuffering’
No module named ‘System.IO’ is imported.
<interactive>:1:159: error:
Not in scope: ‘System.IO.stderr’
No module named ‘System.IO’ is imported.
<interactive>:1:176: error:
Not in scope: data constructor ‘System.IO.NoBuffering’
No module named ‘System.IO’ is imported.
```
# Expected behavior
No warnings or errors should be printed. Instead, `ghci` should find `System.IO` in the `base` package.
# Environment
* GHC version used: 8.6.4, though this seems to apply to older versions as well.
Optional:
* Operating System: OS X
* System Architecture: x86-64
Related:
* https://github.com/haskell/cabal/issues/5988
* https://github.com/commercialhaskell/stack/issues/47068.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/16509GHCI panics: isUnliftedType2019-08-15T09:30:53ZAlex DGHCI panics: isUnliftedTypeGHC panics when the following program is loaded in ghci:
```haskell
{-# LANGUAGE PatternSynonyms #-}
{-# LANGUAGE ViewPatterns #-}
module PatternPanic
(
Outer(..),
Inner(..),
pattern TestPat
) where
data Oute...GHC panics when the following program is loaded in ghci:
```haskell
{-# LANGUAGE PatternSynonyms #-}
{-# LANGUAGE ViewPatterns #-}
module PatternPanic
(
Outer(..),
Inner(..),
pattern TestPat
) where
data Outer = Outer Inner Inner
data Inner = Inner Int Int
pattern TestPat :: String -> String -> Outer
pattern TestPat ref1 ref2 <-
Outer (Inner (extractRef -> Just ref1)
(extractRef -> Just ref2)
)
(Inner (isSameRef ref1 -> True)
(isSameRef ref2 -> True)
)
------------ Helper functions ------------
extractRef :: Int -> Maybe String
extractRef 0 = Nothing
extractRef v = Just $ show v
isSameRef :: String -> Int -> Bool
isSameRef refName e
| Just refName2 <- extractRef e
= refName == refName2
isSameRef _ _ = False
-- Note that the GHC panic does not happen if 'isSameRef' is replaced with the following version.
-- isSameRef :: String -> Int -> Bool
-- isSameRef refName e =
-- extractRef e == Just refName
```
Returns
```
GHCi, version 8.6.3: http://www.haskell.org/ghc/ :? for help
Prelude> :l PatternPanic.hs
[1 of 1] Compiling PatternPanic ( PatternPanic.hs, interpreted )
ghc: panic! (the 'impossible' happened)
(GHC version 8.6.3 for x86_64-apple-darwin):
isUnliftedType
r_a2Qa :: TYPE rep_a2Q9
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable
pprPanic, called at compiler/types/Type.hs:2021:10 in ghc:Type
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
This simplified code snippet was extracted from a relatively large codebase (~180k LOC). Note, that we would get the same error when we try to compile this application with `-O2` with ghc > 8.4. Unfortunately, I am not able to reproduce compilation failure with this minimal example, though.
I tried it with `GHC 8.9.20190323 x86_64-apple-darwin` - same error.
#14828 looks quite similar.
[pattern-panic.zip](/uploads/131454dd8e8815c72f87666db8c7f63f/pattern-panic.zip)8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/16415:doc command does not work on ghc boot libraries with ghc-8.6.42022-03-08T22:55:06ZTakenobu Tani:doc command does not work on ghc boot libraries with ghc-8.6.4In the GHC 8.6.4, GHCi's `:doc` command does not work on ghc boot libraries, such as `GHC.Base`.
Perhaps boot libraries of GHC 8.6.4 were compiled without the `-haddock` option.
At least, it occurs in linux and windows binaries of GHC...In the GHC 8.6.4, GHCi's `:doc` command does not work on ghc boot libraries, such as `GHC.Base`.
Perhaps boot libraries of GHC 8.6.4 were compiled without the `-haddock` option.
At least, it occurs in linux and windows binaries of GHC 8.6.4:
* https://downloads.haskell.org/~ghc/8.6.4/ghc-8.6.4-x86_64-deb9-linux.tar.xz
* https://downloads.haskell.org/~ghc/8.6.4/ghc-8.6.4-x86_64-unknown-mingw32.tar.xz
The error messages are as follows:
```
ghci> :doc id
ghc: Can't find any documentation for GHC.Base.
This is probably because the module was compiled without '-haddock',
but it's also possible that the module contains no documentation.
Try re-compiling with '-haddock'.
```
```
ghci> import Control.Monad.State
ghci> :doc State
ghc: Can't find any documentation for Control.Monad.Trans.State.Lazy.
This is probably because the module was compiled without '-haddock',
but it's also possible that the module contains no documentation.
Try re-compiling with '-haddock'.
```
Previous version of GHCi (ghc 8.6.3) could perform `:doc` command as follows.
```
ghci> :doc id
Identity function.
> id x = x
```
```
ghci> import Control.Monad.State
ghci> :doc State
A state monad parameterized by the type @s@ of the state to carry.
The 'return' function leaves the state unchanged, while @>>=@ uses
the final state of the first computation as the initial state of
the second.
```8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/16096let x = ... and x = ... are not the same in GHCi2023-08-29T00:32:44ZÖmer Sinan Ağacanlet x = ... and x = ... are not the same in GHCiWith #7253 we implemented support for `x = ...` in GHCi which is supposed to do the same thing as `let x = ...`, but they're currently different, as observed in #16089, #15721, and probably in other tickets. Here's a reproducer:
```
~ $...With #7253 we implemented support for `x = ...` in GHCi which is supposed to do the same thing as `let x = ...`, but they're currently different, as observed in #16089, #15721, and probably in other tickets. Here's a reproducer:
```
~ $ ghci -ddump-bcos
GHCi, version 8.4.4: http://www.haskell.org/ghc/ :? for help
...
λ:1> let x = [True,False]
==================== Proto-BCOs ====================
ProtoBCO ExprTopLevel_E0#0 []:
let sat_s1vF = ... in ...
bitmap: 0 []
PUSH_G GHC.Types.[]
PUSH_G GHC.Types.False
PACK : 2
PUSH_L 0
PUSH_G GHC.Types.True
PACK : 2
PUSH_G GHC.Types.[]
PUSH_L 1
PACK : 2
PUSH_L 0
PUSH_APPLY_P
PUSH_G GHC.Base.returnIO
SLIDE 3 3
ENTER
λ:2> x = [True,False]
==================== Proto-BCOs ====================
ProtoBCO x1_r1wJ#0 []:
GHC.Types.:
@ GHC.Types.Bool GHC.Types.False (GHC.Types.[] @ GHC.Types.Bool)
bitmap: 0 []
PUSH_G GHC.Types.[]
PUSH_G GHC.Types.False
PACK : 2
ENTER
ProtoBCO Ghci2.x#0 []:
GHC.Types.: @ GHC.Types.Bool GHC.Types.True x1_r1wJ
bitmap: 0 []
PUSH_G x1_r1wJ
PUSH_G GHC.Types.True
PACK : 2
ENTER
...
```
Expected behavior: these two should generate the same byte code, and should be subject to same checks (e.g. for shadowing).
(Example above uses 8.4.4, but this can be reproduced with GHC HEAD too)8.8.1Ömer Sinan AğacanÖmer Sinan Ağacanhttps://gitlab.haskell.org/ghc/ghc/-/issues/16089seq is not cooperating with :sprint in GHCi as expected2023-08-29T00:32:45Zradrowseq is not cooperating with :sprint in GHCi as expectedI was playing around with strictness and performed following test:
```hs
Prelude> x = [True, False]
Prelude> :sprint x
x = _
Prelude> x `seq` True
True
Prelude> :sprint x
x = _
```
I completely don't understand why `x = _` at this mome...I was playing around with strictness and performed following test:
```hs
Prelude> x = [True, False]
Prelude> :sprint x
x = _
Prelude> x `seq` True
True
Prelude> :sprint x
x = _
```
I completely don't understand why `x = _` at this moment. `seq` must evaluate one level of `x` achieving `x = True : _` to ensure that it is not `undefined`, so why is this information lost?
I am testing it on GHCi version 8.6.3, but it is not reproducible on other versions (checked on 8.4.4, 8.2.2 and 7._._).
I have asked about it on SO, so if this behavior is intended I kindly ask for explaination here [https://stackoverflow.com/questions/53898220/sprint-and-seq-together-missing-evaluation](https://stackoverflow.com/questions/53898220/sprint-and-seq-together-missing-evaluation) to let others know.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.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":"seq is not cooperating with :sprint in GHCi as expected","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":["seq","sprint","strictness"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I was playing around with strictness and performed following test:\r\n\r\n{{{#!hs\r\nPrelude> x = [True, False]\r\nPrelude> :sprint x\r\nx = _\r\nPrelude> x `seq` True\r\nTrue\r\nPrelude> :sprint x\r\nx = _\r\n}}}\r\n\r\nI completely don't understand why `x = _` at this moment. `seq` must evaluate one level of `x` achieving `x = True : _` to ensure that it is not `undefined`, so why is this information lost? \r\n\r\nI am testing it on GHCi version 8.6.3, but it is not reproducible on other versions (checked on 8.4.4, 8.2.2 and 7._._). \r\n\r\nI have asked about it on SO, so if this behavior is intended I kindly ask for explaination here [https://stackoverflow.com/questions/53898220/sprint-and-seq-together-missing-evaluation] to let others know.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/15721Command `:show bindings` throws exception for bindings without `let`2019-07-07T18:03:18ZTao Hesighingnow@gmail.comCommand `:show bindings` throws exception for bindings without `let`The command `:show bindings` works for `let a = 1`:
```hs
Prelude> let a = 1
Prelude> :show bindings
a :: Num p => p = _
```
But not for `a = 1`:
```hs
Prelude> a = 1
Prelude> :show bindings
ghc-stage2.exe: ^^ Could not load 'interact...The command `:show bindings` works for `let a = 1`:
```hs
Prelude> let a = 1
Prelude> :show bindings
a :: Num p => p = _
```
But not for `a = 1`:
```hs
Prelude> a = 1
Prelude> :show bindings
ghc-stage2.exe: ^^ Could not load 'interactive_Ghci1_zdtrModule2_closure', dependency unresolved. See top entry above.
ghc-stage2.exe: ^^ Could not load 'interactive_Ghci1_zdtrModule4_closure', dependency unresolved. See top entry above.
$trModule :: GHC.Types.Module = _
$trModule1 :: GHC.Types.TrName = _
$trModule2 ::
GHC.Prim.Addr# = *** Exception:
ByteCodeLink.lookupCE
During interactive linking, GHCi couldn't find the following symbol:
interactive_Ghci1_zdtrModule2_closure
This may be due to you not asking GHCi to load extra object files,
archives or DLLs needed by your current session. Restart GHCi, specifying
the missing library using the -L/path/to/object/dir and -lmissinglibname
flags, or simply by naming the relevant files on the GHCi command line.
Alternatively, this link failure might indicate a bug in GHCi.
If you suspect the latter, please send a bug report to:
glasgow-haskell-bugs@haskell.org
$trModule3 :: GHC.Types.TrName = _
$trModule4 ::
GHC.Prim.Addr# = *** Exception:
ByteCodeLink.lookupCE
During interactive linking, GHCi couldn't find the following symbol:
interactive_Ghci1_zdtrModule4_closure
This may be due to you not asking GHCi to load extra object files,
archives or DLLs needed by your current session. Restart GHCi, specifying
the missing library using the -L/path/to/object/dir and -lmissinglibname
flags, or simply by naming the relevant files on the GHCi command line.
Alternatively, this link failure might indicate a bug in GHCi.
If you suspect the latter, please send a bug report to:
glasgow-haskell-bugs@haskell.org
a :: Num p => p = _
a1 :: Integer = _
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Command `:show bindings` throws exception for bindings without `let`","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The command `:show bindings` works for `let a = 1`:\r\n\r\n{{{#!hs\r\nPrelude> let a = 1\r\nPrelude> :show bindings\r\na :: Num p => p = _\r\n}}}\r\n\r\nBut not for `a = 1`:\r\n\r\n{{{#!hs\r\nPrelude> a = 1\r\nPrelude> :show bindings\r\nghc-stage2.exe: ^^ Could not load 'interactive_Ghci1_zdtrModule2_closure', dependency unresolved. See top entry above.\r\n\r\nghc-stage2.exe: ^^ Could not load 'interactive_Ghci1_zdtrModule4_closure', dependency unresolved. See top entry above.\r\n\r\n$trModule :: GHC.Types.Module = _\r\n$trModule1 :: GHC.Types.TrName = _\r\n$trModule2 ::\r\n GHC.Prim.Addr# = *** Exception:\r\nByteCodeLink.lookupCE\r\nDuring interactive linking, GHCi couldn't find the following symbol:\r\n interactive_Ghci1_zdtrModule2_closure\r\nThis may be due to you not asking GHCi to load extra object files,\r\narchives or DLLs needed by your current session. Restart GHCi, specifying\r\nthe missing library using the -L/path/to/object/dir and -lmissinglibname\r\nflags, or simply by naming the relevant files on the GHCi command line.\r\nAlternatively, this link failure might indicate a bug in GHCi.\r\nIf you suspect the latter, please send a bug report to:\r\n glasgow-haskell-bugs@haskell.org\r\n\r\n$trModule3 :: GHC.Types.TrName = _\r\n$trModule4 ::\r\n GHC.Prim.Addr# = *** Exception:\r\nByteCodeLink.lookupCE\r\nDuring interactive linking, GHCi couldn't find the following symbol:\r\n interactive_Ghci1_zdtrModule4_closure\r\nThis may be due to you not asking GHCi to load extra object files,\r\narchives or DLLs needed by your current session. Restart GHCi, specifying\r\nthe missing library using the -L/path/to/object/dir and -lmissinglibname\r\nflags, or simply by naming the relevant files on the GHCi command line.\r\nAlternatively, this link failure might indicate a bug in GHCi.\r\nIf you suspect the latter, please send a bug report to:\r\n glasgow-haskell-bugs@haskell.org\r\n\r\na :: Num p => p = _\r\na1 :: Integer = _\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/15443ghc panic when running GI.init on intero REPL2019-07-07T18:04:52Zesclerofiloghc panic when running GI.init on intero REPLI cloned the [https://github.com/haskell-gi/gi-gtk-examples](https://github.com/haskell-gi/gi-gtk-examples) repo to learn to use gi-gtk, deleted all version numbers in the .cabal file to make it build with the latest stack resolver (lts-...I cloned the [https://github.com/haskell-gi/gi-gtk-examples](https://github.com/haskell-gi/gi-gtk-examples) repo to learn to use gi-gtk, deleted all version numbers in the .cabal file to make it build with the latest stack resolver (lts-12.2) and then opened ButtonBox.hs in emacs (spacemacs) with intero, opened the intero repl (without actually loading the buffer into the repl\*) and what happened follows:
```
Starting:
stack ghci --with-ghc ghci "--docker-run-args=--interactive=true --tty=false" --no-build --no-load gi-gtk-examples
GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/vicente/Escritorio/gi-gtk-examples/.stack-work/intero/intero-scriptBbJ8Bq
λ import qualified GI.Gtk as GI (main, init)
λ GI.init Nothing
ghc: panic! (the 'impossible' happened)
(GHC version 8.4.3 for x86_64-unknown-linux):
nameModule
system $dShow_a8qH
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable
pprPanic, called at compiler/basicTypes/Name.hs:241:3 in ghc:Name
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
the contents of `/home/vicente/Escritorio/gi-gtk-examples/.stack-work/intero/intero-scriptBbJ8Bq` are:
```
:set prompt ""
:set -fbyte-code
:set -fdefer-type-errors
:set -fdiagnostics-color=never
:set prompt "\4 "
```
Note: It happens on a terminal ghci invocation too, given the same parameters and configuration.
<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":"ghc panic when running GI.init on intero REPL","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":"I cloned the [https://github.com/haskell-gi/gi-gtk-examples] repo to learn to use gi-gtk, deleted all version numbers in the .cabal file to make it build with the latest stack resolver (lts-12.2) and then opened ButtonBox.hs in emacs (spacemacs) with intero, opened the intero repl (without actually loading the buffer into the repl*) and what happened follows:\r\n\r\n{{{\r\nStarting:\r\n stack ghci --with-ghc ghci \"--docker-run-args=--interactive=true --tty=false\" --no-build --no-load gi-gtk-examples\r\nGHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help\r\nLoaded GHCi configuration from /home/vicente/Escritorio/gi-gtk-examples/.stack-work/intero/intero-scriptBbJ8Bq\r\nλ import qualified GI.Gtk as GI (main, init)\r\nλ GI.init Nothing\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.4.3 for x86_64-unknown-linux):\r\n\tnameModule\r\n system $dShow_a8qH\r\n Call stack:\r\n CallStack (from HasCallStack):\r\n callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable\r\n pprPanic, called at compiler/basicTypes/Name.hs:241:3 in ghc:Name\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nthe contents of {{{/home/vicente/Escritorio/gi-gtk-examples/.stack-work/intero/intero-scriptBbJ8Bq}}} are:\r\n\r\n{{{\r\n:set prompt \"\"\r\n:set -fbyte-code\r\n:set -fdefer-type-errors\r\n:set -fdiagnostics-color=never\r\n:set prompt \"\\4 \"\r\n}}}\r\n\r\nNote: It happens on a terminal ghci invocation too, given the same parameters and configuration.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/15336./System/IO.hs accidentally overridden when running ghci2019-08-10T10:51:32Zluqui./System/IO.hs accidentally overridden when running ghciRunning ghci fails if there is a System/IO.hs module present in the current directory. Doesn't seem like desirable behavior.
```
% mkdir System
% touch System/IO.hs
% ghci
GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help
<...Running ghci fails if there is a System/IO.hs module present in the current directory. Doesn't seem like desirable behavior.
```
% mkdir System
% touch System/IO.hs
% ghci
GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help
<interactive>:1:19: error:
Not in scope: ‘System.IO.hSetBuffering’
No module named ‘System.IO’ is imported.
<interactive>:1:43: error:
Not in scope: ‘System.IO.stdin’
No module named ‘System.IO’ is imported.
<interactive>:1:60: error:
Not in scope: data constructor ‘System.IO.NoBuffering’
No module named ‘System.IO’ is imported.
<interactive>:1:99: error:
Not in scope: ‘System.IO.hSetBuffering’
No module named ‘System.IO’ is imported.
<interactive>:1:123: error:
Not in scope: ‘System.IO.stdout’
No module named ‘System.IO’ is imported.
<interactive>:1:140: error:
Not in scope: data constructor ‘System.IO.NoBuffering’
No module named ‘System.IO’ is imported.
<interactive>:1:179: error:
Not in scope: ‘System.IO.hSetBuffering’
No module named ‘System.IO’ is imported.
<interactive>:1:203: error:
Not in scope: ‘System.IO.stderr’
No module named ‘System.IO’ is imported.
<interactive>:1:220: error:
Not in scope: data constructor ‘System.IO.NoBuffering’
No module named ‘System.IO’ is imported.
```
<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":"./System/IO.hs accidentally overridden when running ghci","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":"Running ghci fails if there is a System/IO.hs module present in the current directory. Doesn't seem like desirable behavior.\r\n\r\n{{{\r\n% mkdir System\r\n% touch System/IO.hs\r\n% ghci\r\nGHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help\r\n\r\n<interactive>:1:19: error:\r\n Not in scope: ‘System.IO.hSetBuffering’\r\n No module named ‘System.IO’ is imported.\r\n\r\n<interactive>:1:43: error:\r\n Not in scope: ‘System.IO.stdin’\r\n No module named ‘System.IO’ is imported.\r\n\r\n<interactive>:1:60: error:\r\n Not in scope: data constructor ‘System.IO.NoBuffering’\r\n No module named ‘System.IO’ is imported.\r\n\r\n<interactive>:1:99: error:\r\n Not in scope: ‘System.IO.hSetBuffering’\r\n No module named ‘System.IO’ is imported.\r\n\r\n<interactive>:1:123: error:\r\n Not in scope: ‘System.IO.stdout’\r\n No module named ‘System.IO’ is imported.\r\n\r\n<interactive>:1:140: error:\r\n Not in scope: data constructor ‘System.IO.NoBuffering’\r\n No module named ‘System.IO’ is imported.\r\n\r\n<interactive>:1:179: error:\r\n Not in scope: ‘System.IO.hSetBuffering’\r\n No module named ‘System.IO’ is imported.\r\n\r\n<interactive>:1:203: error:\r\n Not in scope: ‘System.IO.stderr’\r\n No module named ‘System.IO’ is imported.\r\n\r\n<interactive>:1:220: error:\r\n Not in scope: data constructor ‘System.IO.NoBuffering’\r\n No module named ‘System.IO’ is imported.\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/15246-fghci-leak-cheak causes many testsuite failures with the quick build flavour2019-07-07T18:13:38ZRyan Scott-fghci-leak-cheak causes many testsuite failures with the quick build flavourAs [originally reported](https://mail.haskell.org/pipermail/ghc-devs/2018-May/015812.html) on the ghc-devs mailing list, the `-fghci-leak-check` flag is causing several tests to fail when GHC is built with the quick build flavour. On my ...As [originally reported](https://mail.haskell.org/pipermail/ghc-devs/2018-May/015812.html) on the ghc-devs mailing list, the `-fghci-leak-check` flag is causing several tests to fail when GHC is built with the quick build flavour. On my machine, here are all the tests that fail:
```
Unexpected failures:
ghci/prog001/prog001.run prog001 [bad stdout] (ghci)
ghci/prog002/prog002.run prog002 [bad stdout] (ghci)
ghci/prog003/prog003.run prog003 [bad stdout] (ghci)
ghci/prog010/ghci.prog010.run ghci.prog010 [bad stdout] (ghci)
ghci/prog013/prog013.run prog013 [bad stdout] (ghci)
ghci/prog012/prog012.run prog012 [bad stdout] (ghci)
ghci/prog009/ghci.prog009.run ghci.prog009 [bad stdout] (ghci)
ghci/scripts/ghci025.run ghci025 [bad stdout] (ghci)
ghci/scripts/ghci038.run ghci038 [bad stdout] (ghci)
ghci/scripts/ghci057.run ghci057 [bad stdout] (ghci)
ghci/scripts/T2182ghci.run T2182ghci [bad stdout] (ghci)
ghci/scripts/ghci058.run ghci058 [bad stdout] (ghci)
ghci/scripts/T6106.run T6106 [bad stdout] (ghci)
ghci/scripts/T8353.run T8353 [bad stdout] (ghci)
ghci/scripts/T9293.run T9293 [bad stdout] (ghci)
ghci/scripts/T10989.run T10989 [bad stdout] (ghci)
ghci/should_run/T13825-ghci.run T13825-ghci [bad stdout] (ghci)
ghci.debugger/scripts/print007.run print007 [bad stdout] (ghci)
ghci.debugger/scripts/break009.run break009 [bad stdout] (ghci)
ghci.debugger/scripts/break008.run break008 [bad stdout] (ghci)
ghci.debugger/scripts/break026.run break026 [bad stdout] (ghci)
perf/space_leaks/T4029.run T4029 [bad stdout] (ghci)
```
[Here](https://gist.githubusercontent.com/RyanGlScott/f920737287049b82947e1c47cdbc2b94/raw/4fe68d47cc78675424e09cf451be556c6f430d08/gistfile1.txt) is the full test output. Generally, the test output discrepancies are all of the form of extra lines of:
```
+-fghci-leak-check: HomeModInfo for D is still alive!
+-fghci-leak-check: ModIface is still alive!
+-fghci-leak-check: ModDetails is still alive!
+-fghci-leak-check: Linkable is still alive!
```
<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 | simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"-fghci-leak-cheak causes many testsuite failures with the quick build flavour","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":["simonmar"],"type":"Bug","description":"As [https://mail.haskell.org/pipermail/ghc-devs/2018-May/015812.html originally reported] on the ghc-devs mailing list, the `-fghci-leak-check` flag is causing several tests to fail when GHC is built with the quick build flavour. On my machine, here are all the tests that fail:\r\n\r\n{{{\r\nUnexpected failures:\r\n ghci/prog001/prog001.run prog001 [bad stdout] (ghci)\r\n ghci/prog002/prog002.run prog002 [bad stdout] (ghci)\r\n ghci/prog003/prog003.run prog003 [bad stdout] (ghci)\r\n ghci/prog010/ghci.prog010.run ghci.prog010 [bad stdout] (ghci)\r\n ghci/prog013/prog013.run prog013 [bad stdout] (ghci)\r\n ghci/prog012/prog012.run prog012 [bad stdout] (ghci)\r\n ghci/prog009/ghci.prog009.run ghci.prog009 [bad stdout] (ghci)\r\n ghci/scripts/ghci025.run ghci025 [bad stdout] (ghci)\r\n ghci/scripts/ghci038.run ghci038 [bad stdout] (ghci)\r\n ghci/scripts/ghci057.run ghci057 [bad stdout] (ghci)\r\n ghci/scripts/T2182ghci.run T2182ghci [bad stdout] (ghci)\r\n ghci/scripts/ghci058.run ghci058 [bad stdout] (ghci)\r\n ghci/scripts/T6106.run T6106 [bad stdout] (ghci)\r\n ghci/scripts/T8353.run T8353 [bad stdout] (ghci)\r\n ghci/scripts/T9293.run T9293 [bad stdout] (ghci)\r\n ghci/scripts/T10989.run T10989 [bad stdout] (ghci)\r\n ghci/should_run/T13825-ghci.run T13825-ghci [bad stdout] (ghci)\r\n ghci.debugger/scripts/print007.run print007 [bad stdout] (ghci)\r\n ghci.debugger/scripts/break009.run break009 [bad stdout] (ghci)\r\n ghci.debugger/scripts/break008.run break008 [bad stdout] (ghci)\r\n ghci.debugger/scripts/break026.run break026 [bad stdout] (ghci)\r\n perf/space_leaks/T4029.run T4029 [bad stdout] (ghci)\r\n}}}\r\n\r\n[https://gist.githubusercontent.com/RyanGlScott/f920737287049b82947e1c47cdbc2b94/raw/4fe68d47cc78675424e09cf451be556c6f430d08/gistfile1.txt Here] is the full test output. Generally, the test output discrepancies are all of the form of extra lines of:\r\n\r\n{{{\r\n+-fghci-leak-check: HomeModInfo for D is still alive!\r\n+-fghci-leak-check: ModIface is still alive!\r\n+-fghci-leak-check: ModDetails is still alive!\r\n+-fghci-leak-check: Linkable is still alive!\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/14551GHCi ignores -XMonomorphismRestriction and -XNoExtendedDefaultRules2019-07-07T18:16:32ZDavid FeuerGHCi ignores -XMonomorphismRestriction and -XNoExtendedDefaultRulesBecause of the way the GHCi defaults are applied, specifying `-XMonomorphismRestriction` or `-XNoExtendedDefaultRules` on the GHCi command line doesn't actually make those take effect at the interactive prompt. They get reset to their in...Because of the way the GHCi defaults are applied, specifying `-XMonomorphismRestriction` or `-XNoExtendedDefaultRules` on the GHCi command line doesn't actually make those take effect at the interactive prompt. They get reset to their interactive defaults afterwards. This is rather surprising, and I think it should be fixed.
```
dfeuer@squirrel> ghci -XMonomorphismRestriction
Prelude> x = 3
Prelude> :t x
x :: Num t => t -- What? I said I wanted the restriction!
Prelude> :set -XMonomorphismRestriction
Prelude> y = 3
Prelude> :t y
y :: Integer
```
One option is to dig through the parsed flags after setting the defaults to try to find these, but that sounds unpleasant. We're slowly accumulating hacks in this area, and it would be nice to find a better approach.8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/14336ghci leaks memory2019-07-07T18:17:25ZNeil Mitchellghci leaks memoryThe following script spawns ghci, and that spawned ghci then goes on to leak memory:
```hs
import Control.Concurrent
import Control.Monad
import System.IO
import System.Process
main = do
(Just hin, Nothing, Nothing, pid) <- createP...The following script spawns ghci, and that spawned ghci then goes on to leak memory:
```hs
import Control.Concurrent
import Control.Monad
import System.IO
import System.Process
main = do
(Just hin, Nothing, Nothing, pid) <- createProcess (proc "ghci" ["+RTS","-S"]){std_in=CreatePipe}
forever $ do
threadDelay 100000 -- 0.1s
hPutStrLn hin "\"this is a test of outputting stuff\""
hFlush hin
```
This script just writes a string to GHCi, which then echos it back. The `+RTS -S` is useful to watch the live memory tick up in realtime, but it leaks without it, and the leak can be seen in process explorer (87Mb to 700Mb over about 30 minutes).
While repeatedly writing commands may not be a standard usage of ghci, it is when driven by tools such as ghcid (https://hackage.haskell.org/package/ghcid) and other IDE-like uses.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.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 leaks memory","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following script spawns ghci, and that spawned ghci then goes on to leak memory:\r\n\r\n{{{#!hs\r\nimport Control.Concurrent\r\nimport Control.Monad\r\nimport System.IO\r\nimport System.Process\r\n\r\nmain = do\r\n (Just hin, Nothing, Nothing, pid) <- createProcess (proc \"ghci\" [\"+RTS\",\"-S\"]){std_in=CreatePipe}\r\n forever $ do\r\n threadDelay 100000 -- 0.1s\r\n hPutStrLn hin \"\\\"this is a test of outputting stuff\\\"\"\r\n hFlush hin\r\n}}}\r\n\r\nThis script just writes a string to GHCi, which then echos it back. The {{{+RTS -S}}} is useful to watch the live memory tick up in realtime, but it leaks without it, and the leak can be seen in process explorer (87Mb to 700Mb over about 30 minutes).\r\n\r\nWhile repeatedly writing commands may not be a standard usage of ghci, it is when driven by tools such as ghcid (https://hackage.haskell.org/package/ghcid) and other IDE-like uses.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/13862Optional "-v" not allowed with :load in GHCi2019-07-07T18:19:47ZvantoOptional "-v" not allowed with :load in GHCiWhen loading a file in GHCi with the command `:load` and the file must import another file, if that other file is unavailable then GHCi sends the following error\\\\
```
Failed to load interface for `xxx`
Use -v to see a list of the fil...When loading a file in GHCi with the command `:load` and the file must import another file, if that other file is unavailable then GHCi sends the following error\\\\
```
Failed to load interface for `xxx`
Use -v to see a list of the files searched for.
```
' xxx ' is the name of the imported file that GHCi cannot find.\\\\
But we can not use a flag ( ie -v) with the command `:load` in GHCi.\\\\
This error is not appropriate in GHCi when using `:load`
<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":"Optional \"-v\" not allowed with :load in GHCi","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When loading a file in GHCi with the command {{{:load}}} and the file must import another file, if that other file is unavailable then GHCi sends the following error\\\\\r\n\r\n{{{\r\nFailed to load interface for `xxx`\r\nUse -v to see a list of the files searched for.\r\n}}}\r\n' xxx ' is the name of the imported file that GHCi cannot find.\\\\\r\nBut we can not use a flag ( ie -v) with the command {{{:load}}} in GHCi.\\\\\r\nThis error is not appropriate in GHCi when using {{{:load}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Roland SennRoland Sennhttps://gitlab.haskell.org/ghc/ghc/-/issues/13786GHCi linker is dependent upon object file order2020-02-17T11:34:32ZppelletiGHCi linker is dependent upon object file orderUsing [this package](https://github.com/ppelleti/hs-mercury-api), I tried doing "stack repl" with GHC 8.0.2:
```
whiteandnerdy:hs-mercury-api ppelleti$ stack repl
The following GHC options are incompatible with GHCi and have not been pa...Using [this package](https://github.com/ppelleti/hs-mercury-api), I tried doing "stack repl" with GHC 8.0.2:
```
whiteandnerdy:hs-mercury-api ppelleti$ stack repl
The following GHC options are incompatible with GHCi and have not been passed to it: -threaded
* * * * * * * *
The main module to load is ambiguous. Candidates are:
1. Package `mercury-api' component exe:tmr-firmware with main-is file: /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-firmware.hs
2. Package `mercury-api' component exe:tmr-gpio with main-is file: /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-gpio.hs
3. Package `mercury-api' component exe:tmr-lock with main-is file: /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-lock.hs
4. Package `mercury-api' component exe:tmr-params with main-is file: /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-params.hs
5. Package `mercury-api' component exe:tmr-read with main-is file: /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-read.hs
6. Package `mercury-api' component exe:tmr-write with main-is file: /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-write.hs
You can specify which one to pick by:
* Specifying targets to stack ghci e.g. stack ghci mercury-api:exe:tmr-firmware
* Specifying what the main is e.g. stack ghci --main-is mercury-api:exe:tmr-firmware
* Choosing from the candidate above [1..6]
* * * * * * * *
Specify main module to use (press enter to load none): 4
Loading main module from cadidate 4, --main-is /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-params.hs
Configuring GHCi with the following packages: mercury-api
GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help
ghc: panic! (the 'impossible' happened)
(GHC version 8.0.2 for x86_64-apple-darwin):
Loading temp shared object failed: dlopen(/var/folders/d1/v9ptqpx12mdcxj77509440rc0000gn/T/ghc91859_0/libghc_5.dylib, 5): Symbol not found: _TMR_SR_cmdStopReading
Referenced from: /var/folders/d1/v9ptqpx12mdcxj77509440rc0000gn/T/ghc91859_0/libghc_5.dylib
Expected in: flat namespace
in /var/folders/d1/v9ptqpx12mdcxj77509440rc0000gn/T/ghc91859_0/libghc_5.dylib
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
This bug appears to have been around a while, because it also happens with GHC 7.8.3:
```
whiteandnerdy:hs-mercury-api ppelleti$ cabal repl
Preprocessing library mercury-api-0.1.0.0...
GHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package array-0.5.0.0 ... linking ... done.
Loading package deepseq-1.3.0.2 ... linking ... done.
Loading package bytestring-0.10.4.0 ... linking ... done.
Loading package containers-0.5.5.1 ... linking ... done.
Loading package binary-0.7.1.0 ... linking ... done.
Loading package text-1.2.2.1 ... linking ... done.
Loading package hashable-1.2.6.0 ... linking ... done.
Loading package unordered-containers-0.2.8.0 ... linking ... done.
Loading package clock-0.7.2 ... linking ... done.
Loading package old-locale-1.0.0.6 ... linking ... done.
Loading package time-1.4.2 ... linking ... done.
Loading package unix-2.7.0.1 ... linking ... done.
Loading package ansi-terminal-0.6.2.3 ... linking ... done.
Loading object (static) dist/build/cbits/api/tmr_strerror.o ... done
Loading object (static) dist/build/cbits/api/tmr_param.o ... done
Loading object (static) dist/build/cbits/api/hex_bytes.o ... done
Loading object (static) dist/build/cbits/api/tm_reader.o ... ghc: panic! (the 'impossible' happened)
(GHC version 7.8.3 for x86_64-apple-darwin):
Loading temp shared object failed: dlopen(/var/folders/d1/v9ptqpx12mdcxj77509440rc0000gn/T/ghc91576_0/ghc91576_4.dylib, 9): Symbol not found: _TMR_SR_SerialTransportNativeInit
Referenced from: /var/folders/d1/v9ptqpx12mdcxj77509440rc0000gn/T/ghc91576_0/ghc91576_4.dylib
Expected in: flat namespace
in /var/folders/d1/v9ptqpx12mdcxj77509440rc0000gn/T/ghc91576_0/ghc91576_4.dylib
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
I'm using Mac OS X 10.9.5:
```
whiteandnerdy:hs-mercury-api ppelleti$ uname -a
Darwin whiteandnerdy.lan 13.4.0 Darwin Kernel Version 13.4.0: Mon Jan 11 18:17:34 PST 2016; root:xnu-2422.115.15~1/RELEASE_X86_64 x86_64
```
<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 | MacOS X |
| Architecture | x86_64 (amd64) |
</details>
<!-- {"blocked_by":[],"summary":"GHC panic on Mac OS X with \"cabal repl\" / \"stack repl\" on GHC 8.0.2 and 7.8.3","status":"New","operating_system":"MacOS X","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.2","keywords":[],"differentials":[],"test_case":"","architecture":"x86_64 (amd64)","cc":[""],"type":"Bug","description":"Using [https://github.com/ppelleti/hs-mercury-api this package], I tried doing \"stack repl\" with GHC 8.0.2:\r\n\r\n{{{\r\nwhiteandnerdy:hs-mercury-api ppelleti$ stack repl\r\nThe following GHC options are incompatible with GHCi and have not been passed to it: -threaded\r\n\r\n* * * * * * * *\r\nThe main module to load is ambiguous. Candidates are: \r\n1. Package `mercury-api' component exe:tmr-firmware with main-is file: /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-firmware.hs\r\n2. Package `mercury-api' component exe:tmr-gpio with main-is file: /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-gpio.hs\r\n3. Package `mercury-api' component exe:tmr-lock with main-is file: /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-lock.hs\r\n4. Package `mercury-api' component exe:tmr-params with main-is file: /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-params.hs\r\n5. Package `mercury-api' component exe:tmr-read with main-is file: /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-read.hs\r\n6. Package `mercury-api' component exe:tmr-write with main-is file: /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-write.hs\r\nYou can specify which one to pick by: \r\n * Specifying targets to stack ghci e.g. stack ghci mercury-api:exe:tmr-firmware\r\n * Specifying what the main is e.g. stack ghci --main-is mercury-api:exe:tmr-firmware\r\n * Choosing from the candidate above [1..6]\r\n* * * * * * * *\r\n\r\nSpecify main module to use (press enter to load none): 4\r\nLoading main module from cadidate 4, --main-is /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-params.hs\r\n\r\nConfiguring GHCi with the following packages: mercury-api\r\nGHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.0.2 for x86_64-apple-darwin):\r\n\tLoading temp shared object failed: dlopen(/var/folders/d1/v9ptqpx12mdcxj77509440rc0000gn/T/ghc91859_0/libghc_5.dylib, 5): Symbol not found: _TMR_SR_cmdStopReading\r\n Referenced from: /var/folders/d1/v9ptqpx12mdcxj77509440rc0000gn/T/ghc91859_0/libghc_5.dylib\r\n Expected in: flat namespace\r\n in /var/folders/d1/v9ptqpx12mdcxj77509440rc0000gn/T/ghc91859_0/libghc_5.dylib\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nThis bug appears to have been around a while, because it also happens with GHC 7.8.3:\r\n\r\n{{{\r\nwhiteandnerdy:hs-mercury-api ppelleti$ cabal repl\r\nPreprocessing library mercury-api-0.1.0.0...\r\nGHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer-gmp ... linking ... done.\r\nLoading package base ... linking ... done.\r\nLoading package array-0.5.0.0 ... linking ... done.\r\nLoading package deepseq-1.3.0.2 ... linking ... done.\r\nLoading package bytestring-0.10.4.0 ... linking ... done.\r\nLoading package containers-0.5.5.1 ... linking ... done.\r\nLoading package binary-0.7.1.0 ... linking ... done.\r\nLoading package text-1.2.2.1 ... linking ... done.\r\nLoading package hashable-1.2.6.0 ... linking ... done.\r\nLoading package unordered-containers-0.2.8.0 ... linking ... done.\r\nLoading package clock-0.7.2 ... linking ... done.\r\nLoading package old-locale-1.0.0.6 ... linking ... done.\r\nLoading package time-1.4.2 ... linking ... done.\r\nLoading package unix-2.7.0.1 ... linking ... done.\r\nLoading package ansi-terminal-0.6.2.3 ... linking ... done.\r\nLoading object (static) dist/build/cbits/api/tmr_strerror.o ... done\r\nLoading object (static) dist/build/cbits/api/tmr_param.o ... done\r\nLoading object (static) dist/build/cbits/api/hex_bytes.o ... done\r\nLoading object (static) dist/build/cbits/api/tm_reader.o ... ghc: panic! (the 'impossible' happened)\r\n (GHC version 7.8.3 for x86_64-apple-darwin):\r\n\tLoading temp shared object failed: dlopen(/var/folders/d1/v9ptqpx12mdcxj77509440rc0000gn/T/ghc91576_0/ghc91576_4.dylib, 9): Symbol not found: _TMR_SR_SerialTransportNativeInit\r\n Referenced from: /var/folders/d1/v9ptqpx12mdcxj77509440rc0000gn/T/ghc91576_0/ghc91576_4.dylib\r\n Expected in: flat namespace\r\n in /var/folders/d1/v9ptqpx12mdcxj77509440rc0000gn/T/ghc91576_0/ghc91576_4.dylib\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nI'm using Mac OS X 10.9.5:\r\n\r\n{{{\r\nwhiteandnerdy:hs-mercury-api ppelleti$ uname -a\r\nDarwin whiteandnerdy.lan 13.4.0 Darwin Kernel Version 13.4.0: Mon Jan 11 18:17:34 PST 2016; root:xnu-2422.115.15~1/RELEASE_X86_64 x86_64\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/13617GHCi linker does not honor alignment of sections.2019-07-07T18:20:57ZRyan ScottGHCi linker does not honor alignment of sections.This is a very elusive bug that I noticed when running an `hmatrix` example under GHCi on Windows. Luckily, this example can be reduced down to a couple of `.hs` files and a single `.c` file (with no other Haskell or C dependencies). Unf...This is a very elusive bug that I noticed when running an `hmatrix` example under GHCi on Windows. Luckily, this example can be reduced down to a couple of `.hs` files and a single `.c` file (with no other Haskell or C dependencies). Unfortunately, I can't quite figure out a way to reproduce this bug without `cabal`, so I've put the source code at https://github.com/RyanGlScott/hmatrix-segfault. You can reproduce this bug by doing the following:
```
$ git clone https://github.com/RyanGlScott/hmatrix-segfault
$ git reset 2bfe38f964fca64dd776993c89ec59d35fb368a5
$ cd hmatrix-segfault/
$ cabal install
$ runghc exe/Main.hs
Access violation in generated code when reading ffffffffffffffff
```
Running `Main.hs` in GHCi crashes, whereas compiling it works:
```
$ ghc exe/Main.hs
$ ./exe/Main.exe
[1,1,1,1,1,1,1,1,1,1,1,1]
```
I've reproduced this with GHC 7.10.3, 8.0.2, and 8.2.1-rc1.
There are a couple of things that appear to be necessary to trigger the segfault:
1. You need to have `-O4` under `cc-options` in `hmatrix-segfault.cabal`.
1. You need to define the [FunCodeS](https://github.com/RyanGlScott/hmatrix-segfault/blob/2bfe38f964fca64dd776993c89ec59d35fb368a5/src/Internal/Vectorized.hs#L38) datatype.
Removing either of these things causes the program to work again under GHCi.
<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 | Phyx- |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Segfault in Windows GHCi involving C code compiled with -O4","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["Phyx-"],"type":"Bug","description":"This is a very elusive bug that I noticed when running an `hmatrix` example under GHCi on Windows. Luckily, this example can be reduced down to a couple of `.hs` files and a single `.c` file (with no other Haskell or C dependencies). Unfortunately, I can't quite figure out a way to reproduce this bug without `cabal`, so I've put the source code at https://github.com/RyanGlScott/hmatrix-segfault. You can reproduce this bug by doing the following:\r\n\r\n{{{\r\n$ git clone https://github.com/RyanGlScott/hmatrix-segfault\r\n$ git reset 2bfe38f964fca64dd776993c89ec59d35fb368a5\r\n$ cd hmatrix-segfault/\r\n$ cabal install\r\n$ runghc exe/Main.hs\r\nAccess violation in generated code when reading ffffffffffffffff\r\n}}}\r\n\r\nRunning `Main.hs` in GHCi crashes, whereas compiling it works:\r\n\r\n{{{\r\n$ ghc exe/Main.hs\r\n$ ./exe/Main.exe\r\n[1,1,1,1,1,1,1,1,1,1,1,1]\r\n}}}\r\n\r\nI've reproduced this with GHC 7.10.3, 8.0.2, and 8.2.1-rc1.\r\n\r\nThere are a couple of things that appear to be necessary to trigger the segfault:\r\n\r\n1. You need to have `-O4` under `cc-options` in `hmatrix-segfault.cabal`.\r\n2. You need to define the [https://github.com/RyanGlScott/hmatrix-segfault/blob/2bfe38f964fca64dd776993c89ec59d35fb368a5/src/Internal/Vectorized.hs#L38 FunCodeS] datatype.\r\n\r\nRemoving either of these things causes the program to work again under GHCi.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Tamar ChristinaTamar Christinahttps://gitlab.haskell.org/ghc/ghc/-/issues/12525Internal identifiers creeping into :show bindings2019-07-07T18:26:14ZmniipInternal identifiers creeping into :show bindingsWhen binding variables the "new" way, or defining typeclasses, some things that are better left unseen manage to creep into the `:show Bindings` list.
```html
<pre class="wiki">
GHCi, version 8.1.20160725: http://www.haskell.org/ghc/ :...When binding variables the "new" way, or defining typeclasses, some things that are better left unseen manage to creep into the `:show Bindings` list.
```html
<pre class="wiki">
GHCi, version 8.1.20160725: http://www.haskell.org/ghc/ :? for help
> :show bindings
> x = ()
> :show bindings
<b>$trModule :: GHC.Types.Module = _</b>
x :: () = _
> class Foo a
> :show bindings
x :: () = _
class Foo a
<b>$tcFoo :: GHC.Types.TyCon = _
$tc'C:Foo :: GHC.Types.TyCon = _
$trModule :: GHC.Types.Module = _</b>
</pre>
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Internal identifiers creeping into :show bindings","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When binding variables the \"new\" way, or defining typeclasses, some things that are better left unseen manage to creep into the `:show Bindings` list.\r\n\r\n{{{#!html\r\n<pre class=\"wiki\">\r\nGHCi, version 8.1.20160725: http://www.haskell.org/ghc/ :? for help\r\n> :show bindings\r\n> x = ()\r\n> :show bindings\r\n<b>$trModule :: GHC.Types.Module = _</b>\r\nx :: () = _\r\n> class Foo a\r\n> :show bindings\r\nx :: () = _\r\nclass Foo a\r\n<b>$tcFoo :: GHC.Types.TyCon = _\r\n$tc'C:Foo :: GHC.Types.TyCon = _\r\n$trModule :: GHC.Types.Module = _</b>\r\n</pre>\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Roland SennRoland Sennhttps://gitlab.haskell.org/ghc/ghc/-/issues/11647GHCi does not honour implicit `module Main (main) where` for re-exported `main`s2019-11-03T20:24:49ZHerbert Valerio Riedelhvr@gnu.orgGHCi does not honour implicit `module Main (main) where` for re-exported `main`sHaskell2010 states:
> An abbreviated form of module, consisting only of the module body, is permitted. If this is used, the header is assumed to be `module Main(main) where`.
Consider the following two modules:
```hs
-- module Main (m...Haskell2010 states:
> An abbreviated form of module, consisting only of the module body, is permitted. If this is used, the header is assumed to be `module Main(main) where`.
Consider the following two modules:
```hs
-- module Main (main) where
import Main2 (main)
```
```hs
module Main2 (main) where
main :: IO ()
main = return ()
```
A non-interactive GHC happily compiles `ghc --make Main`, however, GHCi fails with
```
$ ghci Main.hs
GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help
unknown option: 'c'
[1 of 2] Compiling Main2 ( Main2.hs, interpreted )
[2 of 2] Compiling Main ( Main.hs, interpreted )
Main.hs:1:1: The IO action ‘main’ is not exported by module ‘Main’
Failed, modules loaded: Main2.
```
For GHCi we need to uncomment the explicit `module Main (main) where` line to make it work.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHCi does not honour implicit `module Main (main) where` for re-exported `main`s","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Haskell2010 states:\r\n\r\n> An abbreviated form of module, consisting only of the module body, is permitted. If this is used, the header is assumed to be `module Main(main) where`.\r\n\r\n\r\nConsider the following two modules:\r\n\r\n{{{#!hs\r\n-- module Main (main) where\r\nimport Main2 (main)\r\n}}}\r\n\r\n{{{#!hs\r\nmodule Main2 (main) where\r\nmain :: IO ()\r\nmain = return ()\r\n}}}\r\n\r\nA non-interactive GHC happily compiles `ghc --make Main`, however, GHCi fails with\r\n\r\n{{{\r\n$ ghci Main.hs\r\nGHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help\r\nunknown option: 'c'\r\n[1 of 2] Compiling Main2 ( Main2.hs, interpreted )\r\n[2 of 2] Compiling Main ( Main.hs, interpreted )\r\n\r\nMain.hs:1:1: The IO action ‘main’ is not exported by module ‘Main’\r\nFailed, modules loaded: Main2.\r\n}}}\r\n\r\nFor GHCi we need to uncomment the explicit `module Main (main) where` line to make it work.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Roland SennRoland Sennhttps://gitlab.haskell.org/ghc/ghc/-/issues/11606name shadowing warnings don't trigger on standalone declarations in ghci2019-07-07T18:29:38Zrwbartonname shadowing warnings don't trigger on standalone declarations in ghciThe name shadowing warnings in ghci catch shadowing from top-level binds and `let` statements, but not from standalone declarations (new in 8.0).
```
rwbarton@morphism:/tmp$ ~/ghc-HEAD/bin/ghci -fwarn-name-shadowing
GHCi, version 8.1.20...The name shadowing warnings in ghci catch shadowing from top-level binds and `let` statements, but not from standalone declarations (new in 8.0).
```
rwbarton@morphism:/tmp$ ~/ghc-HEAD/bin/ghci -fwarn-name-shadowing
GHCi, version 8.1.20160212: http://www.haskell.org/ghc/ :? for help
Prelude> a <- return ()
Prelude> a <- return ()
<interactive>:2:1: warning:
This binding for ‘a’ shadows the existing binding
defined at <interactive>:1:1
Prelude> let b = return ()
Prelude> let b = return ()
<interactive>:4:5: warning:
This binding for ‘b’ shadows the existing binding
defined at <interactive>:3:5
Prelude> c = return ()
Prelude> c = return ()
Prelude>
```
I'm hoping this can be fixed for 8.0, since I would also very much like to turn on name shadowing warnings in ghci by default (in the interactive flags), to reduce confusion from examples like the below, which is now possible for the first time in 8.0:
```
Prelude> fact 0 = 1
Prelude> fact n = n * fact (n-1)
Prelude> fact 5
^C^CInterrupted.
Prelude> -- why did it run forever?
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"name shadowing warnings don't trigger on standalone declarations in ghci","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"8.0.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The name shadowing warnings in ghci catch shadowing from top-level binds and `let` statements, but not from standalone declarations (new in 8.0).\r\n{{{\r\nrwbarton@morphism:/tmp$ ~/ghc-HEAD/bin/ghci -fwarn-name-shadowing\r\nGHCi, version 8.1.20160212: http://www.haskell.org/ghc/ :? for help\r\nPrelude> a <- return ()\r\nPrelude> a <- return ()\r\n\r\n<interactive>:2:1: warning:\r\n This binding for ‘a’ shadows the existing binding\r\n defined at <interactive>:1:1\r\nPrelude> let b = return ()\r\nPrelude> let b = return ()\r\n\r\n<interactive>:4:5: warning:\r\n This binding for ‘b’ shadows the existing binding\r\n defined at <interactive>:3:5\r\nPrelude> c = return ()\r\nPrelude> c = return ()\r\nPrelude>\r\n}}}\r\n\r\nI'm hoping this can be fixed for 8.0, since I would also very much like to turn on name shadowing warnings in ghci by default (in the interactive flags), to reduce confusion from examples like the below, which is now possible for the first time in 8.0:\r\n{{{\r\nPrelude> fact 0 = 1\r\nPrelude> fact n = n * fact (n-1)\r\nPrelude> fact 5\r\n^C^CInterrupted.\r\nPrelude> -- why did it run forever?\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1rwbartonrwbartonhttps://gitlab.haskell.org/ghc/ghc/-/issues/10857"ghci -XMonomorphismRestriction" doesn't turn on the monomorphism restriction2019-07-07T18:33:28Zrwbarton"ghci -XMonomorphismRestriction" doesn't turn on the monomorphism restrictionCompare
```
rwbarton@morphism:/tmp$ ghci-7.10.1 -XMonomorphismRestriction
GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help
Prelude> let a = (+)
Prelude> :t a
a :: Num a => a -> a -> a
```
with
```
rwbarton@morphism:/tmp$...Compare
```
rwbarton@morphism:/tmp$ ghci-7.10.1 -XMonomorphismRestriction
GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help
Prelude> let a = (+)
Prelude> :t a
a :: Num a => a -> a -> a
```
with
```
rwbarton@morphism:/tmp$ ghci-7.10.1
GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help
Prelude> :set -XMonomorphismRestriction
Prelude> let a = (+)
Prelude> :t a
a :: Integer -> Integer -> Integer
```
Confusing!
This also occurred in 7.8.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.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 -XMonomorphismRestriction\" doesn't turn on the monomorphism restriction","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1","keywords":["newcomer"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Compare\r\n{{{\r\nrwbarton@morphism:/tmp$ ghci-7.10.1 -XMonomorphismRestriction\r\nGHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help\r\nPrelude> let a = (+)\r\nPrelude> :t a\r\na :: Num a => a -> a -> a\r\n}}}\r\nwith\r\n{{{\r\nrwbarton@morphism:/tmp$ ghci-7.10.1 \r\nGHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help\r\nPrelude> :set -XMonomorphismRestriction\r\nPrelude> let a = (+)\r\nPrelude> :t a\r\na :: Integer -> Integer -> Integer\r\n}}}\r\nConfusing!\r\n\r\nThis also occurred in 7.8.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Roland SennRoland Senn