GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T19:18:15Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/377can't build ghc with package depending on lang installed2019-07-07T19:18:15ZJens Petersencan't build ghc with package depending on lang installed```
When I try to build jhc with ghc and have wxhaskell
installed,
the build fails because although lang-1.0 is hidden somehow
it is exposed (by --make??) by being a dependency of the
wxcore package.
If I uninstall wxhaskell then there ...```
When I try to build jhc with ghc and have wxhaskell
installed,
the build fails because although lang-1.0 is hidden somehow
it is exposed (by --make??) by being a dependency of the
wxcore package.
If I uninstall wxhaskell then there is no problem...
however
it is annoying having to uninstall and re-install pkgs
just to build
something. The same problem occurs with hs-plugins
installed
(instead of wxhaskell) iirc.
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 6.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"can't build jhc with package depending on lang installed","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"6.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nWhen I try to build jhc with ghc and have wxhaskell\ninstalled,\nthe build fails because although lang-1.0 is hidden somehow\nit is exposed (by --make??) by being a dependency of the\nwxcore package.\n\nIf I uninstall wxhaskell then there is no problem...\nhowever\nit is annoying having to uninstall and re-install pkgs\njust to build\nsomething. The same problem occurs with hs-plugins\ninstalled\n(instead of wxhaskell) iirc.\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/378make depend of ghc-6.5 segfaults on x86-642023-07-25T16:17:17ZJens Petersenmake depend of ghc-6.5 segfaults on x86-64```
Building current anoncvs HEAD with ghc-6.4 gives a segfault
during make depend on x86_64:
../../glafp-utils/mkdependC/mkdependC -f .depend
-IControl -IControl/Concurrent -IControl/Parallel
-IControl/Monad -IControl/Monad/ST -IData
-...```
Building current anoncvs HEAD with ghc-6.4 gives a segfault
during make depend on x86_64:
../../glafp-utils/mkdependC/mkdependC -f .depend
-IControl -IControl/Concurrent -IControl/Parallel
-IControl/Monad -IControl/Monad/ST -IData
-IData/Generics -IData/Array -IData/Array/IO
-IData/STRef -IDebug -IForeign -IForeign/C
-IForeign/Marshal -IGHC -ISystem -ISystem/Console
-ISystem/Mem -ISystem/IO -ISystem/Posix
-ISystem/Process -ISystem/Directory -IText -IText/Html
-IText/PrettyPrint -IText/ParserCombinators
-IText/Regex -IText/Show -IText/Read
-I../../ghc/includes -s p -- -O --
System/CPUTime_hsc.c System/Time_hsc.c
Text/Regex/Posix_hsc.c
../../ghc/compiler/ghc-inplace -M -optdep-f
-optdep.depend -optdep-s -optdepp -osuf o -H16m -O
-fglasgow-exts -cpp -Iinclude -"#include" HsBase.h
-funbox-strict-fields -ignore-package base -O
-Rghc-timing -fgenerics -fgenerics Control/Arrow.hs
Control/Concurrent.hs Control/Concurrent/Chan.hs
Control/Concurrent/MVar.hs Control/Concurrent/QSem.hs
Control/Concurrent/QSemN.hs
Control/Concurrent/SampleVar.hs Control/Exception.hs
Control/Monad.hs Control/Monad/Fix.hs
Control/Monad/ST.hs Control/Monad/ST/Lazy.hs
Control/Monad/ST/Strict.hs Control/Parallel.hs
Control/Parallel/Strategies.hs Data/Array.hs
Data/Array/Base.hs Data/Array/Diff.hs
Data/Array/IArray.hs Data/Array/IO.hs
Data/Array/IO/Internals.hs Data/Array/MArray.hs
Data/Array/ST.hs Data/Array/Storable.hs
Data/Array/Unboxed.hs Data/Bits.hs Data/Bool.hs
Data/Char.hs Data/Complex.hs Data/Dynamic.hs
Data/Either.hs Data/Eq.hs Data/FiniteMap.hs
Data/FunctorM.hs Data/Generics.hs
Data/Generics/Aliases.hs Data/Generics/Basics.hs
Data/Generics/Instances.hs Data/Generics/Schemes.hs
Data/Generics/Text.hs Data/Generics/Twins.hs
Data/Graph.hs Data/HashTable.hs Data/IORef.hs
Data/Int.hs Data/IntMap.hs Data/IntSet.hs Data/Ix.hs
Data/List.hs Data/Map.hs Data/Maybe.hs Data/Monoid.hs
Data/Ord.hs Data/PackedString.hs Data/Queue.hs
Data/Ratio.hs Data/STRef.hs Data/STRef/Lazy.hs
Data/STRef/Strict.hs Data/Set.hs Data/Tree.hs
Data/Tuple.hs Data/Typeable.hs Data/Unique.hs
Data/Version.hs Data/Word.hs Debug/Trace.hs Foreign.hs
Foreign/C.hs Foreign/C/Error.hs Foreign/C/String.hs
Foreign/C/Types.hs Foreign/Concurrent.hs
Foreign/ForeignPtr.hs Foreign/Marshal.hs
Foreign/Marshal/Alloc.hs Foreign/Marshal/Array.hs
Foreign/Marshal/Error.hs Foreign/Marshal/Pool.hs
Foreign/Marshal/Utils.hs Foreign/Ptr.hs
Foreign/StablePtr.hs Foreign/Storable.hs GHC/Arr.lhs
GHC/Base.lhs GHC/Conc.lhs GHC/ConsoleHandler.hs
GHC/Dotnet.hs GHC/Enum.lhs GHC/Err.lhs
GHC/Exception.lhs GHC/Exts.hs GHC/Float.lhs
GHC/ForeignPtr.hs GHC/Handle.hs GHC/IO.hs
GHC/IOBase.lhs GHC/Int.hs GHC/List.lhs GHC/Num.lhs
GHC/PArr.hs GHC/Pack.lhs GHC/PrimopWrappers.hs
GHC/Ptr.lhs GHC/Read.lhs GHC/Real.lhs GHC/ST.lhs
GHC/STRef.lhs GHC/Show.lhs GHC/Stable.lhs
GHC/Storable.lhs GHC/TopHandler.lhs GHC/Unicode.hs
GHC/Weak.lhs GHC/Word.hs Numeric.hs Prelude.hs
System/CPUTime.hs System/Cmd.hs
System/Console/GetOpt.hs System/Directory.hs
System/Directory/Internals.hs System/Environment.hs
System/Exit.hs System/IO.hs System/IO/Error.hs
System/IO/Unsafe.hs System/Info.hs System/Locale.hs
System/Mem.hs System/Mem/StableName.hs
System/Mem/Weak.hs System/Posix/Internals.hs
System/Posix/Signals.hs System/Posix/Types.hs
System/Process.hs System/Process/Internals.hs
System/Random.hs System/Time.hs Text/Html.hs
Text/Html/BlockTable.hs Text/ParserCombinators/ReadP.hs
Text/ParserCombinators/ReadPrec.hs Text/PrettyPrint.hs
Text/PrettyPrint/HughesPJ.hs Text/Printf.hs
Text/Read.hs Text/Read/Lex.hs Text/Regex.hs
Text/Regex/Posix.hs Text/Show.hs Text/Show/Functions.hs
<<ghc: 169931752 bytes, make[2]: *** [depend]
Segmentation fault
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 6.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"make depend of ghc-6.5 segfaults on x86-64","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"simonmar"},"version":"6.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nBuilding current anoncvs HEAD with ghc-6.4 gives a segfault\nduring make depend on x86_64:\n\n../../glafp-utils/mkdependC/mkdependC -f .depend\n-IControl -IControl/Concurrent -IControl/Parallel\n-IControl/Monad -IControl/Monad/ST -IData\n-IData/Generics -IData/Array -IData/Array/IO\n-IData/STRef -IDebug -IForeign -IForeign/C\n-IForeign/Marshal -IGHC -ISystem -ISystem/Console\n-ISystem/Mem -ISystem/IO -ISystem/Posix\n-ISystem/Process -ISystem/Directory -IText -IText/Html\n-IText/PrettyPrint -IText/ParserCombinators\n-IText/Regex -IText/Show -IText/Read\n-I../../ghc/includes -s p -- -O --\nSystem/CPUTime_hsc.c System/Time_hsc.c\nText/Regex/Posix_hsc.c \n../../ghc/compiler/ghc-inplace -M -optdep-f\n-optdep.depend -optdep-s -optdepp -osuf o -H16m -O\n-fglasgow-exts -cpp -Iinclude -\"#include\" HsBase.h\n-funbox-strict-fields -ignore-package base -O\n-Rghc-timing -fgenerics -fgenerics Control/Arrow.hs\nControl/Concurrent.hs Control/Concurrent/Chan.hs\nControl/Concurrent/MVar.hs Control/Concurrent/QSem.hs\nControl/Concurrent/QSemN.hs\nControl/Concurrent/SampleVar.hs Control/Exception.hs\nControl/Monad.hs Control/Monad/Fix.hs\nControl/Monad/ST.hs Control/Monad/ST/Lazy.hs\nControl/Monad/ST/Strict.hs Control/Parallel.hs\nControl/Parallel/Strategies.hs Data/Array.hs\nData/Array/Base.hs Data/Array/Diff.hs\nData/Array/IArray.hs Data/Array/IO.hs\nData/Array/IO/Internals.hs Data/Array/MArray.hs\nData/Array/ST.hs Data/Array/Storable.hs\nData/Array/Unboxed.hs Data/Bits.hs Data/Bool.hs\nData/Char.hs Data/Complex.hs Data/Dynamic.hs\nData/Either.hs Data/Eq.hs Data/FiniteMap.hs\nData/FunctorM.hs Data/Generics.hs\nData/Generics/Aliases.hs Data/Generics/Basics.hs\nData/Generics/Instances.hs Data/Generics/Schemes.hs\nData/Generics/Text.hs Data/Generics/Twins.hs\nData/Graph.hs Data/HashTable.hs Data/IORef.hs\nData/Int.hs Data/IntMap.hs Data/IntSet.hs Data/Ix.hs\nData/List.hs Data/Map.hs Data/Maybe.hs Data/Monoid.hs\nData/Ord.hs Data/PackedString.hs Data/Queue.hs\nData/Ratio.hs Data/STRef.hs Data/STRef/Lazy.hs\nData/STRef/Strict.hs Data/Set.hs Data/Tree.hs\nData/Tuple.hs Data/Typeable.hs Data/Unique.hs\nData/Version.hs Data/Word.hs Debug/Trace.hs Foreign.hs\nForeign/C.hs Foreign/C/Error.hs Foreign/C/String.hs\nForeign/C/Types.hs Foreign/Concurrent.hs\nForeign/ForeignPtr.hs Foreign/Marshal.hs\nForeign/Marshal/Alloc.hs Foreign/Marshal/Array.hs\nForeign/Marshal/Error.hs Foreign/Marshal/Pool.hs\nForeign/Marshal/Utils.hs Foreign/Ptr.hs\nForeign/StablePtr.hs Foreign/Storable.hs GHC/Arr.lhs\nGHC/Base.lhs GHC/Conc.lhs GHC/ConsoleHandler.hs\nGHC/Dotnet.hs GHC/Enum.lhs GHC/Err.lhs\nGHC/Exception.lhs GHC/Exts.hs GHC/Float.lhs\nGHC/ForeignPtr.hs GHC/Handle.hs GHC/IO.hs\nGHC/IOBase.lhs GHC/Int.hs GHC/List.lhs GHC/Num.lhs\nGHC/PArr.hs GHC/Pack.lhs GHC/PrimopWrappers.hs\nGHC/Ptr.lhs GHC/Read.lhs GHC/Real.lhs GHC/ST.lhs\nGHC/STRef.lhs GHC/Show.lhs GHC/Stable.lhs\nGHC/Storable.lhs GHC/TopHandler.lhs GHC/Unicode.hs\nGHC/Weak.lhs GHC/Word.hs Numeric.hs Prelude.hs\nSystem/CPUTime.hs System/Cmd.hs\nSystem/Console/GetOpt.hs System/Directory.hs\nSystem/Directory/Internals.hs System/Environment.hs\nSystem/Exit.hs System/IO.hs System/IO/Error.hs\nSystem/IO/Unsafe.hs System/Info.hs System/Locale.hs\nSystem/Mem.hs System/Mem/StableName.hs\nSystem/Mem/Weak.hs System/Posix/Internals.hs\nSystem/Posix/Signals.hs System/Posix/Types.hs\nSystem/Process.hs System/Process/Internals.hs\nSystem/Random.hs System/Time.hs Text/Html.hs\nText/Html/BlockTable.hs Text/ParserCombinators/ReadP.hs\nText/ParserCombinators/ReadPrec.hs Text/PrettyPrint.hs\nText/PrettyPrint/HughesPJ.hs Text/Printf.hs\nText/Read.hs Text/Read/Lex.hs Text/Regex.hs\nText/Regex/Posix.hs Text/Show.hs Text/Show/Functions.hs\n<<ghc: 169931752 bytes, make[2]: *** [depend]\nSegmentation fault\n\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/379internal error: scavenge_one: strange object 68, amd642019-07-07T19:18:14Znobodyinternal error: scavenge_one: strange object 68, amd64```
With
ghc-6.4.20050506-src.tar.bz2 or ghc 6.4
Fedora Core 3 (current updates) (gcc 3.4.3 glibc 2.3.5)
amd64
Existing ghc 6.4 in /usr/bin from Fedora Haskell
Project rpm.
pugs r2943
I built ghc-6.4.20050506-src by doing:
...```
With
ghc-6.4.20050506-src.tar.bz2 or ghc 6.4
Fedora Core 3 (current updates) (gcc 3.4.3 glibc 2.3.5)
amd64
Existing ghc 6.4 in /usr/bin from Fedora Haskell
Project rpm.
pugs r2943
I built ghc-6.4.20050506-src by doing:
./configure
make
make
make install
But ghc-6.4 behaves similarly.
You can build pugs by doing:
svn co http://svn.openfoundry.org/pugs/ -r 2943
cd pugs
perl Makefile.PL
make unoptimized
To generate error,
./pugs
Error:
[...]
Welcome to Pugs -- Perl6 User's Golfing System
Type :h for help
pugs: internal error: scavenge_one: strange object 68
Please report this as a bug to
glasgow-haskell-bugs@haskell.org,
or http://www.sourceforge.net/projects/ghc/
Notes:
Using /usr/bin/ghc (ghc-6.4) yields a similar error.
./pugs +RTS -A200M -RTS delays the error.
Mitchell Charity
mncI02eyA zap vendian zot org
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | None |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | None |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"internal error: scavenge_one: strange object 68, amd64","status":"New","operating_system":"","component":"None","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"None","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nWith\n ghc-6.4.20050506-src.tar.bz2 or ghc 6.4\n Fedora Core 3 (current updates) (gcc 3.4.3 glibc 2.3.5)\n amd64\n Existing ghc 6.4 in /usr/bin from Fedora Haskell\nProject rpm.\n pugs r2943\n\nI built ghc-6.4.20050506-src by doing:\n ./configure\n make\n make\n make install\n\nBut ghc-6.4 behaves similarly.\n\nYou can build pugs by doing:\n svn co http://svn.openfoundry.org/pugs/ -r 2943\n cd pugs\n perl Makefile.PL\n make unoptimized\n\nTo generate error,\n ./pugs\n\nError:\n [...]\n Welcome to Pugs -- Perl6 User's Golfing System\n Type :h for help\n \n pugs: internal error: scavenge_one: strange object 68\n Please report this as a bug to\nglasgow-haskell-bugs@haskell.org,\n or http://www.sourceforge.net/projects/ghc/\n\nNotes:\n Using /usr/bin/ghc (ghc-6.4) yields a similar error.\n ./pugs +RTS -A200M -RTS delays the error.\n\nMitchell Charity\nmncI02eyA zap vendian zot org\n\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/380ghc --make panic on fptools/ghc/compiler/Lexer.hs2019-07-07T19:18:14Znobodyghc --make panic on fptools/ghc/compiler/Lexer.hs```
I am trying to use ghc's lexer in my own project. When
building module that imports Lexer module I am getting
this error:
ghc-6.4: panic! (the `impossible' happened, GHC version
6.4):
expectJust upsweep_mod:old_linkable
My...```
I am trying to use ghc's lexer in my own project. When
building module that imports Lexer module I am getting
this error:
ghc-6.4: panic! (the `impossible' happened, GHC version
6.4):
expectJust upsweep_mod:old_linkable
My reproduction project(attached) consists of two files:
Main.hs
========>
module Main where
import Lexer
main = putStrLn "hello"
<=========
and Makefile.
You may have to edit Makefile to provide the correct
path to the fptools folder. Running make demonstrates
the error.
I am using ghc-6.4 on gentoo.
Thank you,
Pavel [pavelzolnikov at yahoo dot com]
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 6.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghc --make panic on fptools/ghc/compiler/Lexer.hs","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"6.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nI am trying to use ghc's lexer in my own project. When\nbuilding module that imports Lexer module I am getting\nthis error:\n\nghc-6.4: panic! (the `impossible' happened, GHC version\n6.4):\n expectJust upsweep_mod:old_linkable\n\n\nMy reproduction project(attached) consists of two files:\n\nMain.hs\n========>\nmodule Main where\n\n\n\nimport Lexer\n\n\n\nmain = putStrLn \"hello\"\n<=========\nand Makefile.\n\nYou may have to edit Makefile to provide the correct\npath to the fptools folder. Running make demonstrates\nthe error.\n\nI am using ghc-6.4 on gentoo.\n\nThank you,\nPavel [pavelzolnikov at yahoo dot com]\n\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/381System.Posix.Signals.setStoppedChildFlag segfaults2019-07-07T19:18:13ZnobodySystem.Posix.Signals.setStoppedChildFlag segfaults```
On GHC6.4 System.Posix.Signals.setStoppedChildFlag causes the
program to segfault (x86/Debian). The following simple program
triggers it:
import System.Posix.Signals
main = setStoppedChildFlag True
```
<details><summary>Trac me...```
On GHC6.4 System.Posix.Signals.setStoppedChildFlag causes the
program to segfault (x86/Debian). The following simple program
triggers it:
import System.Posix.Signals
main = setStoppedChildFlag True
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 6.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | hslibs/posix |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"System.Posix.Signals.setStoppedChildFlag segfaults","status":"New","operating_system":"","component":"hslibs/posix","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"6.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nOn GHC6.4 System.Posix.Signals.setStoppedChildFlag causes the \nprogram to segfault (x86/Debian). The following simple program \ntriggers it:\n\nimport System.Posix.Signals\nmain = setStoppedChildFlag True\n\n\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/382GHC fails to pass dictionary in a rank-2 situation.2019-07-07T19:18:13ZnobodyGHC fails to pass dictionary in a rank-2 situation.```
Hello,
The following code leads to a run- or compile-time error.
\begin{code}
{-# OPTIONS -fglasgow-exts #-}
module Main () where
foo :: (forall m. Monad m => m a) -> IO a
foo = id . id
main :: IO ()
main = foo (return ())
\end{co...```
Hello,
The following code leads to a run- or compile-time error.
\begin{code}
{-# OPTIONS -fglasgow-exts #-}
module Main () where
foo :: (forall m. Monad m => m a) -> IO a
foo = id . id
main :: IO ()
main = foo (return ())
\end{code}
GHC translates `foo' effectively to an identity
function, failing to pass a dictionary to the argument.
foo :: %forall a . (%forall (m::(*->*)) . ZCTMonad m ->
m a)
-> IO a =
\ @ a ->
zi @ (IO a) @ (IO a)
@ (IO a) (id @ (IO a))
(id @ (IO a));
This doesn't typecheck, therefore
$ ./ghc-6.5.20050510 -O IsolateBug.hs
ghc-6.5.20050510: panic! (the `impossible' happened,
GHC version 6.5.20050510):
No match in record selector Var.idInfo
Please report it as a compiler bug to
glasgow-haskell-bugs@haskell.org,
or http://sourceforge.net/projects/ghc/.
$ ghc-6.5.20050510 IsolateBug.hs
$ ./a.out
zsh: segmentation fault ./a.out
The bug still occurs when we give the compiler a little
bit more type information
> foo = (id :: IO a -> IO a) . (id :: IO a -> IO a)
, however
> foo = id . id :: IO a -> IO a
and
> foo = id
behave correctly.
Tested with ghc-6.2.2, ghc-6.4 and the latest ghc-6.5
snapshot.
-- Thomas Jäger <ThJaeger@gmail.com>
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | None |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC fails to pass dictionary in a rank-2 situation.","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"None","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nHello,\n\nThe following code leads to a run- or compile-time error.\n\\begin{code}\n{-# OPTIONS -fglasgow-exts #-}\nmodule Main () where\n\nfoo :: (forall m. Monad m => m a) -> IO a\nfoo = id . id\n\nmain :: IO ()\nmain = foo (return ())\n\\end{code}\n\nGHC translates `foo' effectively to an identity\nfunction, failing to pass a dictionary to the argument.\n foo :: %forall a . (%forall (m::(*->*)) . ZCTMonad m ->\n m a)\n -> IO a =\n \\ @ a ->\n zi @ (IO a) @ (IO a)\n @ (IO a) (id @ (IO a))\n (id @ (IO a));\n\nThis doesn't typecheck, therefore \n\n$ ./ghc-6.5.20050510 -O IsolateBug.hs \nghc-6.5.20050510: panic! (the `impossible' happened,\nGHC version 6.5.20050510):\n No match in record selector Var.idInfo\n\nPlease report it as a compiler bug to\nglasgow-haskell-bugs@haskell.org,\nor http://sourceforge.net/projects/ghc/.\n\n$ ghc-6.5.20050510 IsolateBug.hs \n$ ./a.out \nzsh: segmentation fault ./a.out\n\n\nThe bug still occurs when we give the compiler a little\nbit more type information\n> foo = (id :: IO a -> IO a) . (id :: IO a -> IO a)\n, however\n> foo = id . id :: IO a -> IO a\nand\n> foo = id\nbehave correctly.\n\nTested with ghc-6.2.2, ghc-6.4 and the latest ghc-6.5\nsnapshot.\n\n-- Thomas Jäger <ThJaeger@gmail.com>\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/383Default methods not in scope for spliced-in instances?2019-07-07T19:18:13ZsbronsonDefault methods not in scope for spliced-in instances?```
This is a literate haskell bugreport. Save it to
DefaultMethodScopeTH.lhs.
I noticed a problem with instantiating a typeclasse
from Template
Haskell in the same module that defined it. I've bumped
into this
twice close together now,...```
This is a literate haskell bugreport. Save it to
DefaultMethodScopeTH.lhs.
I noticed a problem with instantiating a typeclasse
from Template
Haskell in the same module that defined it. I've bumped
into this
twice close together now, so I figure I really ought to
report it now.
> {-# OPTIONS_GHC -fth #-}
>
> module DefaultMethodScopeTH where
First, define a typeclass with a default method.
This is probably not a very usefull class, but nobody
wants me to drag
half of the module I'm actually working on into this ;-).
> class Foo a where
> foo :: a -> a
> foo = id
Now try to instantiate it from TH with the default method.
> $([d| instance Foo () where |])
Nothing particularly complicated, right?
But when I try to actually build it, I get this:
$ ghc --make DefaultMethodScopeTH.lhs
Chasing modules from: DefaultMethodScopeTH.lhs
Compiling DefaultMethodScopeTH (
DefaultMethodScopeTH.lhs, DefaultMethodScopeTH.o )
DefaultMethodScopeTH.lhs:22:7:
GHC internal error: `DefaultMethodScopeTH.$dmfoo'
is not in scope
In the definition of `foo': foo =
DefaultMethodScopeTH.$dmfoo
In the definition for method `foo'
In the instance declaration for `Foo ()'
Kind of nasty, eh?
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 6.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | Template Haskell |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Default methods not in scope for spliced-in instances?","status":"New","operating_system":"","component":"Template Haskell","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"simonpj"},"version":"6.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nThis is a literate haskell bugreport. Save it to\nDefaultMethodScopeTH.lhs.\n\nI noticed a problem with instantiating a typeclasse\nfrom Template\nHaskell in the same module that defined it. I've bumped\ninto this\ntwice close together now, so I figure I really ought to\nreport it now.\n\n> {-# OPTIONS_GHC -fth #-}\n> \n> module DefaultMethodScopeTH where\n\nFirst, define a typeclass with a default method.\n\nThis is probably not a very usefull class, but nobody\nwants me to drag\nhalf of the module I'm actually working on into this ;-).\n\n> class Foo a where\n> foo :: a -> a\n> foo = id\n\nNow try to instantiate it from TH with the default method.\n\n> $([d| instance Foo () where |])\n\nNothing particularly complicated, right?\n\nBut when I try to actually build it, I get this:\n\n$ ghc --make DefaultMethodScopeTH.lhs\nChasing modules from: DefaultMethodScopeTH.lhs\nCompiling DefaultMethodScopeTH (\nDefaultMethodScopeTH.lhs, DefaultMethodScopeTH.o )\n\nDefaultMethodScopeTH.lhs:22:7:\n GHC internal error: `DefaultMethodScopeTH.$dmfoo'\nis not in scope\n In the definition of `foo': foo =\nDefaultMethodScopeTH.$dmfoo\n In the definition for method `foo'\n In the instance declaration for `Foo ()'\n\nKind of nasty, eh?\n\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/384internal compiler error: the `impossible' happened2019-07-07T19:18:13Zasamoilovinternal compiler error: the `impossible' happened```
Dear Haskellers,
I've got the following error message during
compilation of the attached Signal.hs file with ghc 6.4
and 6.5.
ghc -c Signal.hs
ghc-6.4: panic! (the `impossible' happened, GHC version
6.4):
types/Type.lhs:(11...```
Dear Haskellers,
I've got the following error message during
compilation of the attached Signal.hs file with ghc 6.4
and 6.5.
ghc -c Signal.hs
ghc-6.4: panic! (the `impossible' happened, GHC version
6.4):
types/Type.lhs:(1107,0)-(1108,77):
Non-exhaustive patterns in function zip_ty_env
Please report it as a compiler bug to
glasgow-haskell-bugs@haskell.org,
or http://sourceforge.net/projects/ghc/.
I spent some time stripping the file to only several
lines :)
Best regards
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"internal compiler error: the `impossible' happened","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"6.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nDear Haskellers,\n\nI've got the following error message during\ncompilation of the attached Signal.hs file with ghc 6.4\nand 6.5.\n\nghc -c Signal.hs\nghc-6.4: panic! (the `impossible' happened, GHC version\n6.4):\n types/Type.lhs:(1107,0)-(1108,77):\nNon-exhaustive patterns in function zip_ty_env\n \n \nPlease report it as a compiler bug to\nglasgow-haskell-bugs@haskell.org,\nor http://sourceforge.net/projects/ghc/.\n\nI spent some time stripping the file to only several\nlines :)\n\nBest regards\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/385Kind error has wrong line2019-07-07T19:18:13ZnobodyKind error has wrong line```
With the attached test file (t.hs) I get the following
result:
--------------------------
cptchaos@motion2 ~ $ ghci-6.4 -fglasgow-exts t.hs
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, versi...```
With the attached test file (t.hs) I get the following
result:
--------------------------
cptchaos@motion2 ~ $ ghci-6.4 -fglasgow-exts t.hs
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version
6.4, for Haskell 98.
/ /_\\/ __ / /___| | http://www.haskell.org/ghc/
\____/\/ /_/\____/|_| Type :? for help.
Loading package base-1.0 ... linking ... done.
Compiling Main ( t.hs, interpreted )
t.hs:4:0:
Couldn't match kind `* -> *' against `*'
In the class declaration for `IOMatrixIf'
Failed, modules loaded: none.
Prelude>
------------------------------
but line 4 is correct (it is in fact an example from
the userguide)
-------------------------------------- example file: t.hs
module Main where
class IOMatrixIf (iomat :: * -> *) b where
iomatrix_new :: Int -> Int -> IO (iomat b)
-- ^ creates a matrix with random values ( just mem.
allocation)
iomatrix_rows :: (iomat b) -> Int
iomatrix_cols :: (iomat b) -> Int
iomatrix_read_elem :: (iomat b) -> Int -> Int -> IO b
iomatrix_write_elem :: (iomat b) -> Int -> Int -> b
-> IO ()
hello = "foo" -- junk code may be some lines
-- here is the kind error
type IOMatrix matRep = IOMatrixIf matRep b => (IO matRep)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Kind error has wrong line","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"6.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\n\nWith the attached test file (t.hs) I get the following\nresult:\n--------------------------\n\ncptchaos@motion2 ~ $ ghci-6.4 -fglasgow-exts t.hs\n ___ ___ _\n / _ \\ /\\ /\\/ __(_)\n / /_\\// /_/ / / | | GHC Interactive, version\n6.4, for Haskell 98.\n/ /_\\\\/ __ / /___| | http://www.haskell.org/ghc/\n\\____/\\/ /_/\\____/|_| Type :? for help.\n\nLoading package base-1.0 ... linking ... done.\nCompiling Main ( t.hs, interpreted )\n\nt.hs:4:0:\n Couldn't match kind `* -> *' against `*'\n In the class declaration for `IOMatrixIf'\nFailed, modules loaded: none.\nPrelude>\n\n------------------------------\n\nbut line 4 is correct (it is in fact an example from\nthe userguide)\n\n-------------------------------------- example file: t.hs\nmodule Main where\n\nclass IOMatrixIf (iomat :: * -> *) b where\n iomatrix_new :: Int -> Int -> IO (iomat b)\n -- ^ creates a matrix with random values ( just mem.\nallocation)\n iomatrix_rows :: (iomat b) -> Int\n iomatrix_cols :: (iomat b) -> Int\n iomatrix_read_elem :: (iomat b) -> Int -> Int -> IO b\n iomatrix_write_elem :: (iomat b) -> Int -> Int -> b\n-> IO ()\n\n\nhello = \"foo\" -- junk code may be some lines\n\n\n-- here is the kind error \ntype IOMatrix matRep = IOMatrixIf matRep b => (IO matRep)\n\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/386:i wrongly claims "Imported from ..."2020-12-09T12:04:52Zpimlott:i wrongly claims "Imported from ..."```
Mostly cosmetic mix-up:
Prelude> :m GHC.Exception
Prelude GHC.Exception> :i System.IO.Error.catch
catch :: IO a -> (IOError -> IO a) -> IO a
-- Imported from GHC.Exception
The catch described is not the same on as imported ...```
Mostly cosmetic mix-up:
Prelude> :m GHC.Exception
Prelude GHC.Exception> :i System.IO.Error.catch
catch :: IO a -> (IOError -> IO a) -> IO a
-- Imported from GHC.Exception
The catch described is not the same on as imported from
GHC.Exception.
```nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/387Too many seq's (in external core)2021-02-06T14:26:56Zp1738jToo many seq's (in external core)```
With the attached input, the resulting core contains a
strange definition of compare_patches. It does 12 (or
so) "seq"'s on the two arguments
(where two would suffice).
```
<details><summary>Trac metadata</summary>
| Trac field ...```
With the attached input, the resulting core contains a
strange definition of compare_patches. It does 12 (or
so) "seq"'s on the two arguments
(where two would suffice).
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 6.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Too many seq's (in external core)","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"6.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nWith the attached input, the resulting core contains a\nstrange definition of compare_patches. It does 12 (or\nso) \"seq\"'s on the two arguments\n(where two would suffice).\n\n\n\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/388Incorrect "Defined but not used"2019-07-07T19:18:12ZnobodyIncorrect "Defined but not used"```
This is johndetr@microsoft.com.
When I compile the following function:
150 hexArg :: P Hex
151 hexArg = do MyState i n <- getState
152 let i = i + 1
153 setState (MyState i n)
154 x <- hexNumber
...```
This is johndetr@microsoft.com.
When I compile the following function:
150 hexArg :: P Hex
151 hexArg = do MyState i n <- getState
152 let i = i + 1
153 setState (MyState i n)
154 x <- hexNumber
155 if i < n then do { char ','; return () }
156 else do { char ')'; eof }
157 return x
I get the following messages:
Vesta.hs:151:20: Warning: Defined but not used: `i'
Vesta.hs:152:16:
Warning: This binding for `i' shadows an existing
binding
In the binding group for: i
The second is correct, if course, but the first is not.
If I change the new binding to i' instead of i (and the
references below, of course) *both* messages go away!
Please let me know if you'd like more information, a
shorter error case, etc.
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 6.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedRejected |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Incorrect \"Defined but not used\"","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"ResolvedRejected","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"6.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nThis is johndetr@microsoft.com.\n\nWhen I compile the following function:\n\n150 hexArg :: P Hex\n151 hexArg = do MyState i n <- getState\n152 let i = i + 1\n153 setState (MyState i n)\n154 x <- hexNumber\n155 if i < n then do { char ','; return () }\n156 else do { char ')'; eof }\n157 return x\n\nI get the following messages:\n\nVesta.hs:151:20: Warning: Defined but not used: `i'\n\nVesta.hs:152:16:\n Warning: This binding for `i' shadows an existing \nbinding\n In the binding group for: i\n\nThe second is correct, if course, but the first is not.\n\nIf I change the new binding to i' instead of i (and the \nreferences below, of course) *both* messages go away!\n\nPlease let me know if you'd like more information, a \nshorter error case, etc.\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/389System.Cmd.system fails on Win9x2019-07-07T19:18:12ZnobodySystem.Cmd.system fails on Win9x```
Vivian McPhail
vivian.mcphail@paradise.net.nz
From a ghci session (6.4):
Prelude> System.Cmd.system "dir"
*** Exception: C:\WINDOWS\SYSTEM\CMD.EXE: runCommand:
does not exist (No such file or directory)
System.Cmd.system tries to ...```
Vivian McPhail
vivian.mcphail@paradise.net.nz
From a ghci session (6.4):
Prelude> System.Cmd.system "dir"
*** Exception: C:\WINDOWS\SYSTEM\CMD.EXE: runCommand:
does not exist (No such file or directory)
System.Cmd.system tries to run cmd.exe but on Win9x
this is command.com.
These executables are both mentioned in the
documentation so the distinction is not unknown.
I see that the source code for System.Process.Internals
has code for detecting this, but for some reason it
does not appear to be working:
-- Find CMD.EXE (or COMMAND.COM on Win98). We use the
same algorithm as
-- system() in the VC++ CRT (Vc7/crt/src/system.c in a
VC++ installation).
findCommandInterpreter :: IO FilePath
findCommandInterpreter = do
-- try COMSPEC first
catchJust ioErrors (getEnv "COMSPEC") $ \e -> do
when (not (isDoesNotExistError e)) $ ioError e
-- try to find CMD.EXE or COMMAND.COM
osver <- c_get_osver
let filename | osver .&. 0x8000 /= 0 = "command.com"
| otherwise = "cmd.exe"
path <- getEnv "PATH"
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"System.Cmd.system fails on Win9x","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"6.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nVivian McPhail\nvivian.mcphail@paradise.net.nz\n\nFrom a ghci session (6.4):\n\nPrelude> System.Cmd.system \"dir\"\n*** Exception: C:\\WINDOWS\\SYSTEM\\CMD.EXE: runCommand:\ndoes not exist (No such file or directory)\n\nSystem.Cmd.system tries to run cmd.exe but on Win9x\nthis is command.com.\n\nThese executables are both mentioned in the\ndocumentation so the distinction is not unknown.\n\nI see that the source code for System.Process.Internals\nhas code for detecting this, but for some reason it\ndoes not appear to be working:\n\n-- Find CMD.EXE (or COMMAND.COM on Win98). We use the\nsame algorithm as\n-- system() in the VC++ CRT (Vc7/crt/src/system.c in a\nVC++ installation).\nfindCommandInterpreter :: IO FilePath\nfindCommandInterpreter = do\n -- try COMSPEC first\n catchJust ioErrors (getEnv \"COMSPEC\") $ \\e -> do\n when (not (isDoesNotExistError e)) $ ioError e\n\n -- try to find CMD.EXE or COMMAND.COM\n osver <- c_get_osver\n let filename | osver .&. 0x8000 /= 0 = \"command.com\"\n\t\t | otherwise = \"cmd.exe\"\n path <- getEnv \"PATH\"\n\n\n\n\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/390SHGetFolderPath link error2019-07-07T19:18:12ZnobodySHGetFolderPath link error```
Vivian McPhail
On Win9x with GHC 6.4.1
Attempting to compile Cabal
setup.exe is linked to missing export
SHELL32.DLL:SHGetFolderPathA
There is a dll named ShFolder.dll which can be
downloaded from microsoft to provide this functi...```
Vivian McPhail
On Win9x with GHC 6.4.1
Attempting to compile Cabal
setup.exe is linked to missing export
SHELL32.DLL:SHGetFolderPathA
There is a dll named ShFolder.dll which can be
downloaded from microsoft to provide this function. I
note that libshfolder.a is also to be found in
$GHC/gcc-lib directory.
I have (manually) added "ShFolder" to extraLibraries of
Cabal in package.conf, which fixed the problem when
running GHCi.
However, when running the Cabal package setup.exe the
above error (in a dialog box) occurs.
I ran ghc with -v to see the libraries linked against,
and they included -lshfolder.
I cannot figure out what is going wrong here. Does
shell32 say it exports the function and thus prevent
ShFolder from providing it?
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 6.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedNoReason |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"SHGetFolderPath link error","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"ResolvedNoReason","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"6.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nVivian McPhail\n\nOn Win9x with GHC 6.4.1\n\nAttempting to compile Cabal\n\nsetup.exe is linked to missing export\nSHELL32.DLL:SHGetFolderPathA\n\nThere is a dll named ShFolder.dll which can be\ndownloaded from microsoft to provide this function. I\nnote that libshfolder.a is also to be found in\n$GHC/gcc-lib directory.\n\nI have (manually) added \"ShFolder\" to extraLibraries of\nCabal in package.conf, which fixed the problem when\nrunning GHCi.\n\nHowever, when running the Cabal package setup.exe the\nabove error (in a dialog box) occurs.\n\nI ran ghc with -v to see the libraries linked against,\nand they included -lshfolder.\n\nI cannot figure out what is going wrong here. Does\nshell32 say it exports the function and thus prevent\nShFolder from providing it?\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/391unjustified deduction error2019-07-07T19:18:11Znobodyunjustified deduction error```
(also sent to glasgow-haskell-users) maeder@tzi.de
the following (reduced) example used to go through with
ghc-6.2.2 but fails with ghc-6.4.
This seems to be a - low priority - bug. (hugs accepts
this module.)
I compile with:
ghc...```
(also sent to glasgow-haskell-users) maeder@tzi.de
the following (reduced) example used to go through with
ghc-6.2.2 but fails with ghc-6.4.
This seems to be a - low priority - bug. (hugs accepts
this module.)
I compile with:
ghc -fglasgow-exts Context.hs
module Context where
class Language a
class Language a => Logic a b | a -> b
class (Language a, Logic b c, Logic d e)
=> Comorph a b c d e | a -> b, a -> d
instance (Comorph a1 b1 c1 d1 e1, Comorph a2 b2 c2 d2 e2)
=> Language (a1, a2)
instance (Comorph a1 b1 c1 d1 e1, Comorph a2 b2 c2 d2 e2)
=> Comorph (a1, a2) b1 c1 d2 e2
-- end of module
ghc-6.4 (or ghc-6.4.1) complains with:
Context.hs:11:0:
Could not deduce (Comorph a2 b2 c21 d2 e21, Comorph
a1 b1 c11 d1 e11)
from the context (Comorph a1 b1 c1 d1 e1, Comorph
a2 b2 c2 d2 e2)
arising from the superclasses of an instance
declaration at
Context.hs:11:0
Probable fix:
add (Comorph a2 b2 c21 d2 e21, Comorph a1 b1 c11
d1 e11)
to the instance declaration superclass context
In the instance declaration for `Comorph (a1, a2)
b1 c1 d2 e2'
If I replace the first instance with
"instance (Language a1, Language a2) => Language (a1, a2)"
then ghc-6.4 is happy.
Cheers Christian
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedInvalid |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"unjustified deduction error","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"ResolvedInvalid","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"6.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\n(also sent to glasgow-haskell-users) maeder@tzi.de\n\nthe following (reduced) example used to go through with\nghc-6.2.2 but fails with ghc-6.4. \n\nThis seems to be a - low priority - bug. (hugs accepts\nthis module.)\nI compile with:\n\nghc -fglasgow-exts Context.hs\n\n\nmodule Context where\n\nclass Language a\nclass Language a => Logic a b | a -> b\nclass (Language a, Logic b c, Logic d e)\n => Comorph a b c d e | a -> b, a -> d\n\ninstance (Comorph a1 b1 c1 d1 e1, Comorph a2 b2 c2 d2 e2)\n => Language (a1, a2)\n\ninstance (Comorph a1 b1 c1 d1 e1, Comorph a2 b2 c2 d2 e2)\n => Comorph (a1, a2) b1 c1 d2 e2\n\n-- end of module\n\nghc-6.4 (or ghc-6.4.1) complains with:\n\nContext.hs:11:0:\n Could not deduce (Comorph a2 b2 c21 d2 e21, Comorph\na1 b1 c11 d1 e11)\n from the context (Comorph a1 b1 c1 d1 e1, Comorph\na2 b2 c2 d2 e2)\n arising from the superclasses of an instance\ndeclaration at\nContext.hs:11:0\n Probable fix:\n add (Comorph a2 b2 c21 d2 e21, Comorph a1 b1 c11\nd1 e11)\n to the instance declaration superclass context\n In the instance declaration for `Comorph (a1, a2)\nb1 c1 d2 e2'\n\n\nIf I replace the first instance with\n\"instance (Language a1, Language a2) => Language (a1, a2)\"\nthen ghc-6.4 is happy.\n\nCheers Christian\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/392forall in pattern type sig has changed from 6.2.22019-07-07T19:18:11Zmtullsenforall in pattern type sig has changed from 6.2.2```
------ The program (straight from documentation :-) ------
$ cat Test.hs
test = \(f :: forall a. a -> a) -> (f True,f 'a')
------ Works fine under 6.2.2 ------
tests $ ghci-6.2.2 -fglasgow-exts Test.hs
...
Compiling Test ...```
------ The program (straight from documentation :-) ------
$ cat Test.hs
test = \(f :: forall a. a -> a) -> (f True,f 'a')
------ Works fine under 6.2.2 ------
tests $ ghci-6.2.2 -fglasgow-exts Test.hs
...
Compiling Test ( Test.hs, interpreted )
Ok, modules loaded: Test.
------ Doesn't typecheck under 6.4 ------
$ ghci-6.4 -fglasgow-exts Test.hs
...
Compiling Test ( Test.hs, interpreted )
Test.hs:3:9:
Inferred type is less polymorphic than expected
Quantified type variable `a' is mentioned in the environment:
test :: (a -> a) -> t (bound at Test.hs:3:0)
Expected type: forall a1. a1 -> a1
Inferred type: a -> a
In a lambda abstraction: \ (f :: forall a. a -> a) -> (f True, f 'a')
In the definition of `test': test = \ (f :: forall a. a -> a) -> (f True, f
'a')
...
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"forall in pattern type sig has changed from 6.2.2","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"6.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\n------ The program (straight from documentation :-) ------\n$ cat Test.hs\n\ntest = \\(f :: forall a. a -> a) -> (f True,f 'a')\n\n------ Works fine under 6.2.2 ------\ntests $ ghci-6.2.2 -fglasgow-exts Test.hs\n...\nCompiling Test ( Test.hs, interpreted )\nOk, modules loaded: Test.\n\n------ Doesn't typecheck under 6.4 ------\n$ ghci-6.4 -fglasgow-exts Test.hs\n...\nCompiling Test ( Test.hs, interpreted )\n\nTest.hs:3:9:\n Inferred type is less polymorphic than expected\n Quantified type variable `a' is mentioned in the environment:\n test :: (a -> a) -> t (bound at Test.hs:3:0)\n Expected type: forall a1. a1 -> a1\n Inferred type: a -> a\n In a lambda abstraction: \\ (f :: forall a. a -> a) -> (f True, f 'a')\n In the definition of `test': test = \\ (f :: forall a. a -> a) -> (f True, f \n'a')\n...\n\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/393functions without implementations2023-04-01T22:28:21ZGhost Userfunctions without implementations```
Allow to declare a function by only supplying its type
signature.
This feature shall enhance rapid prototyping by fixing
an interface but leaving some functions unimplemented.
Currently this can be (only) simulated by supplying
dumm...```
Allow to declare a function by only supplying its type
signature.
This feature shall enhance rapid prototyping by fixing
an interface but leaving some functions unimplemented.
Currently this can be (only) simulated by supplying
dummy implementations, like
f :: ...
f = undefined
Since it is possible to supply dummy data types by
"data T" (not followed by "="), allowing functions
without implementations seems almost to be a logical
consequence. Surely, the compiler should emit warnings
for missing implementations.
It would be nice if such function declarations via type
signatures could be repeated at any position within a
module.
```IcelandjackIcelandjackhttps://gitlab.haskell.org/ghc/ghc/-/issues/394program seqfaults when translated with profiling2019-07-07T19:18:11ZGhost Userprogram seqfaults when translated with profiling```
The following program seqfaults when translated with
profiling under linux und with ghc-6.4 and ghc-6.4.1.
If I omit the last element of the string list or if I
use the list directly (without the definitiion of the
constant "mainS")...```
The following program seqfaults when translated with
profiling under linux und with ghc-6.4 and ghc-6.4.1.
If I omit the last element of the string list or if I
use the list directly (without the definitiion of the
constant "mainS") the problem is gone. Also ghc-6.2.2
does not have the problem.
maeder@jupiter -> ghc --version
The Glorious Glasgow Haskell Compilation System,
version 6.4.1.20050517
maeder@jupiter -> ghc --make -prof -auto-all
seqfault.hs -no-recomp
Chasing modules from: seqfault.hs
Compiling Main ( seqfault.hs, seqfault.o )
Linking ...
maeder@jupiter -> ./a.out
Segmentation fault
maeder@jupiter -> uname -a
Linux jupiter 2.6.8-24.14-smp #1 SMP Tue Mar 29
09:27:43 UTC 2005 i686 i686 i386GNU/Linux
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 6.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"program seqfaults when translated with profiling","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"6.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nThe following program seqfaults when translated with\nprofiling under linux und with ghc-6.4 and ghc-6.4.1.\n\nIf I omit the last element of the string list or if I\nuse the list directly (without the definitiion of the\nconstant \"mainS\") the problem is gone. Also ghc-6.2.2\ndoes not have the problem.\n\nmaeder@jupiter -> ghc --version\nThe Glorious Glasgow Haskell Compilation System,\nversion 6.4.1.20050517\n\nmaeder@jupiter -> ghc --make -prof -auto-all\nseqfault.hs -no-recomp\nChasing modules from: seqfault.hs\nCompiling Main ( seqfault.hs, seqfault.o )\nLinking ...\n\nmaeder@jupiter -> ./a.out\nSegmentation fault\n\nmaeder@jupiter -> uname -a\nLinux jupiter 2.6.8-24.14-smp #1 SMP Tue Mar 29\n09:27:43 UTC 2005 i686 i686 i386GNU/Linux\n\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/395non-termination without optimization2019-07-07T19:18:11ZGhost Usernon-termination without optimization```
I've found a (relatively) small example that does not
terminate if
translated unoptimized under linux with ghc-6.4 or
ghc-6.4.1, although it should (and does with ghc-6.2.2).
I compile with:
ghc --make trans.hs -o trans -no-recomp
...```
I've found a (relatively) small example that does not
terminate if
translated unoptimized under linux with ghc-6.4 or
ghc-6.4.1, although it should (and does with ghc-6.2.2).
I compile with:
ghc --make trans.hs -o trans -no-recomp
and let the program process the file "Map.hs" (that is
merely used as
input data) several times. While "./trans" sometimes
succeeds to
translate Map.hs a couple of times it fails to
translate it more times
and leaves a half translated file Map.hs.trans.
Unfortunately the exact
amount of data that needs to be processed varies in
order to tickle the
bug. (7 times Map.hs below, up to 11 times in other cases).
The program terminates as expected if I use my
(included) Map.hs instead of Data.Map, or if I declare
the character map to be a separate
constant, or if I compile with optimization.
If compiled unoptimized with profiling it also does not
terminate.
maeder@jupiter -> uname -a
Linux jupiter 2.6.8-24.14-smp #1 SMP Tue Mar 29
09:27:43 UTC 2005 i686
i686 i386GNU/Linux
maeder@jupiter -> gcc --version
gcc (GCC) 3.3.4 (pre 3.3.5 20040809)
Copyright (C) 2003 Free Software Foundation, Inc.
maeder@jupiter -> ghc --version
The Glorious Glasgow Haskell Compilation System,
version 6.4.1.20050517
maeder@jupiter -> ghc --make trans.hs -o trans -no-recomp
Chasing modules from: trans.hs
Compiling Main ( trans.hs, trans.o )
Linking ...
maeder@jupiter -> date
Fr Mai 20 10:27:00 CEST 2005
maeder@jupiter -> time ./trans Map.hs Map.hs Map.hs
Map.hs Map.hs Map.hs
real 0m20.732s
user 0m20.298s
sys 0m0.031s
maeder@jupiter -> ll Map.*
-rw-r--r-- 1 maeder wimi 57184 2005-05-20 09:31 Map.hs
-rw-r--r-- 1 maeder wimi 207572 2005-05-20 10:27
Map.hs.trans
maeder@jupiter -> time ./trans Map.hs Map.hs Map.hs
Map.hs Map.hs Map.hs
Map.hs
trans: interrupted
real 4m29.816s
user 4m5.554s
sys 0m24.120s
maeder@jupiter -> ll Map.*
-rw-r--r-- 1 maeder wimi 57184 2005-05-20 09:31 Map.hs
-rw-r--r-- 1 maeder wimi 98304 2005-05-20 10:28
Map.hs.trans
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 6.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"non-termination without optimization ","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"simonmar"},"version":"6.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nI've found a (relatively) small example that does not\nterminate if\ntranslated unoptimized under linux with ghc-6.4 or\nghc-6.4.1, although it should (and does with ghc-6.2.2).\n\nI compile with:\n\nghc --make trans.hs -o trans -no-recomp\n\nand let the program process the file \"Map.hs\" (that is\nmerely used as\ninput data) several times. While \"./trans\" sometimes\nsucceeds to\ntranslate Map.hs a couple of times it fails to\ntranslate it more times\nand leaves a half translated file Map.hs.trans.\nUnfortunately the exact\namount of data that needs to be processed varies in\norder to tickle the\nbug. (7 times Map.hs below, up to 11 times in other cases).\n\nThe program terminates as expected if I use my\n(included) Map.hs instead of Data.Map, or if I declare\nthe character map to be a separate\nconstant, or if I compile with optimization.\n\nIf compiled unoptimized with profiling it also does not\nterminate.\n\nmaeder@jupiter -> uname -a\nLinux jupiter 2.6.8-24.14-smp #1 SMP Tue Mar 29\n09:27:43 UTC 2005 i686\ni686 i386GNU/Linux\n\nmaeder@jupiter -> gcc --version\ngcc (GCC) 3.3.4 (pre 3.3.5 20040809)\nCopyright (C) 2003 Free Software Foundation, Inc.\n\nmaeder@jupiter -> ghc --version\nThe Glorious Glasgow Haskell Compilation System,\nversion 6.4.1.20050517\n\nmaeder@jupiter -> ghc --make trans.hs -o trans -no-recomp\nChasing modules from: trans.hs\nCompiling Main ( trans.hs, trans.o )\nLinking ...\n\nmaeder@jupiter -> date\nFr Mai 20 10:27:00 CEST 2005\n\nmaeder@jupiter -> time ./trans Map.hs Map.hs Map.hs\nMap.hs Map.hs Map.hs\n\nreal 0m20.732s\nuser 0m20.298s\nsys 0m0.031s\n\nmaeder@jupiter -> ll Map.*\n-rw-r--r-- 1 maeder wimi 57184 2005-05-20 09:31 Map.hs\n-rw-r--r-- 1 maeder wimi 207572 2005-05-20 10:27\nMap.hs.trans\n\nmaeder@jupiter -> time ./trans Map.hs Map.hs Map.hs\nMap.hs Map.hs Map.hs\nMap.hs\ntrans: interrupted\n\nreal 4m29.816s\nuser 4m5.554s\nsys 0m24.120s\n\nmaeder@jupiter -> ll Map.*\n-rw-r--r-- 1 maeder wimi 57184 2005-05-20 09:31 Map.hs\n-rw-r--r-- 1 maeder wimi 98304 2005-05-20 10:28\nMap.hs.trans\n\n\n\n\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/396Segfault on MVar-abuse2019-07-07T19:18:10ZvolkersfSegfault on MVar-abuse```
The attached program segfaults using 6.4 on FreeBSD at the 2nd
takeMVar. Sorry, no HEAD to test with atm (I understand that the
program might be strechting the limits a bit ;).
Other interesting effects can be observer, e.g. a rath...```
The attached program segfaults using 6.4 on FreeBSD at the 2nd
takeMVar. Sorry, no HEAD to test with atm (I understand that the
program might be strechting the limits a bit ;).
Other interesting effects can be observer, e.g. a rather unexpected
"threads blocked indefinetely" when commenting out both lines (1) &
(2) OR having both lines activated.
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 6.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedNoReason |
| Component | None |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Segfault on MVar-abuse","status":"New","operating_system":"","component":"None","related":[],"milestone":"","resolution":"ResolvedNoReason","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"6.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nThe attached program segfaults using 6.4 on FreeBSD at the 2nd \ntakeMVar. Sorry, no HEAD to test with atm (I understand that the \nprogram might be strechting the limits a bit ;).\nOther interesting effects can be observer, e.g. a rather unexpected \n\"threads blocked indefinetely\" when commenting out both lines (1) & \n(2) OR having both lines activated.\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/397Reading source files in encodings other than Latin-12019-07-07T19:18:10ZnobodyReading source files in encodings other than Latin-1```
For GHC 6.4 on SuSE Linux 9.2 (installed from the GHC RPM).
When including SOME non-ascii characters in character or
string literals, in the source code, I get a "lexical error in
string/character literal" error message. Exampl...```
For GHC 6.4 on SuSE Linux 9.2 (installed from the GHC RPM).
When including SOME non-ascii characters in character or
string literals, in the source code, I get a "lexical error in
string/character literal" error message. Examples are some
french accents and german umlauts - é,Ü,Ä. However, with
other characters from the same set (like üä) there is no
problem, they are processed correctly
I checked with Hugs and there were no problems, so it seems
to be a GHC bug.
For further questions send email to: Rainer Volz, mail at
vrtprj.com
```nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/398Xlib Types Not Instances of Anything2019-07-07T19:18:10ZjcastXlib Types Not Instances of AnythingThe types defined by newtype in Graphics.X11.Xlib.Types
are not instances of any type classes. Ptr, on the
other hand, which these types are synonyms for, is an
instance of Eq, Ord, Show, Typeable, Data, Storable,
and several other class...The types defined by newtype in Graphics.X11.Xlib.Types
are not instances of any type classes. Ptr, on the
other hand, which these types are synonyms for, is an
instance of Eq, Ord, Show, Typeable, Data, Storable,
and several other classes not relevant to the usage of
pointers in Graphics.X11.Xlib.Ross Patersonr.paterson@city.ac.ukRoss Patersonr.paterson@city.ac.ukhttps://gitlab.haskell.org/ghc/ghc/-/issues/399panic when splicing a declaration with an existing name2019-07-07T19:18:10Zstefanheimannpanic when splicing a declaration with an existing name```
The title and the attached test says all.
Run the test with `ghc --make -fth GHCBug.hs'
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| ...```
The title and the attached test says all.
Run the test with `ghc --make -fth GHCBug.hs'
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 6.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | Template Haskell |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"panic when splicing a declaration with an existing name","status":"New","operating_system":"","component":"Template Haskell","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"simonpj"},"version":"6.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nThe title and the attached test says all.\n\nRun the test with `ghc --make -fth GHCBug.hs'\n\n\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/400socketToHandle, hGetContents cause errors in ghci2019-07-07T19:18:10ZpimlottsocketToHandle, hGetContents cause errors in ghci```
I wrote a server using socketToHandle and hGetContents.
The first request worked fine, but the second request
crashed with "internal error: scavenge_stack: weird
activation record found on stack: 9". I tried to
create a test case. ...```
I wrote a server using socketToHandle and hGetContents.
The first request worked fine, but the second request
crashed with "internal error: scavenge_stack: weird
activation record found on stack: 9". I tried to
create a test case. I couldn't reproduce the same
problem, but I did get an intermittent "Bad file
descriptor". I think it may be a related problem, and
it may have to do with garbage collection (based on a
strace showing a call to getrusage).
The program is below, and when I run it with runghc and
feed it a line of input with nc, it crashes on the 17th
request. It's not important to me that you fix it; in
fact I only tried this as an experiment to simplify
some working code. But if you would like more
information, let me know.
I am using the Debian package ghc6 6.4-4.
import Network.Socket
import System.IO
main = do
s <- socket AF_INET Stream 0
h <- inet_addr "127.0.0.1"
bindSocket s (SockAddrInet 1236 h)
listen s 5
loop s
loop listenSock = do
(s,_) <- accept listenSock
h <- socketToHandle s ReadMode
input <- hGetContents h
putStrLn (take 10 input)
send s "got it\n"
sClose s
loop listenSock
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | None |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedNoReason |
| Component | libraries/network |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"socketToHandle, hGetContents cause errors in ghci","status":"New","operating_system":"","component":"libraries/network","related":[],"milestone":"","resolution":"ResolvedNoReason","owner":{"tag":"OwnedBy","contents":"simonmar"},"version":"None","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nI wrote a server using socketToHandle and hGetContents.\n The first request worked fine, but the second request\ncrashed with \"internal error: scavenge_stack: weird\nactivation record found on stack: 9\". I tried to\ncreate a test case. I couldn't reproduce the same\nproblem, but I did get an intermittent \"Bad file\ndescriptor\". I think it may be a related problem, and\nit may have to do with garbage collection (based on a\nstrace showing a call to getrusage).\n\nThe program is below, and when I run it with runghc and\nfeed it a line of input with nc, it crashes on the 17th\nrequest. It's not important to me that you fix it; in\nfact I only tried this as an experiment to simplify\nsome working code. But if you would like more\ninformation, let me know.\n\nI am using the Debian package ghc6 6.4-4.\n\nimport Network.Socket\nimport System.IO\n\nmain = do \n s <- socket AF_INET Stream 0\n h <- inet_addr \"127.0.0.1\"\n bindSocket s (SockAddrInet 1236 h)\n listen s 5 \n loop s \n\nloop listenSock = do\n (s,_) <- accept listenSock\n h <- socketToHandle s ReadMode\n input <- hGetContents h\n putStrLn (take 10 input)\n send s \"got it\\n\"\n sClose s\n loop listenSock\n\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/401hsc2hs looks for cmd.exe under Win982019-07-07T19:18:09Znobodyhsc2hs looks for cmd.exe under Win98```
vivian.mcphail@paradise.net.nz
hsc2hs.exe: C:\WINDOWS\SYSTEM\CMD.EXE: runCommand: does
not exist (No such file or directory)
This bug was fixed in GHC 6.4.1 for the library call,
but for some reason this is not the case with hsc2hs...```
vivian.mcphail@paradise.net.nz
hsc2hs.exe: C:\WINDOWS\SYSTEM\CMD.EXE: runCommand: does
not exist (No such file or directory)
This bug was fixed in GHC 6.4.1 for the library call,
but for some reason this is not the case with hsc2hs.exe.
Windows 98 uses command.com
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 6.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | None |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"hsc2hs looks for cmd.exe under Win98","status":"New","operating_system":"","component":"None","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"simonmar"},"version":"6.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nvivian.mcphail@paradise.net.nz\n\nhsc2hs.exe: C:\\WINDOWS\\SYSTEM\\CMD.EXE: runCommand: does\nnot exist (No such file or directory)\n\nThis bug was fixed in GHC 6.4.1 for the library call,\nbut for some reason this is not the case with hsc2hs.exe.\n\nWindows 98 uses command.com\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/402internal error: startTask: Can't create new task2019-07-07T19:18:09Znobodyinternal error: startTask: Can't create new task```
internal error: startTask: Can't create new task
With
ghc-6.4.20050506-src.tar.bz2
Fedora Core 3 (current updates) (gcc 3.4.3 glibc 2.3.5)
amd64
perl v5.8.5 x86_64-linux-thread-multi
pugs r4695
I built ghc-6.4.20050506-src by doing...```
internal error: startTask: Can't create new task
With
ghc-6.4.20050506-src.tar.bz2
Fedora Core 3 (current updates) (gcc 3.4.3 glibc 2.3.5)
amd64
perl v5.8.5 x86_64-linux-thread-multi
pugs r4695
I built ghc-6.4.20050506-src by doing:
./configure
make
make
make install
You can build pugs by doing:
svn co http://svn.openfoundry.org/pugs/ -r 4695
cd pugs
perl Makefile.PL
make unoptimized
To generate error,
EVALBOT_CODE='42' EVALBOT_TMPFILE=/tmp/deleteme EVALBO
T_PUGS=`pwd`/pugs perl -w examples/network/evalbot/evalhel
per.p5 ; cat /tmp/deleteme
Error:
$ cat /tmp/deleteme
pugs: internal error: startTask: Can't create new task
Please report this as a bug to
glasgow-haskell-bugs@haskell.org,
or http://www.sourceforge.net/projects/ghc/
Fyi.
Thanks for all your work,
Mitchell Charity
mncI02eyA zap vendian zot org
```6.4.2Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/403scavenge_stack: weird activation record found on stack:375482019-07-07T19:18:09Zmalairescavenge_stack: weird activation record found on stack:37548```
During 'make test' of pugs (http://pugscode.org/) which
is written in Haskell I got this error:
...
...
t/oo/class/nested_use..............................ok
t/oo/class/require.................................ok
2/3 TODO bug...```
During 'make test' of pugs (http://pugscode.org/) which
is written in Haskell I got this error:
...
...
t/oo/class/nested_use..............................ok
t/oo/class/require.................................ok
2/3 TODO bug tests
t/oo/clone.........................................ok
3/9 TODO feature tests
t/oo/construction..................................ok
6/7 TODO feature tests
t/oo/delegation....................................ok
24/34 TODO feature tests
t/oo/destruction...................................ok
3/6pugs: internal error: scavenge_stack: weird
activation record found on stack: 37548
Please report this as a bug to
glasgow-haskell-bugs@haskell.org,
or http://www.sourceforge.net/projects/ghc/
t/oo/destruction...................................dubious
Test returned status 254 (wstat 65024, 0xfe00)
after all the subtests completed successfully
...
...
I have:
* GHC 6.4
* pugs r4733
* parrot r8392
* SuSe 9.1
* "uname -a" gives "Linux 2.6.5-7.155.29-default #1 Thu
Jun 2 12:07:05 UTC 2005 i686 athlon i386 GNU/Linux"
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 6.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | None |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"scavenge_stack: weird activation record found on stack:37548","status":"New","operating_system":"","component":"None","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"simonmar"},"version":"6.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nDuring 'make test' of pugs (http://pugscode.org/) which\nis written in Haskell I got this error:\n\n...\n...\nt/oo/class/nested_use..............................ok\nt/oo/class/require.................................ok\n 2/3 TODO bug tests\nt/oo/clone.........................................ok\n 3/9 TODO feature tests\nt/oo/construction..................................ok\n 6/7 TODO feature tests\nt/oo/delegation....................................ok\n 24/34 TODO feature tests\nt/oo/destruction...................................ok\n3/6pugs: internal error: scavenge_stack: weird\nactivation record found on stack: 37548\n Please report this as a bug to\nglasgow-haskell-bugs@haskell.org,\n or http://www.sourceforge.net/projects/ghc/\nt/oo/destruction...................................dubious\n Test returned status 254 (wstat 65024, 0xfe00)\n after all the subtests completed successfully\n...\n...\n\n\nI have:\n* GHC 6.4\n* pugs r4733\n* parrot r8392\n* SuSe 9.1\n* \"uname -a\" gives \"Linux 2.6.5-7.155.29-default #1 Thu\nJun 2 12:07:05 UTC 2005 i686 athlon i386 GNU/Linux\"\n\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/404Double constant leads to malformed .hc2022-09-20T07:50:50ZManuel M T ChakravartyDouble constant leads to malformed .hc```
The program
> avogadro = 6.022E23
> main = print $ avogadro
when compiled with -O leads to a .hc about which gcc
complains
Main.hc: In function 'Main_lvl_entry':
Main.hc:328: warning: integer overflow in expression
The .hc fi...```
The program
> avogadro = 6.022E23
> main = print $ avogadro
when compiled with -O leads to a .hc about which gcc
complains
Main.hc: In function 'Main_lvl_entry':
Main.hc:328: warning: integer overflow in expression
The .hc files is attached.
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 6.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Double constant leads to malformed .hc","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"simonmar"},"version":"6.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nThe program\n\n> avogadro = 6.022E23\n> main = print $ avogadro\n\nwhen compiled with -O leads to a .hc about which gcc\ncomplains\n\n Main.hc: In function 'Main_lvl_entry':\n Main.hc:328: warning: integer overflow in expression\n\nThe .hc files is attached. \n\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/405Typechecker loop and stack overflow in 6.42019-07-07T19:18:08ZekarttunTypechecker loop and stack overflow in 6.4```
The following seems to trigger an loop in the typechecker,
which does from stack overflow after a while.
The example is quite pointless but shows
the bug.
newtype PRef a = PRef a
type Drop1 a = a
class Ref a r | a -> r where readRe...```
The following seems to trigger an loop in the typechecker,
which does from stack overflow after a while.
The example is quite pointless but shows
the bug.
newtype PRef a = PRef a
type Drop1 a = a
class Ref a r | a -> r where readRef :: a -> r
instance Ref (PRef a) (Drop1 a) where readRef (PRef v) = v
Here is a dump from the test (bug.hs contains the above code):
e@yui ~/work/pcl/hpclc $ ghci -v -fglasgow-exts bug.hs
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version 6.4, for Haskell 98.
/ /_\\/ __ / /___| | http://www.haskell.org/ghc/
\____/\/ /_/\____/|_| Type :? for help.
Using package config file: /usr/lib/ghc-6.4/package.conf
Using package config file: /home/e/.ghc/i386-linux-6.4/package.conf
Hsc static flags: -static
*** Parser:
*** Desugar:
*** Simplify:
*** CorePrep:
*** ByteCodeGen:
Loading package base-1.0 ... linking ... done.
*** Parser:
*** Desugar:
*** Simplify:
*** CorePrep:
*** ByteCodeGen:
*** Chasing dependencies:
unload: retaining objs []
unload: retaining bcos []
Stable modules:
unload: retaining objs []
unload: retaining bcos []
*** Compiling Main ( bug.hs, interpreted ):
compile: input file bug.hs
*** Checking old interface for Main:
Compiling Main ( bug.hs, interpreted )
*** Parser:
*** Renamer/typechecker:
*** Exception: stack overflow
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | None |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Typechecker loop and stack overflow in 6.4","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"None","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nThe following seems to trigger an loop in the typechecker,\nwhich does from stack overflow after a while.\nThe example is quite pointless but shows\nthe bug.\n\nnewtype PRef a = PRef a\ntype Drop1 a = a\nclass Ref a r | a -> r where readRef :: a -> r\ninstance Ref (PRef a) (Drop1 a) where readRef (PRef v) = v\n\nHere is a dump from the test (bug.hs contains the above code):\ne@yui ~/work/pcl/hpclc $ ghci -v -fglasgow-exts bug.hs \n ___ ___ _\n / _ \\ /\\ /\\/ __(_)\n / /_\\// /_/ / / | | GHC Interactive, version 6.4, for Haskell 98.\n/ /_\\\\/ __ / /___| | http://www.haskell.org/ghc/\n\\____/\\/ /_/\\____/|_| Type :? for help.\n\nUsing package config file: /usr/lib/ghc-6.4/package.conf\nUsing package config file: /home/e/.ghc/i386-linux-6.4/package.conf\nHsc static flags: -static\n*** Parser:\n*** Desugar:\n*** Simplify:\n*** CorePrep:\n*** ByteCodeGen:\nLoading package base-1.0 ... linking ... done.\n*** Parser:\n*** Desugar:\n*** Simplify:\n*** CorePrep:\n*** ByteCodeGen:\n*** Chasing dependencies:\nunload: retaining objs []\nunload: retaining bcos []\nStable modules:\nunload: retaining objs []\nunload: retaining bcos []\n*** Compiling Main ( bug.hs, interpreted ):\ncompile: input file bug.hs\n*** Checking old interface for Main:\nCompiling Main ( bug.hs, interpreted )\n*** Parser:\n*** Renamer/typechecker:\n*** Exception: stack overflow\n\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/406internal error: EVACUATED object entered!2019-07-07T19:18:07Zmalaireinternal error: EVACUATED object entered!```
During 'make test' of pugs (http://pugscode.org/) which
is written in Haskell I got this error:
...
...
t/oo/construction..................................ok
6/7 TODO feature tests
t/oo/delegation...............................```
During 'make test' of pugs (http://pugscode.org/) which
is written in Haskell I got this error:
...
...
t/oo/construction..................................ok
6/7 TODO feature tests
t/oo/delegation....................................ok
24/34 TODO feature tests
t/oo/destruction...................................ok
6/6# Looks like you failed 2 tests of 6
pugs: internal error: EVACUATED object entered!
Please report this as a bug to
glasgow-haskell-bugs@haskell.org,
or http://www.sourceforge.net/projects/ghc/
t/oo/destruction...................................dubious
Test returned status 254 (wstat 65024, 0xfe00)
DIED. FAILED tests 4-5
Failed 2/6 tests, 66.67% okay
t/oo/enums.........................................ok
54/58 TODO feature tests
...
...
I have:
* GHC 6.4
* pugs r4916
* (no parrot)
* SuSe 9.1
* "uname -a" gives "Linux markus 2.6.5-7.155.29-default
#1 Thu Jun 2 12:07:05 UTC 2005 i686 athlon i386 GNU/Linux"
```6.6.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/407Segfault when using -xc to smoke out a <<loop>>2019-07-07T19:18:07ZGhost UserSegfault when using -xc to smoke out a <<loop>>```
The following program illustrates the problem:
module Main where
data T k = T | S k deriving Show
test :: T k
test = test
main :: IO ()
main = putStrLn $ show (test :: T Int)
When compiled with
ghc --make Main.hs
and run, the...```
The following program illustrates the problem:
module Main where
data T k = T | S k deriving Show
test :: T k
test = test
main :: IO ()
main = putStrLn $ show (test :: T Int)
When compiled with
ghc --make Main.hs
and run, the program outputs "<<loop>>". Which is fine.
However, when compiled with
ghc --make Main.hs -prof -auto-all
and run with
./a.out +RTS -xc -RTS
the result is a segmentation fault. There is no stack
trace.
The test was done on Gentoo Linux, the CPU is Athlon XP.
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Segfault when using -xc to smoke out a <<loop>>","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"simonmar"},"version":"6.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nThe following program illustrates the problem:\n\nmodule Main where\n\ndata T k = T | S k deriving Show\n\ntest :: T k\ntest = test\n\nmain :: IO ()\nmain = putStrLn $ show (test :: T Int)\n\nWhen compiled with\n ghc --make Main.hs\nand run, the program outputs \"<<loop>>\". Which is fine.\nHowever, when compiled with\n ghc --make Main.hs -prof -auto-all\nand run with\n ./a.out +RTS -xc -RTS\nthe result is a segmentation fault. There is no stack\ntrace.\n\nThe test was done on Gentoo Linux, the CPU is Athlon XP. \n\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/408OpenAL needs -pthread2019-07-07T19:18:07ZvolkersfOpenAL needs -pthread```
On FreeBSD (and maybe NetBSD as well), OpenAL needs -pthread in
CFLAGS/LDFLAGS:
configure:2352: gcc -o conftest -I/usr/local/include -L/usr/local/lib
conftest.c -lopenal >&5
/usr/local/lib/libopenal.so: undefined reference to...```
On FreeBSD (and maybe NetBSD as well), OpenAL needs -pthread in
CFLAGS/LDFLAGS:
configure:2352: gcc -o conftest -I/usr/local/include -L/usr/local/lib
conftest.c -lopenal >&5
/usr/local/lib/libopenal.so: undefined reference to `pthread_create'
/usr/local/lib/libopenal.so: undefined reference to `pthread_attr_init'
/usr/local/lib/libopenal.so: undefined reference to `pthread_exit'
This should best be solved during configure instead of setting this
globally. Also, this probably needs to be propagated into OpenAL.
cabal for linking a resulting application (although already the RTS
should pull in -pthread).
```Not GHCpannepannehttps://gitlab.haskell.org/ghc/ghc/-/issues/409confusing error2019-07-07T19:18:06Zpimlottconfusing error```
I got a perplexing error message. Here is a concise
example:
t = ((\Just x -> x) :: Maybe a -> a) (Just 1)
Try.hs:1:6:
Couldn't match the rigid variable `a' against
`t -> t1'
`a' is bound by the polym...```
I got a perplexing error message. Here is a concise
example:
t = ((\Just x -> x) :: Maybe a -> a) (Just 1)
Try.hs:1:6:
Couldn't match the rigid variable `a' against
`t -> t1'
`a' is bound by the polymorphic type `forall
a. Maybe a -> a' at Try.hs:1:5-34
Expected type: a
Inferred type: t -> t1
In the expression: (\ Just x -> x) :: Maybe a -> a
In the definition of `t': t = ((\ Just x -> x)
:: Maybe a -> a) (Just 1)
Failed, modules loaded: none.
It seems to be telling me that the whole expression "(\
Just x -> x) ::
Maybe a -> a" was expected to have type a, in
contradiction to the explicit
type annotation it prints out! In the context of a
larger program, this
threw me for a loop. I would have expected
Expected type: Maybe -> a
Inferred type: Maybe -> t -> t1
Even better, if I change the code, I get a helpful
diagnostic:
t = (\Just x -> x) (Just 1)
Try.hs:1:6:
Constructor `Just' should have 1 argument, but
has been given 0
When checking the pattern: Just
In a lambda abstraction: \ Just x -> x
In the definition of `t': t = (\ Just x -> x)
(Just 1)
Failed, modules loaded: none.
Could I get that error in the first example? You could
probably go even further: "(did you forget parentheses
around the pattern?)".
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | None |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"confusing error","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"simonpj"},"version":"None","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nI got a perplexing error message. Here is a concise\nexample:\n\n t = ((\\Just x -> x) :: Maybe a -> a) (Just 1)\n \n Try.hs:1:6:\n Couldn't match the rigid variable `a' against\n`t -> t1'\n `a' is bound by the polymorphic type `forall\na. Maybe a -> a' at Try.hs:1:5-34\n Expected type: a\n Inferred type: t -> t1\n In the expression: (\\ Just x -> x) :: Maybe a -> a\n In the definition of `t': t = ((\\ Just x -> x)\n:: Maybe a -> a) (Just 1)\n Failed, modules loaded: none.\n\nIt seems to be telling me that the whole expression \"(\\\nJust x -> x) ::\nMaybe a -> a\" was expected to have type a, in\ncontradiction to the explicit\ntype annotation it prints out! In the context of a\nlarger program, this\nthrew me for a loop. I would have expected\n\n Expected type: Maybe -> a\n Inferred type: Maybe -> t -> t1\n\nEven better, if I change the code, I get a helpful\ndiagnostic:\n\n t = (\\Just x -> x) (Just 1)\n\n Try.hs:1:6:\n Constructor `Just' should have 1 argument, but\nhas been given 0\n When checking the pattern: Just\n In a lambda abstraction: \\ Just x -> x\n In the definition of `t': t = (\\ Just x -> x)\n(Just 1)\n Failed, modules loaded: none.\n\nCould I get that error in the first example? You could\nprobably go even further: \"(did you forget parentheses\naround the pattern?)\".\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/410compiler panic when class name is used as a type2019-07-07T19:18:05Znobodycompiler panic when class name is used as a type```
The compiler panics with a message "the `impossible'
happened" when compiling the following:
class Foo where
bar :: Foo
It seems to happen whenever the class name is used
as a type within its own `where' c...```
The compiler panics with a message "the `impossible'
happened" when compiling the following:
class Foo where
bar :: Foo
It seems to happen whenever the class name is used
as a type within its own `where' clause. This should
yield a more comprehensible error message.
I can be reached at vnkwjyc02@sneakemail.com
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 6.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"compiler panic when class name is used as a type","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"6.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nThe compiler panics with a message \"the `impossible' \nhappened\" when compiling the following: \n \nclass Foo where \n bar :: Foo \n \nIt seems to happen whenever the class name is used \nas a type within its own `where' clause. This should \nyield a more comprehensible error message. \n \nI can be reached at vnkwjyc02@sneakemail.com \n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/411panic: "Non-exhaustive patterns in function zip_ty_env"2019-07-07T19:18:05Znobodypanic: "Non-exhaustive patterns in function zip_ty_env"```
ghc-6.4: panic! (the `impossible' happened, GHC version
6.4):
types/Type.lhs:(1107,0)-(1108,77):
Non-exhaustive patterns in function zip_ty_env
The same file compiles fine with GHC 6.2.2.
Unfortunately I don't have a small ...```
ghc-6.4: panic! (the `impossible' happened, GHC version
6.4):
types/Type.lhs:(1107,0)-(1108,77):
Non-exhaustive patterns in function zip_ty_env
The same file compiles fine with GHC 6.2.2.
Unfortunately I don't have a small example of this
behaviour. I can send you the whole library if you need
it, but it is not painless to get to this point.
It would be great if you could give me some pointers
about where the bug might lie - it uses MPTC instances,
recursive newtypes and the FFI.
thanks,
peter, peteg at unsw.edu.au
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | None |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"panic: \"Non-exhaustive patterns in function zip_ty_env\"","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"simonpj"},"version":"None","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nghc-6.4: panic! (the `impossible' happened, GHC version\n6.4):\n types/Type.lhs:(1107,0)-(1108,77):\nNon-exhaustive patterns in function zip_ty_env\n\nThe same file compiles fine with GHC 6.2.2.\n\nUnfortunately I don't have a small example of this\nbehaviour. I can send you the whole library if you need\nit, but it is not painless to get to this point.\n\nIt would be great if you could give me some pointers\nabout where the bug might lie - it uses MPTC instances,\nrecursive newtypes and the FFI.\n\nthanks,\npeter, peteg at unsw.edu.au\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/412Warning and glagow-exts instead of glasgow-exts2019-07-07T19:18:04ZnobodyWarning and glagow-exts instead of glasgow-exts```
Take this module (Bla.hs):
x = [ q | y <- [1..10] | z <- [30..40], let q = z*z]
Loading it into GHCi gives:
[ Bla.hs:1: Illegal parallel list comprehension: use -
fglagow-exts ]
PROBLEM: glagow-exts should be glasgow-exts
If we...```
Take this module (Bla.hs):
x = [ q | y <- [1..10] | z <- [30..40], let q = z*z]
Loading it into GHCi gives:
[ Bla.hs:1: Illegal parallel list comprehension: use -
fglagow-exts ]
PROBLEM: glagow-exts should be glasgow-exts
If we supply this option, one of the warnings is incorrect:
[ Bla.hs:1: Warning: Defined but not used: y, z ]
PROBLEM: z is used but marked as not used
Cheers, Arjan (afie@cs.uu.nl)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | None |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Warning and glagow-exts instead of glasgow-exts","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"simonpj"},"version":"None","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nTake this module (Bla.hs): \n\nx = [ q | y <- [1..10] | z <- [30..40], let q = z*z]\n\nLoading it into GHCi gives:\n\n[ Bla.hs:1: Illegal parallel list comprehension: use -\nfglagow-exts ]\n\nPROBLEM: glagow-exts should be glasgow-exts\n\nIf we supply this option, one of the warnings is incorrect:\n\n[ Bla.hs:1: Warning: Defined but not used: y, z ]\n\nPROBLEM: z is used but marked as not used\n\nCheers, Arjan (afie@cs.uu.nl)\n\n\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/413runghc exits with status zero when compilation fails2019-07-07T19:18:04Zmagunterrunghc exits with status zero when compilation fails```
runghc and ghc -e exit with status zero even when
compilation fails. I
believe they should exit with a non-zero status when
compilation fails.
```
<details><summary>Trac metadata</summary>
| Trac field | Value ...```
runghc and ghc -e exit with status zero even when
compilation fails. I
believe they should exit with a non-zero status when
compilation fails.
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 6.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"runghc exits with status zero when compilation fails","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"simonmar"},"version":"6.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nrunghc and ghc -e exit with status zero even when\ncompilation fails. I\nbelieve they should exit with a non-zero status when\ncompilation fails.\n\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/414GHC does not eforce that Main exports main2020-03-22T17:02:46ZSimon Peyton JonesGHC does not eforce that Main exports main```
The Haskell 98 report says "A Haskell program is a
collection of
modules, one of which, by convention, must be called
Main and must
export the value main." However, the program below
builds and executes
fine.
module Main() -- sho...```
The Haskell 98 report says "A Haskell program is a
collection of
modules, one of which, by convention, must be called
Main and must
export the value main." However, the program below
builds and executes
fine.
module Main() -- should be "module Main" or "module
Main(main)"
where
main = putStrLn "Hello, World"
$ runghc Main.hs
Hello, World
Originally reported by Brian Smith
[brianlsmith@gmail.com]
```6.12.2Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/415Bad location for violation of functional dependency2019-07-07T19:18:03ZmagunterBad location for violation of functional dependency```
The code below produces an error message which gives no
clue
that the actual source of the error is on the line
marked L3
(pointing instead to L1 and L2):
.../BadWarningLoc.hs:1:0:
Couldn't match `S Z' against `Z'
Expect...```
The code below produces an error message which gives no
clue
that the actual source of the error is on the line
marked L3
(pointing instead to L1 and L2):
.../BadWarningLoc.hs:1:0:
Couldn't match `S Z' against `Z'
Expected type: S Z
Inferred type: Z
When using functional dependencies to combine
MinMax a Z Z a,
arising from the instance declaration at
.../BadWarningLoc.hs:10:0
MinMax (S Z) Z _c d,
arising from use of `t' at .../BadWarningLoc.hs:21:8-10
With the type signature, marked L4, uncommented the error
message does indeed point to the culprit, L3.
(With L3 commented-out, the code compiles.)
thanks,
mike
{-# OPTIONS_GHC -fglasgow-exts
-fallow-undecidable-instances #-}
data Z = Z
data S a = S a
n0 = Z
n1 = S n0
class MinMax a b c d | a b -> c d, a c d -> b, b c d -> a
instance MinMax Z Z Z Z
instance MinMax a Z Z a -- L1: wrongly flagged as
error src.
instance MinMax Z b Z b
instance MinMax a b c d => MinMax (S a) (S b) (S c) (S d)
class Extend a b where extend :: a -> b -> b
instance Extend Z b where Z `extend` b = b
instance MinMax a b _c b => Extend a b where _a
`extend` b = b
t :: MinMax a b _c d => a -> b -> d
t _ _ = (undefined :: d)
t1 = n1 `t` n0 -- L2
t2 = n1 `extend` n0 -- L3: uncommenting just this line
produces
-- an error message pointing at L1 and L2
-- with no mention of the real culprit, L3.
--t1 :: S Z -- L4: uncommenting this and L3 produces an
-- error message rightly pointing at L2 and L3.
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Bad location for violation of functional dependency","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"6.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nThe code below produces an error message which gives no\nclue\nthat the actual source of the error is on the line\nmarked L3\n(pointing instead to L1 and L2):\n\n .../BadWarningLoc.hs:1:0:\n Couldn't match `S Z' against `Z'\n Expected type: S Z\n Inferred type: Z\n When using functional dependencies to combine\n MinMax a Z Z a,\n\tarising from the instance declaration at\n.../BadWarningLoc.hs:10:0\n MinMax (S Z) Z _c d,\n\tarising from use of `t' at .../BadWarningLoc.hs:21:8-10\n\nWith the type signature, marked L4, uncommented the error\nmessage does indeed point to the culprit, L3.\n\n(With L3 commented-out, the code compiles.)\n\n\tthanks,\n\tmike\n\n{-# OPTIONS_GHC -fglasgow-exts\n-fallow-undecidable-instances #-}\ndata Z\t\t= Z\ndata S a\t= S a\n\nn0\t= Z\nn1\t= S n0\n\nclass MinMax a b c d | a b -> c d, a c d -> b, b c d -> a\ninstance MinMax Z Z Z Z\t\t\t\t\ninstance MinMax a Z Z a\t -- L1: wrongly flagged as\nerror src.\ninstance MinMax Z b Z b\t\t\t\t\ninstance MinMax a b c d => MinMax (S a) (S b) (S c) (S d)\n\nclass Extend a b where extend :: a -> b -> b\ninstance Extend Z b where Z `extend` b = b\ninstance MinMax a b _c b => Extend a b where _a\n`extend` b = b\n\nt\t:: MinMax a b _c d => a -> b -> d\nt _ _\t= (undefined :: d)\n\nt1 = n1 `t` n0\t -- L2\nt2 = n1 `extend` n0 -- L3: uncommenting just this line\nproduces\n\t\t --\t an error message pointing at L1 and L2\n\t\t --\t with no mention of the real culprit, L3.\n--t1\t:: S Z\t -- L4: uncommenting this and L3 produces an\n\t\t --\terror message rightly pointing at L2 and L3.\n\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/416instance of synonym2019-07-07T19:18:03Znobodyinstance of synonym```
The following non-Haskell 98 instance is accepted even
without -fglasgow-exts:
type Foo = Double
instance Bounded Foo
The error message quotes the relevant part of the
Report (The instance type must be of form (T a b c)
where T is ...```
The following non-Haskell 98 instance is accepted even
without -fglasgow-exts:
type Foo = Double
instance Bounded Foo
The error message quotes the relevant part of the
Report (The instance type must be of form (T a b c)
where T is not a synonym, and a,b,c are distinct type
variables) and the code expresses this, but it seems
that type synonyms have already been expanded, so only
non-saturated ones are left at this stage.
ross@soi.city.ac.uk
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | None |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"instance of synonym","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"None","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nThe following non-Haskell 98 instance is accepted even\nwithout -fglasgow-exts:\n\ntype Foo = Double\ninstance Bounded Foo\n\nThe error message quotes the relevant part of the\nReport (The instance type must be of form (T a b c)\nwhere T is not a synonym, and a,b,c are distinct type\nvariables) and the code expresses this, but it seems\nthat type synonyms have already been expanded, so only\nnon-saturated ones are left at this stage.\n\nross@soi.city.ac.uk\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/417Hardcoded path to perl.exe2019-07-07T19:18:02ZnobodyHardcoded path to perl.exe```
I apologize in advance for not selecting a proper
category but as I am an extreme neophyte - I didn't
know what to select.
I use GHC primarily to build Pugs (http://pugscode.org)
I got frustrated that on Win32, the current working
...```
I apologize in advance for not selecting a proper
category but as I am an extreme neophyte - I didn't
know what to select.
I use GHC primarily to build Pugs (http://pugscode.org)
I got frustrated that on Win32, the current working
directory supercedes the %PATH variable and the
perl.exe in the GHC root directory was getting used
instead of my freshly installed 5.8.7
I deleted the file and corresponding perl56.dll and
everything appeared to be working fine and yet Pugs
would fail to build spitting out a cryptic 0x01 error
(not exactly sure what the code was but it wasn't helpful).
Since I had deleted the files instead of renaming them
(hindsight always being 20/20) and not wanting to
install GHC all over again just to see if for some
strange reason that was the problem - I copied over the
perl.exe and perl58.dll and what do you know - it worked.
My bug report then is this - if there is some valid
reason to hardcode a path to the GHC root directory for
perl instead of looking in %PATH as a backup plan -
then please make any error message more descriptive.
Note: Not being very familiar with GHC, it might be
that the error message was very informative and that it
is the Pugs build process fault for not carrying it
over. If that is the case then please disregard and
please forgive.
Cheers,
Joshua Gatcomb
a.k.a. Limbic~Region
Limbic_Region_2000@Yahoo.com
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 6.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | None |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Hardcoded path to perl.exe","status":"New","operating_system":"","component":"None","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"6.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nI apologize in advance for not selecting a proper\ncategory but as I am an extreme neophyte - I didn't\nknow what to select.\n\nI use GHC primarily to build Pugs (http://pugscode.org)\n\nI got frustrated that on Win32, the current working\ndirectory supercedes the %PATH variable and the\nperl.exe in the GHC root directory was getting used\ninstead of my freshly installed 5.8.7\n\nI deleted the file and corresponding perl56.dll and\neverything appeared to be working fine and yet Pugs\nwould fail to build spitting out a cryptic 0x01 error\n(not exactly sure what the code was but it wasn't helpful).\n\nSince I had deleted the files instead of renaming them\n(hindsight always being 20/20) and not wanting to\ninstall GHC all over again just to see if for some\nstrange reason that was the problem - I copied over the\nperl.exe and perl58.dll and what do you know - it worked.\n\nMy bug report then is this - if there is some valid\nreason to hardcode a path to the GHC root directory for\nperl instead of looking in %PATH as a backup plan -\nthen please make any error message more descriptive.\n\nNote: Not being very familiar with GHC, it might be\nthat the error message was very informative and that it\nis the Pugs build process fault for not carrying it\nover. If that is the case then please disregard and\nplease forgive.\n\nCheers,\nJoshua Gatcomb\na.k.a. Limbic~Region\nLimbic_Region_2000@Yahoo.com\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/418throwTo to a thread inside 'block'2019-07-07T19:18:02ZremitthrowTo to a thread inside 'block'\[copy-pasting my original mail
(http://www.haskell.org/pipermail/glasgow-haskell-bugs/2005-June/005235.html)\]
Good evening,
I just stumbled across a segfault caused when running the
following small program. (During an attempt to impl...\[copy-pasting my original mail
(http://www.haskell.org/pipermail/glasgow-haskell-bugs/2005-June/005235.html)\]
Good evening,
I just stumbled across a segfault caused when running the
following small program. (During an attempt to implement
single-assignment variables.)
```
> module Main where
>
> import Control.Concurrent
> import System.IO.Unsafe (unsafeInterleaveIO)
>
> main = do
> v <- newEmptyMVar
> a <- unsafeInterleaveIO (readMVar v)
> t <- forkIO (print a)
> threadDelay (1000*1000)
> killThread t
> forkIO (print a)
> putMVar v ()
```
The crucial part about it seems to be the interruption
of the
lazy IO. Typing Ctl-c while running the first "print a"
by hand
from ghci instead of the forkIO+killThread doesn't change
behaviour:
```
Prelude System.IO.Unsafe Control.Concurrent> v <- newEmptyMVar
Prelude System.IO.Unsafe Control.Concurrent> a <- unsafeInterleaveIO (readMVar v)
Prelude System.IO.Unsafe Control.Concurrent> print a
Interrupted.
Prelude System.IO.Unsafe Control.Concurrent> forkIO (print a)
Prelude System.IO.Unsafe Control.Concurrent> putMVar v ()
zsh: segmentation fault (core dumped) ghci
```
Both 6.4 and 6.2.1 crash when running main from ghci.
When running it as a compiled executable everything is
fine.
Although I'm pretty sure I've seen 6.2.1 crashing
on it when run with -e main, I cannot reproduce it
anymore. 6.4
certainly happily runs it with -e main. (A serious lack
of sleep
the last week may play a role too.. :-/)
Whether the module is compiled before being loaded into
ghci has
no effect.
Core-dumps etc can of course be sent if necessary.
Good night,
Remihttps://gitlab.haskell.org/ghc/ghc/-/issues/419TcSimplify.lhs:(2093,13)-(2094,38): Non-exhaustive patterns2019-07-07T19:18:02ZnobodyTcSimplify.lhs:(2093,13)-(2094,38): Non-exhaustive patterns```
Dear ghc developers,
instead of giving some kind of 'unresolved overloading'
error message, the following code
% cat Bug.hs
{-# OPTIONS_GHC -fglasgow-exts #-}
module Bug where
class Foo a
instance Foo (a -> b)
foo :: Foo a => a -...```
Dear ghc developers,
instead of giving some kind of 'unresolved overloading'
error message, the following code
% cat Bug.hs
{-# OPTIONS_GHC -fglasgow-exts #-}
module Bug where
class Foo a
instance Foo (a -> b)
foo :: Foo a => a -> ()
foo = undefined
class Bar a r
-- The same happens if we use fundeps:
-- class Bar a r | r -> a
bar :: Bar a r => r -> ()
bar = undefined
test = foo bar
causes ghc to panic:
% ghc Bug.hs
ghc-6.5.20050709: panic! (the `impossible' happened,
GHC version 6.5.20050709):
typecheck/TcSimplify.lhs:(2093,13)-(2094,38):
Non-exhaustive patterns in case
Best regards,
Thomas Jäger
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | None |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"TcSimplify.lhs:(2093,13)-(2094,38): Non-exhaustive patterns","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"None","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nDear ghc developers,\n\ninstead of giving some kind of 'unresolved overloading'\nerror message, the following code\n\n% cat Bug.hs\n{-# OPTIONS_GHC -fglasgow-exts #-}\nmodule Bug where\n\nclass Foo a\ninstance Foo (a -> b)\n\nfoo :: Foo a => a -> ()\nfoo = undefined\n\nclass Bar a r\n-- The same happens if we use fundeps:\n-- class Bar a r | r -> a\n\nbar :: Bar a r => r -> ()\nbar = undefined\n\ntest = foo bar\n\ncauses ghc to panic:\n\n% ghc Bug.hs\nghc-6.5.20050709: panic! (the `impossible' happened,\nGHC version 6.5.20050709):\n typecheck/TcSimplify.lhs:(2093,13)-(2094,38):\nNon-exhaustive patterns in case\n\n\nBest regards,\n\nThomas Jäger\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/420O'Haskell2019-07-07T19:18:02ZmlbmO'Haskell```
Is there any project for extending GHC with support to
O'Haskell or any other object-oriented Haskell
extesion? That could be very useful for improving
Haskell interoperability with OO languages.
Thanks in advance,
Monique Monteiro...```
Is there any project for extending GHC with support to
O'Haskell or any other object-oriented Haskell
extesion? That could be very useful for improving
Haskell interoperability with OO languages.
Thanks in advance,
Monique Monteiro
```https://gitlab.haskell.org/ghc/ghc/-/issues/421Reloading edited mutually recursive modules gives error2019-07-07T19:18:01ZjosefsReloading edited mutually recursive modules gives error```
Given two modules which are mutually recursive, for
instance the following:
<file Boot.hs>
module Boot where
import A
data Data = forall n. Class n => D n
</file>
<file Boot.hs-boot>
module Boot where
data Data
</file>
<file A.hs>...```
Given two modules which are mutually recursive, for
instance the following:
<file Boot.hs>
module Boot where
import A
data Data = forall n. Class n => D n
</file>
<file Boot.hs-boot>
module Boot where
data Data
</file>
<file A.hs>
module A where
import {-# source #-} Boot
class Class a where
method :: a -> Data -> a
</file>
Now, if I do 'ghci Boot.hs' this will correctly cause
an error because Boot.hs needs -fglasgow-exts. So I add
{-# OPTIONS -fglasgow-exts #-} in the beginning of
Boot.hs. Finally I do ':r' in ghci. This yields the
following error:
*** Exception: expectJust upsweep_mod:old_linkable
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 6.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Reloading edited mutually recursive modules gives error","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"6.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nGiven two modules which are mutually recursive, for\ninstance the following:\n<file Boot.hs>\nmodule Boot where\n\nimport A\n\ndata Data = forall n. Class n => D n\n</file>\n<file Boot.hs-boot>\nmodule Boot where\n\ndata Data\n</file>\n<file A.hs>\nmodule A where\n\nimport {-# source #-} Boot\n\nclass Class a where\n method :: a -> Data -> a\n</file>\n\nNow, if I do 'ghci Boot.hs' this will correctly cause\nan error because Boot.hs needs -fglasgow-exts. So I add\n{-# OPTIONS -fglasgow-exts #-} in the beginning of\nBoot.hs. Finally I do ':r' in ghci. This yields the\nfollowing error:\n*** Exception: expectJust upsweep_mod:old_linkable\n\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/422Reloading mutually recursive modules gives more errors2019-07-07T19:18:01ZjosefsReloading mutually recursive modules gives more errors```
Sorry for the not so descriptive title. It seems I'm
tickling several bugs related to mutually recursive
modules with ghci. This time the setup looks like follows:
<file Boot.hs>
{-# OPTIONS -fglasgow-exts #-}
module Boot where
impo...```
Sorry for the not so descriptive title. It seems I'm
tickling several bugs related to mutually recursive
modules with ghci. This time the setup looks like follows:
<file Boot.hs>
{-# OPTIONS -fglasgow-exts #-}
module Boot where
import A
data Data = forall c. Class c => Data c
</file>
<file A.hs>
module A where
import {-# source #-} Boot
class Class a where
fkn :: a -> a
-- fkn = id
mkData :: a -> Data
modify :: Class a => a -> a
modify = fkn
</file>
<file Boot.hs-boot>
module Boot where
data Data
</file>
Now do 'ghci A.hs'. That should work alright. Then
uncomment the line in the class declaration in file
A.hs. Type ':r' in ghci. This is seems to confuse ghci
quite a lot:
A.hs:1:0: Circular imports: module `A' depends on itself
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 6.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedNoReason |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Reloading mutually recursive modules gives more errors","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"ResolvedNoReason","owner":{"tag":"OwnedBy","contents":"simonmar"},"version":"6.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nSorry for the not so descriptive title. It seems I'm\ntickling several bugs related to mutually recursive\nmodules with ghci. This time the setup looks like follows:\n<file Boot.hs>\n{-# OPTIONS -fglasgow-exts #-}\nmodule Boot where\n\nimport A\n\ndata Data = forall c. Class c => Data c\n</file>\n<file A.hs>\nmodule A where\n\nimport {-# source #-} Boot\n\nclass Class a where\n fkn :: a -> a\n-- fkn = id\n mkData :: a -> Data\n\nmodify :: Class a => a -> a\nmodify = fkn\n</file>\n<file Boot.hs-boot>\nmodule Boot where\n\ndata Data\n</file>\n\nNow do 'ghci A.hs'. That should work alright. Then\nuncomment the line in the class declaration in file\nA.hs. Type ':r' in ghci. This is seems to confuse ghci\nquite a lot:\nA.hs:1:0: Circular imports: module `A' depends on itself\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/423runProcess uses cwd for bad working directory argument2019-07-07T19:18:01ZmagunterrunProcess uses cwd for bad working directory argument```
When given a path to a non-existent directory,
runProcess uses the
current working directory. It should throw an exception.
mike
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ----...```
When given a path to a non-existent directory,
runProcess uses the
current working directory. It should throw an exception.
mike
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"runProcess uses cwd for bad working directory argument","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"6.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nWhen given a path to a non-existent directory,\nrunProcess uses the\ncurrent working directory. It should throw an exception.\n\n mike\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/424can't compile Y-combinator2019-07-07T19:18:01Zsakaican't compile Y-combinator```
When I try to compile the following code with GHC-6.4,
ghc takes much time and seems not to terminate.
module Fix (fix) where
newtype T a = PsiInv{ psi :: T a -> a }
fix :: (a -> a) -> a
fix f = g (PsiInv g)
where g x = f (psi...```
When I try to compile the following code with GHC-6.4,
ghc takes much time and seems not to terminate.
module Fix (fix) where
newtype T a = PsiInv{ psi :: T a -> a }
fix :: (a -> a) -> a
fix f = g (PsiInv g)
where g x = f (psi x x)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 6.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedWon'tFix |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"can't compile Y-combinator","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"ResolvedWon'tFix","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"6.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nWhen I try to compile the following code with GHC-6.4,\nghc takes much time and seems not to terminate.\n\nmodule Fix (fix) where\n\nnewtype T a = PsiInv{ psi :: T a -> a }\n\nfix :: (a -> a) -> a\nfix f = g (PsiInv g)\n where g x = f (psi x x)\n\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/425Template Haskell: reification of data types w/o constructors2023-06-27T20:54:04ZwthallerTemplate Haskell: reification of data types w/o constructors```
Reifying data types without constructors works in --make mode, but
causes an exception in TcSplice.lhs in one-shot compilation.
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| --------...```
Reifying data types without constructors works in --make mode, but
causes an exception in TcSplice.lhs in one-shot compilation.
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 6.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | Template Haskell |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Template Haskell: reification of data types w/o constructors","status":"New","operating_system":"","component":"Template Haskell","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"6.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nReifying data types without constructors works in --make mode, but \ncauses an exception in TcSplice.lhs in one-shot compilation.\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/426Runtime exception on Windows, possibly due to bit operations2019-07-07T19:18:00ZnobodyRuntime exception on Windows, possibly due to bit operations```
From david.amos@symbian.com
The attached code works fine when interpreted.
However, when compiled, it causes a runtime exception.
This appears to affect the windows distribution only.
```
<details><summary>Trac metadata</summary...```
From david.amos@symbian.com
The attached code works fine when interpreted.
However, when compiled, it causes a runtime exception.
This appears to affect the windows distribution only.
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 6.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedNoReason |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Runtime exception on Windows, possibly due to bit operations","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"ResolvedNoReason","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"6.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nFrom david.amos@symbian.com\n\nThe attached code works fine when interpreted. \nHowever, when compiled, it causes a runtime exception. \nThis appears to affect the windows distribution only.\n\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/427Random.StdGen slowness2019-07-07T19:18:00ZremitRandom.StdGen slowness```
Two (performance) problems in one:
{-# OPTIONS -fffi #-}
module Main (main) where
import Control.Monad
import Random
foreign import ccall unsafe "random" _crandom :: IO Int
randomInt :: (Int, Int) -> IO Int
randomInt (min,max) = ...```
Two (performance) problems in one:
{-# OPTIONS -fffi #-}
module Main (main) where
import Control.Monad
import Random
foreign import ccall unsafe "random" _crandom :: IO Int
randomInt :: (Int, Int) -> IO Int
randomInt (min,max) = do
n <- _crandom
return $ min + n `rem` range
where
range = max - min + 1
main = replicateM_ (5*10^6) $ do
x <- randomRIO (0::Int,1000) :: IO Int
x `seq` return ()
return ()
First, without the "seq" at the end, hardly anything is
evaluated and we're building huge amounts of thunks.
Three ideas about this one:
- Blame the user :)
- data StdGen = StdGen !Int !Int
Use strict fields in StdGen. Doesn't actually help
(at least in this example).
- Force evaluation of the StdGen in getStdRandom.
Does help in this example, but also changes behaviour
of the library:
x <- randomRIO undefined
currently dies only when x (or the result of a later
randomRIO) is evaluated. This change causes it to die
immediately.
Second, even _with_ the "seq", replacing "randomRIO" by
"randomInt" speeds the thing up with a factor of about
30. (2 to 3.6, in a "real world" university practicum
exercise of 900 lines of code)
Even given the fact that they're not really doing the
same thing, this seems rather much :(
```Edward KmettEdward Kmetthttps://gitlab.haskell.org/ghc/ghc/-/issues/428Template Haskell panic with class names2019-07-07T19:18:00ZwthallerTemplate Haskell panic with class names```
File Bug.hs:
module Bug where
foo = ''Show
Compile using:
ghc -c -fth Bug.hs
Result:
ghc-6.4.1: panic! (the `impossible' happened, GHC version 6.4.1):
lookupDeprec GHCziShow.Show{tc 2h}
Please report it as a compiler bug t...```
File Bug.hs:
module Bug where
foo = ''Show
Compile using:
ghc -c -fth Bug.hs
Result:
ghc-6.4.1: panic! (the `impossible' happened, GHC version 6.4.1):
lookupDeprec GHCziShow.Show{tc 2h}
Please report it as a compiler bug to glasgow-haskell-
bugs@haskell.org,
or http://sourceforge.net/projects/ghc/.
The panic does not happen if the type class or one of its method is
actually used in the same module.
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 6.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | Template Haskell |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Template Haskell panic with class names","status":"New","operating_system":"","component":"Template Haskell","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"simonpj"},"version":"6.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nFile Bug.hs:\nmodule Bug where\nfoo = ''Show\n\nCompile using:\nghc -c -fth Bug.hs\n\nResult:\nghc-6.4.1: panic! (the `impossible' happened, GHC version 6.4.1):\n lookupDeprec GHCziShow.Show{tc 2h}\n\nPlease report it as a compiler bug to glasgow-haskell-\nbugs@haskell.org,\nor http://sourceforge.net/projects/ghc/.\n\nThe panic does not happen if the type class or one of its method is \nactually used in the same module.\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/429when typing expression fails, don't try to Show it2019-07-07T19:18:00Zpimlottwhen typing expression fails, don't try to Show it```
Enter a ghci session, and run "print id":
Prelude> print id
Top level:
No instance for (Show (IO ()))
arising from use of `print' at Top level
Probable fix: add an instance declaration for (Show
(IO ()))
In a 'do'...```
Enter a ghci session, and run "print id":
Prelude> print id
Top level:
No instance for (Show (IO ()))
arising from use of `print' at Top level
Probable fix: add an instance declaration for (Show
(IO ()))
In a 'do' expression: print it
<interactive>:1:0:
No instance for (Show (a -> a))
arising from use of `print' at <interactive>:1:0-4
Probable fix: add an instance declaration for (Show
(a -> a))
In the definition of `it': it = print id
It would be nice to make the first error go away. It
looks as if, when typing "print id" fails, ghci
nonetheless goes ahead and tries to type "let it =
print id; print it", or something. This just creates
useless noise.
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | None |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedDuplicate |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"when typing expression fails, don't try to Show it","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"ResolvedDuplicate","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"None","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nEnter a ghci session, and run \"print id\":\n\nPrelude> print id\n\nTop level:\n No instance for (Show (IO ()))\n arising from use of `print' at Top level\n Probable fix: add an instance declaration for (Show\n(IO ()))\n In a 'do' expression: print it\n\n<interactive>:1:0:\n No instance for (Show (a -> a))\n arising from use of `print' at <interactive>:1:0-4\n Probable fix: add an instance declaration for (Show\n(a -> a))\n In the definition of `it': it = print id\n\nIt would be nice to make the first error go away. It\nlooks as if, when typing \"print id\" fails, ghci\nnonetheless goes ahead and tries to type \"let it =\nprint id; print it\", or something. This just creates\nuseless noise.\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/430Result type signatures and lexically scoped type variables2019-07-07T19:18:00ZnobodyResult type signatures and lexically scoped type variables```
Dear ghc developers,
The ghc documentation (7.4.10.) states that
"A lexically scoped type variable can be bound by:
[...] A result type signature"
However, actually trying to use them causes some
unexpected behavior:
import D...```
Dear ghc developers,
The ghc documentation (7.4.10.) states that
"A lexically scoped type variable can be bound by:
[...] A result type signature"
However, actually trying to use them causes some
unexpected behavior:
import Data.Typeable
foo :: Typeable b => b
foo :: a = typeOf (undefined :: a) `seq` (undefined :: a)
bar :: forall b. Typeable b => b
bar :: a = typeOf (undefined :: a) `seq` (undefined :: a)
baz :: forall a. Typeable a => a
baz :: a = typeOf (undefined :: a) `seq` (undefined :: a)
All three examples give rise to basically the same
error message, namely
Inferred type is less polymorphic than expected
Quantified type variable `b' is mentioned in the
environment:
Scoped type variable `a' = b (bound at:
test135.hs:4:7)
When trying to generalise the type inferred for `foo'
Signature type: forall b. (Typeable b) => b
Type to generalise: b
In the type signature for `foo'
When generalising the type(s) for `foo'
If I understand the documentation correctly, they
should all compile. An especially interesting case is
'baz', where the 'a' from the result type annotation
seems to shadow the a from the type signature (that
doesn't happen with pattern type annotations).
Another curiosity happens if we alpha-rename foo:
qux :: Typeable a => a
qux :: a = typeOf (undefined :: a) `seq` (undefined :: a)
The error message becomes
All of the type variables in the constraint
`Typeable a' are already in scope
(at least one must be universally quantified here)
In the type signature: qux :: (Typeable a) => a
This is just my wild speculation, but does this really
mean that the 'a' in qux's signature is bound by "qux
:: a"?
ghc6.2 gives the same error messages, where of course
'bar' behaves like 'foo' and 'baz' like 'qux'.
Thanks you,
-- Thomas Jäger
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | None |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedInvalid |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Result type signatures and lexically scoped type variables","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"ResolvedInvalid","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"None","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nDear ghc developers,\n\nThe ghc documentation (7.4.10.) states that\n \"A lexically scoped type variable can be bound by: \n [...] A result type signature\"\n\nHowever, actually trying to use them causes some\nunexpected behavior:\n\nimport Data.Typeable\n\nfoo :: Typeable b => b\nfoo :: a = typeOf (undefined :: a) `seq` (undefined :: a)\n\nbar :: forall b. Typeable b => b\nbar :: a = typeOf (undefined :: a) `seq` (undefined :: a)\n \nbaz :: forall a. Typeable a => a\nbaz :: a = typeOf (undefined :: a) `seq` (undefined :: a)\n\nAll three examples give rise to basically the same\nerror message, namely\n\n Inferred type is less polymorphic than expected\n Quantified type variable `b' is mentioned in the\nenvironment:\n Scoped type variable `a' = b (bound at:\ntest135.hs:4:7)\n When trying to generalise the type inferred for `foo'\n Signature type: forall b. (Typeable b) => b\n Type to generalise: b\n In the type signature for `foo'\n When generalising the type(s) for `foo'\n\nIf I understand the documentation correctly, they\nshould all compile. An especially interesting case is\n'baz', where the 'a' from the result type annotation\nseems to shadow the a from the type signature (that\ndoesn't happen with pattern type annotations).\n\nAnother curiosity happens if we alpha-rename foo:\n\nqux :: Typeable a => a\nqux :: a = typeOf (undefined :: a) `seq` (undefined :: a)\n\nThe error message becomes\n\n All of the type variables in the constraint\n`Typeable a' are already in scope\n (at least one must be universally quantified here)\n In the type signature: qux :: (Typeable a) => a\n\nThis is just my wild speculation, but does this really\nmean that the 'a' in qux's signature is bound by \"qux\n:: a\"?\n\nghc6.2 gives the same error messages, where of course\n'bar' behaves like 'foo' and 'baz' like 'qux'.\n\nThanks you,\n\n-- Thomas Jäger\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/431runInteractiveProcess and closed stdin.2019-07-07T19:17:59ZnobodyrunInteractiveProcess and closed stdin.```
Hello,
The System.Process.runInteractiveProcess function
doesn't seem to provide the child process with a stdin
handle when the parent's stdin is closed. Below is a
small example:
import System.Process
import Control.Concurrent
imp...```
Hello,
The System.Process.runInteractiveProcess function
doesn't seem to provide the child process with a stdin
handle when the parent's stdin is closed. Below is a
small example:
import System.Process
import Control.Concurrent
import System.IO
main = do
hClose stdin -- everything works as expected if the
handle isn't closed.
putStrLn "Running cat ..."
(inp, out, err, pid) <- runInteractiveProcess "cat"
[] Nothing Nothing
forkIO (hPutStrLn inp "foo" >> hClose inp)
forkIO (putStrLn =<< hGetContents out)
forkIO (putStrLn =<< hGetContents err)
-- Don't want to deal with waitForProcess and
-threaded right now.
threadDelay 1000000
return ()
Running this example produces the error
% ghc Run.hs -o run
% ./run
Running cat ...
cat: -: Bad file descriptor
cat: closing standard input: Bad file descriptor
I think the bug is in
fptools/libraries/base/cbits/runProcess.c:
//...
pipe(fdStdInput);
//...
dup2 (fdStdInput[0], STDIN_FILENO);
/...
close(fdStdInput[0]);
//...
pipe(...) will assign the lowest available file
descriptors, i.e. 0 if stdin is closed. The dup2 won't
do anything, since src and dest fds are identical, so
close(...) will close the child's stdin immediately.
% uname -a
Linux mthomas 2.6.12 #2 Thu Jul 21 07:51:44 EDT 2005
i686 GNU/Linux
% ghc --version
The Glorious Glasgow Haskell Compilation System,
version 6.5.20050728
Thanks,
-- Thomas Jäger
```https://gitlab.haskell.org/ghc/ghc/-/issues/432runhaskell causes GHC to segfault on OS X2019-07-07T19:17:59Znobodyrunhaskell causes GHC to segfault on OS X```
Attempting to use runhaskell to build a caballized
package on OS X
causes ghc to segfault.
The user sees:
crossroads-able> cd harp
crossroads-able> runhaskell Setup.hs configure
Warning: No license-file field.
Configuring harp-0.2...```
Attempting to use runhaskell to build a caballized
package on OS X
causes ghc to segfault.
The user sees:
crossroads-able> cd harp
crossroads-able> runhaskell Setup.hs configure
Warning: No license-file field.
Configuring harp-0.2...
configure: searching for ghc in path.
configure: found ghc at /opt/local/bin/ghc
runhaskell: waitForProcess: interrupted (Interrupted
system call)
(this is from the build of harp, part of the
haskell-src-exts pacakge,
but the same behavior was observed every time I tried
to use
runhaskell, including trying to caballize a build on a
small app
that I wrote. The application built successfully under
cabal on
FreeBSD-5.4 x86 with ghc-6.4.)
Attached are a crash log (ghccrash.log) and a ktrace
log (ktrace.log).
Superficially, it looks like a bad ioctl might trigger
the crash.
I'd apprecaite any hints on where to poke around in the
source
to track this down.
Thanks.
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 6.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | None |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"runhaskell causes GHC to segfault on OS X","status":"New","operating_system":"","component":"None","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"6.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nAttempting to use runhaskell to build a caballized\npackage on OS X\ncauses ghc to segfault.\n\nThe user sees:\n\ncrossroads-able> cd harp \ncrossroads-able> runhaskell Setup.hs configure\nWarning: No license-file field.\nConfiguring harp-0.2...\nconfigure: searching for ghc in path.\nconfigure: found ghc at /opt/local/bin/ghc\nrunhaskell: waitForProcess: interrupted (Interrupted\nsystem call)\n\n(this is from the build of harp, part of the\nhaskell-src-exts pacakge,\nbut the same behavior was observed every time I tried\nto use\nrunhaskell, including trying to caballize a build on a\nsmall app\nthat I wrote. The application built successfully under\ncabal on\nFreeBSD-5.4 x86 with ghc-6.4.)\n\nAttached are a crash log (ghccrash.log) and a ktrace\nlog (ktrace.log).\nSuperficially, it looks like a bad ioctl might trigger\nthe crash.\n\nI'd apprecaite any hints on where to poke around in the\nsource\nto track this down.\n\nThanks.\n\n\n\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/433ghc-6.4.1.20050801: panic!2023-09-20T14:47:58Zggdghc-6.4.1.20050801: panic!```
Hi!
I've pulled the latest Yi code from the darcs
repository and tried to compile it with 'make
way=static' using ghc-6.4.1.20050801 compiler.
Here is the result:
[...]
ghc -Wall -Werror -Icbits -Imk -funbox-s...```
Hi!
I've pulled the latest Yi code from the darcs
repository and tried to compile it with 'make
way=static' using ghc-6.4.1.20050801 compiler.
Here is the result:
[...]
ghc -Wall -Werror -Icbits -Imk -funbox-strict-fields
-O2 -fasm -threaded -package-conf yi.conf
-package yi -i -Icbits -Imk -c Yi.hs -o Yi.o -ohi Yi.hi
ghc -Wall -Werror -Icbits -Imk -funbox-strict-fields
-O2 -fasm -threaded -package-conf yi.conf
-package yi -c Main.hs -o Main.o -ohi Main.hi
./Yi.hi :
Interface file inconsistency:
home-package module `Yi.Editor' is mentioned,
but does not appear in the dependencies of the
interface
ghc-6.4.1.20050801: panic! (the `impossible'
happened, GHC version 6.4.1.20050801):
forkM Declaration for staticzumain{v}
Please report it as a compiler bug to
glasgow-haskell-bugs@haskell.org,
or http://sourceforge.net/projects/ghc/.
Sincerely,
Gour
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | None |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedNoReason |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghc-6.4.1.20050801: panic!","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"ResolvedNoReason","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"None","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nHi! \n \nI've pulled the latest Yi code from the darcs \nrepository and tried to compile it with 'make \nway=static' using ghc-6.4.1.20050801 compiler. \n \nHere is the result: \n \n[...] \nghc -Wall -Werror -Icbits -Imk -funbox-strict-fields \n-O2 -fasm -threaded -package-conf yi.conf \n-package yi -i -Icbits -Imk -c Yi.hs -o Yi.o -ohi Yi.hi \nghc -Wall -Werror -Icbits -Imk -funbox-strict-fields \n-O2 -fasm -threaded -package-conf yi.conf \n-package yi -c Main.hs -o Main.o -ohi Main.hi \n./Yi.hi : \n Interface file inconsistency: \n home-package module `Yi.Editor' is mentioned, \n but does not appear in the dependencies of the \ninterface \nghc-6.4.1.20050801: panic! (the `impossible' \nhappened, GHC version 6.4.1.20050801): \n forkM Declaration for staticzumain{v} \n \nPlease report it as a compiler bug to \nglasgow-haskell-bugs@haskell.org, \nor http://sourceforge.net/projects/ghc/. \n \n \nSincerely, \nGour \n \n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/434panic compiling classes2019-07-07T19:17:58Zabrimpanic compiling classes```
$ ghc Bug.hs
ghc-6.4: panic! (the `impossible' happened, GHC version
6.4):
ds_app_type Bug.Class1{tc r155} []
$ cat Bug.hs
module Bug where
class Class1 a where
class Class2 a where
class1 :: a -> Class1
```
<details>...```
$ ghc Bug.hs
ghc-6.4: panic! (the `impossible' happened, GHC version
6.4):
ds_app_type Bug.Class1{tc r155} []
$ cat Bug.hs
module Bug where
class Class1 a where
class Class2 a where
class1 :: a -> Class1
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 6.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"panic compiling classes","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"6.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\n$ ghc Bug.hs\nghc-6.4: panic! (the `impossible' happened, GHC version\n6.4):\n ds_app_type Bug.Class1{tc r155} []\n\n$ cat Bug.hs\nmodule Bug where\n\nclass Class1 a where\n\nclass Class2 a where\n class1 :: a -> Class1\n\n\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/435haddock doesn't like records2022-05-03T09:14:26Zas49haddock doesn't like records```
haddock fails with
~/current/sources/analyzer:$ haddock RecDemo.hs
Warning: RecDemo: the following names could not be
resolved:
Int Bool
Fail: Main.extractRecSel: unexpected (con)declHsConDecl
(SrcLoc 4 13) Foo [] [] [] Nothing...```
haddock fails with
~/current/sources/analyzer:$ haddock RecDemo.hs
Warning: RecDemo: the following names could not be
resolved:
Int Bool
Fail: Main.extractRecSel: unexpected (con)declHsConDecl
(SrcLoc 4 13) Foo [] [] [] Nothing
if a file contains (a) a record constructor with some
field selector elem1, (b) another, non-record
constructor (c) the data type is exported with only the
non-record constructor, (d) the selector elem1 is exported.
Example attached,
Axel.
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 6.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"haddock doesn't like records","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"6.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nhaddock fails with\n\n~/current/sources/analyzer:$ haddock RecDemo.hs\nWarning: RecDemo: the following names could not be\nresolved:\n Int Bool\n\nFail: Main.extractRecSel: unexpected (con)declHsConDecl\n(SrcLoc 4 13) Foo [] [] [] Nothing\n\nif a file contains (a) a record constructor with some\nfield selector elem1, (b) another, non-record\nconstructor (c) the data type is exported with only the\nnon-record constructor, (d) the selector elem1 is exported.\n\nExample attached,\nAxel.\n\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/436Declare large amounts of constant data2019-07-07T19:17:58ZajkDeclare large amounts of constant data```
Simon Marlow wrote in Bug#635718:
"It is true that GHC doesn't have a good way to declare
large amounts of constant data. This is a shortcoming,
but not a bug (please by all means submit a feature
request)."
Submitting as requested...```
Simon Marlow wrote in Bug#635718:
"It is true that GHC doesn't have a good way to declare
large amounts of constant data. This is a shortcoming,
but not a bug (please by all means submit a feature
request)."
Submitting as requested:)
```https://gitlab.haskell.org/ghc/ghc/-/issues/437Recompilation check should include flags2019-07-07T19:17:58ZSimon Peyton JonesRecompilation check should include flags```
GHC skips recompilation of a module if the module code
hasn't changed, even if the flags in use *have* changed.
A benign version is that switching on -O won't recompile
modules that were compiled without -O. But here's a
nastie...```
GHC skips recompilation of a module if the module code
hasn't changed, even if the flags in use *have* changed.
A benign version is that switching on -O won't recompile
modules that were compiled without -O. But here's a
nastier version: changing the -main-is flag can lead to an
obscure link error. Details below supplied by Niels
[cpjvelde@cs.uu.nl]
Simon
Actually, i reproduced it now and the reason is a bit
different. I have an
application Test and Test2. They both have a main
function. Test imports Test2
for some other function. So this is how those files look
like:
~/pancake > cat Test.hs
module Test where
import Test2 hiding (main)
main = doit
~/pancake > cat Test2.hs
module Test2 where
doit = print "Test2.doit"
main = print "Test2.main"
I then first compile the first app:
~/pancake > ghc --make -main-is Test.main Test.hs
Chasing modules from: Test.hs
Compiling Test2 ( ./Test2.hs, ./Test2.o )
Compiling Test ( Test.hs, Test.o )
Linking ...
then i compile the second app:
~/pancake > ghc --make -main-is Test2.main Test2.hs
Chasing modules from: Test2.hs
Skipping Test2 ( Test2.hs, Test2.o )
Linking ...
/usr/lib/ghc-6.4/libHSrts.a(Main.o)(.text+0xe): In function
`main':
: undefined reference to `__stginit_ZCMain'
/usr/lib/ghc-6.4/libHSrts.a(Main.o)(.text+0x28): In
function `main':
: undefined reference to `ZCMain_main_closure'
collect2: ld returned 1 exit status
So I guess generating Test2.o the first time and using -
main-is renamed the main
in Test2.o . Since it is not recompiled when I want to
compile the second app,
it fails because it cant find the main...I thought providing
a -main-is flag
again when compiling the second app would somehow
force recompilation of Test2.o
or at least fixing the 'renaming' that the first compilation
of Test2.o had
caused.
greetings, Niels.
```7.4.1dtereidtereihttps://gitlab.haskell.org/ghc/ghc/-/issues/438Recompilation check should include flags2022-05-03T09:14:27ZSimon Peyton JonesRecompilation check should include flags```
GHC skips recompilation of a module if the module code
hasn't changed, even if the flags in use *have* changed.
A benign version is that switching on -O won't recompile
modules that were compiled without -O. But here's a
nastie...```
GHC skips recompilation of a module if the module code
hasn't changed, even if the flags in use *have* changed.
A benign version is that switching on -O won't recompile
modules that were compiled without -O. But here's a
nastier version: changing the -main-is flag can lead to an
obscure link error. Details below supplied by Niels
[cpjvelde@cs.uu.nl]
Simon
Actually, i reproduced it now and the reason is a bit
different. I have an
application Test and Test2. They both have a main
function. Test imports Test2
for some other function. So this is how those files look
like:
~/pancake > cat Test.hs
module Test where
import Test2 hiding (main)
main = doit
~/pancake > cat Test2.hs
module Test2 where
doit = print "Test2.doit"
main = print "Test2.main"
I then first compile the first app:
~/pancake > ghc --make -main-is Test.main Test.hs
Chasing modules from: Test.hs
Compiling Test2 ( ./Test2.hs, ./Test2.o )
Compiling Test ( Test.hs, Test.o )
Linking ...
then i compile the second app:
~/pancake > ghc --make -main-is Test2.main Test2.hs
Chasing modules from: Test2.hs
Skipping Test2 ( Test2.hs, Test2.o )
Linking ...
/usr/lib/ghc-6.4/libHSrts.a(Main.o)(.text+0xe): In function
`main':
: undefined reference to `__stginit_ZCMain'
/usr/lib/ghc-6.4/libHSrts.a(Main.o)(.text+0x28): In
function `main':
: undefined reference to `ZCMain_main_closure'
collect2: ld returned 1 exit status
So I guess generating Test2.o the first time and using -
main-is renamed the main
in Test2.o . Since it is not recompiled when I want to
compile the second app,
it fails because it cant find the main...I thought providing
a -main-is flag
again when compiling the second app would somehow
force recompilation of Test2.o
or at least fixing the 'renaming' that the first compilation
of Test2.o had
caused.
greetings, Niels.
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | None |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | ResolvedDuplicate |
| Component | None |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Recompilation check should include flags","status":"New","operating_system":"","component":"None","related":[],"milestone":"","resolution":"ResolvedDuplicate","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"None","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nGHC skips recompilation of a module if the module code \nhasn't changed, even if the flags in use *have* changed. \nA benign version is that switching on -O won't recompile \nmodules that were compiled without -O. But here's a \nnastier version: changing the -main-is flag can lead to an \nobscure link error. Details below supplied by Niels \n[cpjvelde@cs.uu.nl]\n\nSimon\n\nActually, i reproduced it now and the reason is a bit \ndifferent. I have an\napplication Test and Test2. They both have a main \nfunction. Test imports Test2\nfor some other function. So this is how those files look \nlike:\n\n~/pancake > cat Test.hs\nmodule Test where\nimport Test2 hiding (main)\n\nmain = doit\n\n~/pancake > cat Test2.hs\nmodule Test2 where\n\ndoit = print \"Test2.doit\"\nmain = print \"Test2.main\"\n\nI then first compile the first app:\n~/pancake > ghc --make -main-is Test.main Test.hs\nChasing modules from: Test.hs\nCompiling Test2 ( ./Test2.hs, ./Test2.o )\nCompiling Test ( Test.hs, Test.o )\nLinking ...\n\nthen i compile the second app:\n~/pancake > ghc --make -main-is Test2.main Test2.hs\nChasing modules from: Test2.hs\nSkipping Test2 ( Test2.hs, Test2.o )\nLinking ...\n/usr/lib/ghc-6.4/libHSrts.a(Main.o)(.text+0xe): In function \n`main':\n: undefined reference to `__stginit_ZCMain'\n/usr/lib/ghc-6.4/libHSrts.a(Main.o)(.text+0x28): In \nfunction `main':\n: undefined reference to `ZCMain_main_closure'\ncollect2: ld returned 1 exit status\n\nSo I guess generating Test2.o the first time and using -\nmain-is renamed the main\nin Test2.o . Since it is not recompiled when I want to \ncompile the second app,\nit fails because it cant find the main...I thought providing \na -main-is flag\nagain when compiling the second app would somehow \nforce recompilation of Test2.o\nor at least fixing the 'renaming' that the first compilation \nof Test2.o had \ncaused.\n\ngreetings, Niels.\n\n\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/439panic when interpreting compiled stuff2020-10-24T15:57:57Zisaacdupreepanic when interpreting compiled stuff```
I am using the Linux/ppc ghc 6.4 binary found on the
ghc downloads page. I'm assuming it supports ghci,
since ghci seems to work for other things.
The simplest way to trigger it is this (or the equivalent):
echo 'main=return()' > bu...```
I am using the Linux/ppc ghc 6.4 binary found on the
ghc downloads page. I'm assuming it supports ghci,
since ghci seems to work for other things.
The simplest way to trigger it is this (or the equivalent):
echo 'main=return()' > bug.hs && ghc bug.hs && ghci bug.hs
, and enter `main' at the ghci prompt. It yields:
<interactive>: Unable to mmap( MAP_FIXED ) for Jump Islands
ghc-6.4: panic! (the `impossible' happened, GHC version
6.4):
loadObj: failed
Please report it as a compiler bug to
glasgow-haskell-bugs@haskell.org,
or http://sourceforge.net/projects/ghc/.
Oddly, entering `main' again at the next ghci prompt
yields a different mesage and exits ghci:
<interactive>: internal error: Unable to make
ppcJumpIsland for #11
Please report this as a bug to
glasgow-haskell-bugs@haskell.org,
or http://www.sourceforge.net/projects/ghc/
I came across this when doing `ghci -package wx', which
after some ordinary output printed:
Loading package haskell98-1.0 ... ghc-6.4: Unable to
mmap( MAP_FIXED ) for Jump Islands
(followed by the rest of the error messages in my first
output listing.)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 6.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedNoReason |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"panic when interpreting compiled stuff","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"ResolvedNoReason","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"6.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nI am using the Linux/ppc ghc 6.4 binary found on the\nghc downloads page. I'm assuming it supports ghci,\nsince ghci seems to work for other things.\n\nThe simplest way to trigger it is this (or the equivalent):\necho 'main=return()' > bug.hs && ghc bug.hs && ghci bug.hs\n, and enter `main' at the ghci prompt. It yields:\n<interactive>: Unable to mmap( MAP_FIXED ) for Jump Islands\n\nghc-6.4: panic! (the `impossible' happened, GHC version\n6.4):\n loadObj: failed\n\nPlease report it as a compiler bug to\nglasgow-haskell-bugs@haskell.org,\nor http://sourceforge.net/projects/ghc/.\n\n\nOddly, entering `main' again at the next ghci prompt\nyields a different mesage and exits ghci:\n<interactive>: internal error: Unable to make\nppcJumpIsland for #11\n Please report this as a bug to\nglasgow-haskell-bugs@haskell.org,\n or http://www.sourceforge.net/projects/ghc/\n\n\nI came across this when doing `ghci -package wx', which\nafter some ordinary output printed:\nLoading package haskell98-1.0 ... ghc-6.4: Unable to\nmmap( MAP_FIXED ) for Jump Islands\n(followed by the rest of the error messages in my first\noutput listing.)\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/440parse error way too late2019-07-07T19:17:57Zas49parse error way too late```
On the attached file the compiler reports
typeerror.hs:29: parse error (possibly incorrect
indentation)
where line no 29 is the type signature of the second
function (lookup). I thought ghc was off by one line
and looked desperatel...```
On the attached file the compiler reports
typeerror.hs:29: parse error (possibly incorrect
indentation)
where line no 29 is the type signature of the second
function (lookup). I thought ghc was off by one line
and looked desperately at line 30 (which was stupid
since ghc's line numbers are only too far down, never
early). The solution is that I missed the equal sign in
the first function. I report this since I'm puzzled by
the fact that ghc got all the way down to the next type
signature before the parser found an error.
Axel.
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedNoReason |
| Component | Compiler (Parser) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"parse error way too late","status":"New","operating_system":"","component":"Compiler (Parser)","related":[],"milestone":"","resolution":"ResolvedNoReason","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"6.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nOn the attached file the compiler reports\n\ntypeerror.hs:29: parse error (possibly incorrect\nindentation)\n\nwhere line no 29 is the type signature of the second\nfunction (lookup). I thought ghc was off by one line\nand looked desperately at line 30 (which was stupid\nsince ghc's line numbers are only too far down, never\nearly). The solution is that I missed the equal sign in\nthe first function. I report this since I'm puzzled by\nthe fact that ghc got all the way down to the next type\nsignature before the parser found an error.\n\nAxel.\n\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/441GHCi doesn't run computations in a new thread2019-07-07T19:17:57ZdonsGHCi doesn't run computations in a new thread```
A broken QuickCheck property cause ghci to panic after
reloading the module. Seen in stable and head branch.
paprika$ ghci T.hs
*Main> do_test
test : *
(0)
*Main> :reload
ghc-6.5: ...```
A broken QuickCheck property cause ghci to panic after
reloading the module. Seen in stable and head branch.
paprika$ ghci T.hs
*Main> do_test
test : *
(0)
*Main> :reload
ghc-6.5: panic! (the `impossible' happened, GHC version
6.5):
<<loop>>
Please report it as a compiler bug to
glasgow-haskell-bugs@haskell.org,
or http://sourceforge.net/projects/ghc/.
Changing the property to check for empty lists causes
the test to pass, and reload to work fine.
-- Don Stewart
```6.4.2Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/442configure problems with openGL and openAL2019-07-07T19:17:57Znobodyconfigure problems with openGL and openAL```
I've been compiling the latest GHC snapshot
(6.4.1.20050827) from source and have encountered some
annoying problems with the configure script not being
as intelligent as it should be. This is on a GNU/Linux
system running Debian un...```
I've been compiling the latest GHC snapshot
(6.4.1.20050827) from source and have encountered some
annoying problems with the configure script not being
as intelligent as it should be. This is on a GNU/Linux
system running Debian unstable. Initially I didn't
have the openGL GLU headers installed so I got a
compile error when the "glu.h" file wasn't found. I
believe that since the GLU library was installed, the
configure script assumed that the GLU header file would
be there -- or else it didn't check. Installing the
GLU header files fixed this. Then I got a weird bug
while compiling the openAL support in GHC:
------------------------------------------------------------------------
==fptools== make all - --no-print-directory -r;
in
/home/mvanier/lang/useful/haskell/ghc/ghc-6.4.1.20050827/libraries/OpenAL
------------------------------------------------------------------------
rm -f Sound/OpenAL/ALC/Context.o; if [ ! -d
Sound/OpenAL/ALC/Context_split ]; then mkdir Sound/OpenAL
/ALC/Context_split; else /usr/bin/find
Sound/OpenAL/ALC/Context_split -name '*.o' -print |
xargs rm -
f __rm_food; fi;
../../ghc/compiler/ghc-inplace -H16m -O -Wall -fffi
-Iinclude '-#include "HsOpenAL.h"' -cpp -DCALLCON
V=ccall -ignore-package OpenAL -O -Rghc-timing
-fgenerics -package base -package OpenGL -fgenerics
-split-objs -c Sound/OpenAL/ALC/Context.hs -o
Sound/OpenAL/ALC/Context.o -ohi Sound/OpenAL/ALC/Co
ntext.hi
/tmp/ghc27232.hc: In function 's33v_ret':
/tmp/ghc27232.hc:553: error: void value not ignored as
it ought to be
/tmp/ghc27232.hc: In function 's33y_ret':
/tmp/ghc27232.hc:595: error: void value not ignored as
it ought to be
<<ghc: 60654736 bytes, 14 GCs, 2844362/5655392 avg/max
bytes residency (3 samples), 18M in use, 0.00
INIT (0.00 elapsed), 0.18 MUT (0.40 elapsed), 0.09 GC
(0.12 elapsed) :ghc>>
make[2]: *** [Sound/OpenAL/ALC/Context.o] Error 1
make[1]: *** [all] Error 1
make: *** [build] Error 1
As a result, I disabled openAL support.
Mike Vanier
mvanier@cs.caltech.edu
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | None |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedWon'tFix |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"configure problems with openGL and openAL","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"ResolvedWon'tFix","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"None","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nI've been compiling the latest GHC snapshot\n(6.4.1.20050827) from source and have encountered some\nannoying problems with the configure script not being\nas intelligent as it should be. This is on a GNU/Linux\nsystem running Debian unstable. Initially I didn't\nhave the openGL GLU headers installed so I got a\ncompile error when the \"glu.h\" file wasn't found. I\nbelieve that since the GLU library was installed, the\nconfigure script assumed that the GLU header file would\nbe there -- or else it didn't check. Installing the\nGLU header files fixed this. Then I got a weird bug\nwhile compiling the openAL support in GHC:\n\n------------------------------------------------------------------------\n==fptools== make all - --no-print-directory -r;\n in\n/home/mvanier/lang/useful/haskell/ghc/ghc-6.4.1.20050827/libraries/OpenAL\n------------------------------------------------------------------------\nrm -f Sound/OpenAL/ALC/Context.o; if [ ! -d\nSound/OpenAL/ALC/Context_split ]; then mkdir Sound/OpenAL\n/ALC/Context_split; else /usr/bin/find\nSound/OpenAL/ALC/Context_split -name '*.o' -print |\nxargs rm -\nf __rm_food; fi; \n../../ghc/compiler/ghc-inplace -H16m -O -Wall -fffi\n-Iinclude '-#include \"HsOpenAL.h\"' -cpp -DCALLCON\nV=ccall -ignore-package OpenAL -O -Rghc-timing\n-fgenerics -package base -package OpenGL -fgenerics \n-split-objs -c Sound/OpenAL/ALC/Context.hs -o\nSound/OpenAL/ALC/Context.o -ohi Sound/OpenAL/ALC/Co\nntext.hi\n/tmp/ghc27232.hc: In function 's33v_ret':\n/tmp/ghc27232.hc:553: error: void value not ignored as\nit ought to be\n/tmp/ghc27232.hc: In function 's33y_ret':\n/tmp/ghc27232.hc:595: error: void value not ignored as\nit ought to be\n<<ghc: 60654736 bytes, 14 GCs, 2844362/5655392 avg/max\nbytes residency (3 samples), 18M in use, 0.00 \nINIT (0.00 elapsed), 0.18 MUT (0.40 elapsed), 0.09 GC\n(0.12 elapsed) :ghc>>\nmake[2]: *** [Sound/OpenAL/ALC/Context.o] Error 1\nmake[1]: *** [all] Error 1\nmake: *** [build] Error 1\n\nAs a result, I disabled openAL support.\n\nMike Vanier\nmvanier@cs.caltech.edu\n\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/443Unify.unifyTauTyLists: mismatched type lists!2019-07-07T19:17:56ZnobodyUnify.unifyTauTyLists: mismatched type lists!```
the following simple code
-------------------------
data List elem = Cons elem List | Nil
t1 :: List
t1 = Cons 1 Nil
-------------------------
causes (loaded within ghci):
ghc-6.4: panic! (the `impossible' happened, GHC version...```
the following simple code
-------------------------
data List elem = Cons elem List | Nil
t1 :: List
t1 = Cons 1 Nil
-------------------------
causes (loaded within ghci):
ghc-6.4: panic! (the `impossible' happened, GHC version
6.4):
Unify.unifyTauTyLists: mismatched type lists!
Please report it as a compiler bug to
glasgow-haskell-bugs@haskell.org,
or http://sourceforge.net/projects/ghc/.
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 6.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Unify.unifyTauTyLists: mismatched type lists!","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"6.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nthe following simple code\n\n-------------------------\ndata List elem = Cons elem List | Nil\n\nt1 :: List\nt1 = Cons 1 Nil\n-------------------------\n\ncauses (loaded within ghci):\n\n\nghc-6.4: panic! (the `impossible' happened, GHC version\n6.4):\n\tUnify.unifyTauTyLists: mismatched type lists!\n\nPlease report it as a compiler bug to\nglasgow-haskell-bugs@haskell.org,\nor http://sourceforge.net/projects/ghc/.\n\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/444panic with bad data/class definition.2019-07-07T19:17:56Znobodypanic with bad data/class definition.```
This malformed program causes a panic in ghc-6.4
class SClass a where
sFun :: a -> SData
data SData
= SCon SClass
email: Ben.Lippmeier@anu.edu.au
```
<details><summary>Trac metadata</summary>
| Trac field | Value ...```
This malformed program causes a panic in ghc-6.4
class SClass a where
sFun :: a -> SData
data SData
= SCon SClass
email: Ben.Lippmeier@anu.edu.au
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"panic with bad data/class definition.","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"6.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\n\nThis malformed program causes a panic in ghc-6.4\n\nclass SClass a where\n sFun :: a -> SData\n \ndata SData\n\t= SCon SClass\n\nemail: Ben.Lippmeier@anu.edu.au\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/445panic! mkWWcpr: not a product2019-07-07T19:17:56Znobodypanic! mkWWcpr: not a product```
I encountered the following bug:
ghc-6.4: panic! (the `impossible' happened, GHC version
6.4):
mkWWcpr: not a product SPIRziSPIR.SPIR{tc r3jI}
Please report it as a compiler bug to
glasgow-haskell-bugs@haskell.org,
or http:...```
I encountered the following bug:
ghc-6.4: panic! (the `impossible' happened, GHC version
6.4):
mkWWcpr: not a product SPIRziSPIR.SPIR{tc r3jI}
Please report it as a compiler bug to
glasgow-haskell-bugs@haskell.org,
or http://sourceforge.net/projects/ghc/.
This was in conjunction with the use of .hs-boot files
for recursive modules, though I don't know for sure if that
actually caused the problem.
Unfortunate I can't provide a simple reproducible test case
at this point, but I thought I'd let you know about the
bug anyway.
Fergus Henderson <fjh-mailbox-30@galois.com>
```6.8.1Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/446ghc is confused about instances of Ord2019-07-07T19:17:56Zgreenrdghc is confused about instances of Ord```
When I compile the attached file _without_ -fallow-incoherent-instances
on ghc 6.4 on Fedora Core Linux, I receive the following errors:
PartialOrder.hs:19:0:
Overlapping instances for PartialOrder a
arising from the ...```
When I compile the attached file _without_ -fallow-incoherent-instances
on ghc 6.4 on Fedora Core Linux, I receive the following errors:
PartialOrder.hs:19:0:
Overlapping instances for PartialOrder a
arising from the superclasses of an instance declaration at
PartialOrder.hs:19:0
Matching instances:
PartialOrder.hs:11:0: instance (Ord a) => PartialOrder a
PartialOrder.hs:19:0: instance PartialOrder (LineList a)
(The choice depends on the instantiation of `a'
Use -fallow-incoherent-instances to use the first choice above)
In the instance declaration for `PartialOrder (LineList a)'
PartialOrder.hs:20:53:
Overlapping instances for PartialOrder a
arising from use of `lte' at PartialOrder.hs:20:53-55
Matching instances:
PartialOrder.hs:11:0: instance (Ord a) => PartialOrder a
PartialOrder.hs:19:0: instance PartialOrder (LineList a)
(The choice depends on the instantiation of `a'
Use -fallow-incoherent-instances to use the first choice above)
In the first argument of `zipWith', namely `lte'
In the first argument of `and', namely `(zipWith lte c d)'
In the definition of `lte':
lte (LineList c) (LineList d) = and (zipWith lte c d)
However, when I compile it _with_ -fallow-incoherent-instances, I
receive _these_ errors:
PartialOrder.hs:19:0:
No instance for (Ord a)
arising from the superclasses of an instance declaration at
PartialOrder.hs:19:0
Probable fix: add (Ord a) to the instance declaration superclass
context
In the instance declaration for `PartialOrder (LineList a)'
PartialOrder.hs:20:53:
Could not deduce (Ord a)
from the context (PartialOrder (LineList a), Eq (LineList a))
arising from use of `lte' at PartialOrder.hs:20:53-55
Probable fix: add (Ord a) to the class or instance method `lte'
In the first argument of `zipWith', namely `lte'
In the first argument of `and', namely `(zipWith lte c d)'
In the definition of `lte':
lte (LineList c) (LineList d) = and (zipWith lte c d)
So in the _first_ compilation run, ghc is suggesting that an instance of
Ord a (which I believe is a figment of its imagination) collides; but in the
_second_ compilation run, it complains that it can't _find_ the instance for
Ord a. Surely an inconsistency.
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedInvalid |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghc is confused about instances of Ord","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"ResolvedInvalid","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"6.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nWhen I compile the attached file _without_ -fallow-incoherent-instances \non ghc 6.4 on Fedora Core Linux, I receive the following errors: \n \nPartialOrder.hs:19:0: \n Overlapping instances for PartialOrder a \n arising from the superclasses of an instance declaration at \nPartialOrder.hs:19:0 \n Matching instances: \n PartialOrder.hs:11:0: instance (Ord a) => PartialOrder a \n PartialOrder.hs:19:0: instance PartialOrder (LineList a) \n (The choice depends on the instantiation of `a' \n Use -fallow-incoherent-instances to use the first choice above) \n In the instance declaration for `PartialOrder (LineList a)' \n \nPartialOrder.hs:20:53: \n Overlapping instances for PartialOrder a \n arising from use of `lte' at PartialOrder.hs:20:53-55 \n Matching instances: \n PartialOrder.hs:11:0: instance (Ord a) => PartialOrder a \n PartialOrder.hs:19:0: instance PartialOrder (LineList a) \n (The choice depends on the instantiation of `a' \n Use -fallow-incoherent-instances to use the first choice above) \n In the first argument of `zipWith', namely `lte' \n In the first argument of `and', namely `(zipWith lte c d)' \n In the definition of `lte': \n lte (LineList c) (LineList d) = and (zipWith lte c d) \n \nHowever, when I compile it _with_ -fallow-incoherent-instances, I \nreceive _these_ errors: \n \nPartialOrder.hs:19:0: \n No instance for (Ord a) \n arising from the superclasses of an instance declaration at \nPartialOrder.hs:19:0 \n Probable fix: add (Ord a) to the instance declaration superclass \ncontext \n In the instance declaration for `PartialOrder (LineList a)' \n \nPartialOrder.hs:20:53: \n Could not deduce (Ord a) \n from the context (PartialOrder (LineList a), Eq (LineList a)) \n arising from use of `lte' at PartialOrder.hs:20:53-55 \n Probable fix: add (Ord a) to the class or instance method `lte' \n In the first argument of `zipWith', namely `lte' \n In the first argument of `and', namely `(zipWith lte c d)' \n In the definition of `lte': \n lte (LineList c) (LineList d) = and (zipWith lte c d) \n \nSo in the _first_ compilation run, ghc is suggesting that an instance of \nOrd a (which I believe is a figment of its imagination) collides; but in the \n_second_ compilation run, it complains that it can't _find_ the instance for \nOrd a. Surely an inconsistency. \n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/447segmentation fault when profiling large case2019-07-07T19:17:56Znobodysegmentation fault when profiling large case```
If the attached file is compiled with -prof -auto-all,
the binary produced will segfault (even if RTS
profiling options are not present). This seems to be
caused by a combination of a case statement with a
large number of branches a...```
If the attached file is compiled with -prof -auto-all,
the binary produced will segfault (even if RTS
profiling options are not present). This seems to be
caused by a combination of a case statement with a
large number of branches and a relatively complex value
at the end of each branch - reducing the number of
branches by one or changing any of the data
declarations to newtypes eliminates the segfault.
```6.4.2Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/448compiler panic2023-09-11T21:09:58Znobodycompiler panic```
I played with cyclic lists in GHCI.
My session looked like:
% ghci
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | |...```
I played with cyclic lists in GHCI.
My session looked like:
% ghci
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version
6.4, for Haskell 98.
/ /_\\/ __ / /___| | http://www.haskell.org/ghc/
\____/\/ /_/\____/|_| Type :? for help.
Loading package base-1.0 ... linking ... done.
Prelude> let cl = cycle [1..5]
Prelude> take 100 cl
[1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5]
Prelude> let cl = cycle [-2,2]
Prelude> take 100 cl
[-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2]
Prelude> let cl = cycle [-2..2]
Prelude> sum $ take 1000 cl
0
Prelude> sum $ take 10000 cl
0
Prelude> sum $ take 100000 cl
0
Prelude> sum $ take 1000000 cl
*** Exception: stack overflow
Prelude> sum $! take 1000000 cl
*** Exception: stack overflow
Prelude> foldl' (+) 0 $! take 1000000 cl
<interactive>:1:0: Not in scope: `foldl''
Prelude> List.foldl' (+) 0 $! take 1000000 cl
<interactive>:1:0: Not in scope: `List.foldl''
Prelude> Data.List.foldl' (+) 0 $! take 1000000 cl
0
Prelude> Data.List.foldl' (+) 0 $! take 10000000 cl
0
Prelude> Data.List.foldl' (+) 0 $! take 100000000 cl
0
Prelude> Data.List.foldl' (+) 0 $! take 100000000 cl
0
Prelude> Data.List.foldl' (+) 0 $! take 1000000 cl
0
Prelude> Data.List.foldl (+) 0 $! take 1000000 cl
*** Exception: stack overflow
*********************
After that I read "TyingTheKnot" page of HaWiki and
desided to repeat example with double linked list. So i
created file. It already contained some garbage from my
previous experiments but I decided it's irrelevant:
% cat test13.hs
import Control.Exception as C
data DL a = DL {prev_dl::DL, el::a, next_dl::DL}
mkDL :: [a] -> DL a
mkDL xs = let (first,last) = go last xs first
in first
go :: DL a -> [a] -> DL a -> (DL a,DL a)
go prev [] next = (prev, next)
go prev (x:xs) next = let this = DL prev x rest
(rest,fin) = go this xs next
in this
takeF 0 lst = []
takeF n lst = (el lst):takeF (n-1) next_dl lst
takeR 0 lst = []
takeR n lst = (el lst):takeF (n-1) prev_dl lst
main = do putStrLn "hello"
r <- getLine
C.catch (action r) handler
action :: String -> IO()
action r = if (r=="") then C.ioError (userError "input
void")
else print $ r++r
handler :: Exception -> IO()
% cat test14.hs
~/coding/Haskell
% cat test13.hs
~/coding/Haskell
import Control.Exception as C
data DL a = DL {prev_dl::DL, el::a, next_dl::DL}
mkDL :: [a] -> DL a
mkDL xs = let (first,last) = go last xs first
in first
go :: DL a -> [a] -> DL a -> (DL a,DL a)
go prev [] next = (prev, next)
go prev (x:xs) next = let this = DL prev x rest
(rest,fin) = go this xs next
in this
takeF 0 lst = []
takeF n lst = (el lst):takeF (n-1) next_dl lst
takeR 0 lst = []
takeR n lst = (el lst):takeF (n-1) prev_dl lst
main = do putStrLn "hello"
r <- getLine
C.catch (action r) handler
action :: String -> IO()
action r = if (r=="") then C.ioError (userError "input
void")
else print $ r++r
handler :: Exception -> IO()
*** end of test13.hs
After file was ready I tried to load it in my ghci
session and got this:
Prelude> :l test13.hs
Compiling Main ( test13.hs, interpreted )
ghc-6.4: panic! (the `impossible' happened, GHC version
6.4):
Unify.unifyTauTyLists: mismatched type lists!
Please report it as a compiler bug to
glasgow-haskell-bugs@haskell.org,
or http://sourceforge.net/projects/ghc/.
>
>
Some info about my system.
% uname -a
Linux mausov_comp 2.6.10-as5 #1 Fri Jun 24 13:45:31 MSD
2005 i686 Intel(R) Celeron(R) CPU 2.30GHz GenuineIntel
GNU/Linux
% gcc -v
Reading specs from
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/specs
Configured with:
/var/tmp/portage/gcc-3.3.4-r1/work/gcc-3.3.4/configure
--prefix=/usr
--bindir=/usr/i686-pc-linux-gnu/gcc-bin/3.3
--includedir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3/info
--enable-shared --host=i686-pc-linux-gnu
--target=i686-pc-linux-gnu --with-system-zlib
--enable-languages=c,c++ --enable-threads=posix
--enable-long-long --disable-checking
--disable-libunwind-exceptions --enable-cstdio=stdio
--enable-version-specific-runtime-libs
--with-gxx-include-dir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/include/g++-v3
--with-local-prefix=/usr/local --enable-shared
--enable-nls --without-included-gettext
--disable-multilib --enable-__cxa_atexit
--enable-clocale=generic
Thread model: posix
gcc version 3.3.4 20040623 (Gentoo Linux 3.3.4-r1,
ssp-3.3.2-2, pie-8.7.6)
I compiled ghc-6.4 using ghc-6.2.2
My email is v_dmitry@list.ru
Hope that'l help
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedDuplicate |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"compiler panic","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"ResolvedDuplicate","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"6.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nI played with cyclic lists in GHCI.\nMy session looked like:\n\n% ghci \n \n ___ ___ _\n / _ \\ /\\ /\\/ __(_)\n / /_\\// /_/ / / | | GHC Interactive, version\n6.4, for Haskell 98.\n/ /_\\\\/ __ / /___| | http://www.haskell.org/ghc/\n\\____/\\/ /_/\\____/|_| Type :? for help.\n\nLoading package base-1.0 ... linking ... done.\nPrelude> let cl = cycle [1..5]\nPrelude> take 100 cl\n[1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5,1,2,3,4,5]\nPrelude> let cl = cycle [-2,2]\nPrelude> take 100 cl\n[-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2,-2,2]\nPrelude> let cl = cycle [-2..2]\nPrelude> sum $ take 1000 cl\n0\nPrelude> sum $ take 10000 cl\n0\nPrelude> sum $ take 100000 cl\n0\nPrelude> sum $ take 1000000 cl\n*** Exception: stack overflow\nPrelude> sum $! take 1000000 cl\n*** Exception: stack overflow\nPrelude> foldl' (+) 0 $! take 1000000 cl\n\n<interactive>:1:0: Not in scope: `foldl''\nPrelude> List.foldl' (+) 0 $! take 1000000 cl\n\n<interactive>:1:0: Not in scope: `List.foldl''\nPrelude> Data.List.foldl' (+) 0 $! take 1000000 cl\n0\nPrelude> Data.List.foldl' (+) 0 $! take 10000000 cl\n0\nPrelude> Data.List.foldl' (+) 0 $! take 100000000 cl\n0\nPrelude> Data.List.foldl' (+) 0 $! take 100000000 cl\n0\nPrelude> Data.List.foldl' (+) 0 $! take 1000000 cl\n0\nPrelude> Data.List.foldl (+) 0 $! take 1000000 cl\n*** Exception: stack overflow\n\n*********************\n\nAfter that I read \"TyingTheKnot\" page of HaWiki and\ndesided to repeat example with double linked list. So i\ncreated file. It already contained some garbage from my\nprevious experiments but I decided it's irrelevant:\n\n% cat test13.hs \n \nimport Control.Exception as C\n\ndata DL a = DL {prev_dl::DL, el::a, next_dl::DL}\n\nmkDL :: [a] -> DL a\nmkDL xs = let (first,last) = go last xs first\n in first\n\ngo :: DL a -> [a] -> DL a -> (DL a,DL a)\ngo prev [] next = (prev, next) \ngo prev (x:xs) next = let this = DL prev x rest\n (rest,fin) = go this xs next\n in this\n\ntakeF 0 lst = []\ntakeF n lst = (el lst):takeF (n-1) next_dl lst\n\ntakeR 0 lst = []\ntakeR n lst = (el lst):takeF (n-1) prev_dl lst\n\n\n\n\n\nmain = do putStrLn \"hello\"\n r <- getLine\n C.catch (action r) handler\n \naction :: String -> IO()\naction r = if (r==\"\") then C.ioError (userError \"input\nvoid\") \n else print $ r++r\n\nhandler :: Exception -> IO()\n% cat test14.hs \n \n~/coding/Haskell \n% cat test13.hs \n \n~/coding/Haskell \nimport Control.Exception as C\n\ndata DL a = DL {prev_dl::DL, el::a, next_dl::DL}\n\nmkDL :: [a] -> DL a\nmkDL xs = let (first,last) = go last xs first\n in first\n\ngo :: DL a -> [a] -> DL a -> (DL a,DL a)\ngo prev [] next = (prev, next) \ngo prev (x:xs) next = let this = DL prev x rest\n (rest,fin) = go this xs next\n in this\n\ntakeF 0 lst = []\ntakeF n lst = (el lst):takeF (n-1) next_dl lst\n\ntakeR 0 lst = []\ntakeR n lst = (el lst):takeF (n-1) prev_dl lst\n\n\n\n\n\nmain = do putStrLn \"hello\"\n r <- getLine\n C.catch (action r) handler\n \naction :: String -> IO()\naction r = if (r==\"\") then C.ioError (userError \"input\nvoid\") \n else print $ r++r\n\nhandler :: Exception -> IO()\n\n*** end of test13.hs\n\nAfter file was ready I tried to load it in my ghci\nsession and got this:\n\nPrelude> :l test13.hs\nCompiling Main ( test13.hs, interpreted )\nghc-6.4: panic! (the `impossible' happened, GHC version\n6.4):\n Unify.unifyTauTyLists: mismatched type lists!\n\nPlease report it as a compiler bug to\nglasgow-haskell-bugs@haskell.org,\nor http://sourceforge.net/projects/ghc/.\n\n>\n>\n\nSome info about my system.\n\n% uname -a \n \nLinux mausov_comp 2.6.10-as5 #1 Fri Jun 24 13:45:31 MSD\n2005 i686 Intel(R) Celeron(R) CPU 2.30GHz GenuineIntel\nGNU/Linux\n\n% gcc -v \n \nReading specs from\n/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/specs\nConfigured with:\n/var/tmp/portage/gcc-3.3.4-r1/work/gcc-3.3.4/configure\n--prefix=/usr\n--bindir=/usr/i686-pc-linux-gnu/gcc-bin/3.3\n--includedir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/include\n--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3\n--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3/man\n--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3/info\n--enable-shared --host=i686-pc-linux-gnu\n--target=i686-pc-linux-gnu --with-system-zlib\n--enable-languages=c,c++ --enable-threads=posix\n--enable-long-long --disable-checking\n--disable-libunwind-exceptions --enable-cstdio=stdio\n--enable-version-specific-runtime-libs\n--with-gxx-include-dir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/include/g++-v3\n--with-local-prefix=/usr/local --enable-shared\n--enable-nls --without-included-gettext\n--disable-multilib --enable-__cxa_atexit\n--enable-clocale=generic\nThread model: posix\ngcc version 3.3.4 20040623 (Gentoo Linux 3.3.4-r1,\nssp-3.3.2-2, pie-8.7.6)\n\nI compiled ghc-6.4 using ghc-6.2.2\n\nMy email is v_dmitry@list.ru\n\nHope that'l help\n\n\n\n\n\n\n\n\n\n\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/449Very big integer arithmetic crashes GHCi on Windows and Mac2019-07-07T19:17:55ZSimon Peyton JonesVery big integer arithmetic crashes GHCi on Windows and Mac```
With GHC 6.4, interpreted or compiled, on Windows and
Mac OS X,
evaluating the expression (4^(4^44))::Integer causes a
crash.
On Unix, it just goes out to lunch and eats memory,
which seems more plausible.
On Mac, the message ...```
With GHC 6.4, interpreted or compiled, on Windows and
Mac OS X,
evaluating the expression (4^(4^44))::Integer causes a
crash.
On Unix, it just goes out to lunch and eats memory,
which seems more plausible.
On Mac, the message is:
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version 6.4, for
Haskell 98.
/ /_\\/ __ / /___| | http://www.haskell.org/ghc/
\____/\/ /_/\____/|_| Type :? for help.
Loading package base-1.0 ... linking ... done.
Prelude> 4^(4^44)::Integer
bash: [539: 1] tcsetattr: Operation not supported
Segmentation fault
```6.4.2Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/450"class A where a :: A -> Int" panics GHC 6.42019-07-07T19:17:55Zcarlossch"class A where a :: A -> Int" panics GHC 6.4```
Coming back to Haskell after a year off, I accidentally typed a very
simple class definition wrong, and turns out that GHC 6.4 dies with
ghc-6.4: panic! (the `impossible' happened, GHC version 6.4):
ds_app_type Main.A{tc r1zQ} []...```
Coming back to Haskell after a year off, I accidentally typed a very
simple class definition wrong, and turns out that GHC 6.4 dies with
ghc-6.4: panic! (the `impossible' happened, GHC version 6.4):
ds_app_type Main.A{tc r1zQ} []
if you run
$ ghc crasher.hs
ghc-6.4: panic! (the `impossible' happened, GHC version 6.4):
ds_app_type Main.A{tc r151} []
where crasher.hs is a file with a single line
class A where a :: A -> Int
I'm using the OSX version of GHC, by the way.
-carlos
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | None |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedDuplicate |
| Component | None |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"\"class A where a :: A -> Int\" panics GHC 6.4","status":"New","operating_system":"","component":"None","related":[],"milestone":"","resolution":"ResolvedDuplicate","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"None","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nComing back to Haskell after a year off, I accidentally typed a very \nsimple class definition wrong, and turns out that GHC 6.4 dies with \n\nghc-6.4: panic! (the `impossible' happened, GHC version 6.4):\n\tds_app_type Main.A{tc r1zQ} []\n\nif you run\n\n$ ghc crasher.hs\nghc-6.4: panic! (the `impossible' happened, GHC version 6.4):\n\tds_app_type Main.A{tc r151} []\n\nwhere crasher.hs is a file with a single line\n\nclass A where a :: A -> Int\n\nI'm using the OSX version of GHC, by the way.\n\n-carlos\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/451GHC poor type-checker error message2019-07-07T19:17:55ZisaacdupreeGHC poor type-checker error message```
Here is a very tricky GHC (6.4) error message I found.
I have simplified the context from where I found it,
but the error is basically the same (still rather less
confusing than the real thing, where Value ::
[TString], TString :: [...```
Here is a very tricky GHC (6.4) error message I found.
I have simplified the context from where I found it,
but the error is basically the same (still rather less
confusing than the real thing, where Value ::
[TString], TString :: [(String,Textdomain)], and error
messages talked about, e.g., [[([Char],Textdomain)]]
instead of [[Char]]). I had to run the original through
Hugs to find my mistake there. Here is the code:
> import Data.List(intersperse)
> type Value = String
> -- unifyEnd :: [key] -> [Value] -> [Value]
> -- this example assumes (length ks <= length vs)
> unifyEnd ks vs =
> let (fvs,evs) = splitAt (length ks - 1) vs
> in fvs ++ concat (intersperse "," evs)
Here is the GHC-6.4 error message:
BadErrorMessage.lhs:10:41:
Couldn't match `[Char]' against `Char'
Expected type: [[Char]]
Inferred type: [Char]
In the second argument of `intersperse', namely `evs'
In the first argument of `concat', namely
`(intersperse "," evs)'
The error message when the type signature is
uncommented at least might lead to less pursuing of the
wrong things, claiming the literal `","' is in error
instead, but does not get to the location of the error.
The Hugs error, while not perfect, has got the location
correct: it shows me the part I erred in:
ERROR "BadErrorMessage.lhs":8 - Type error in application
*** Expression : fvs ++ concat (intersperse "," evs)
*** Term : fvs
*** Type : [[Char]]
*** Does not match : [Char]
I had forgotten to put [ ] around concat (...), i.e.
fvs ++ [concat (intersperse "," evs)]
is the corrected fragment of the definition.
GHC did not appear to realize that the two arguments to
'intersperse' were currently consistent with each
other, given intersperse's type signature of a -> [a]
-> [a], but would not be if the type of the one claimed
to be in error were changed to the "expected" type. (If
it could say that they were both the wrong type, that
would be another choice it had that makes sense, but
that would be two human errors, perhaps less likely
than one.)
```https://gitlab.haskell.org/ghc/ghc/-/issues/452+RTS -xc and SIGINT handler gives seg fault2019-07-07T19:17:55Zfergus+RTS -xc and SIGINT handler gives seg fault```
To reproduce this bug, save the attached file Bug.hs,
run the following commands
ghc -package posix -prof -auto-all Bug.hs
./a.out +RTS -xc
and then hit control-C. The result is a SIGSEGV inside
fprintCCS().
```
<details><s...```
To reproduce this bug, save the attached file Bug.hs,
run the following commands
ghc -package posix -prof -auto-all Bug.hs
./a.out +RTS -xc
and then hit control-C. The result is a SIGSEGV inside
fprintCCS().
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | None |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | Profiling |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"+RTS -xc and SIGINT handler gives seg fault","status":"New","operating_system":"","component":"Profiling","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"None","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nTo reproduce this bug, save the attached file Bug.hs, \nrun the following commands\n\n ghc -package posix -prof -auto-all Bug.hs\n ./a.out +RTS -xc\n\nand then hit control-C. The result is a SIGSEGV inside\nfprintCCS().\n\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/453scavenge_one: strange object 472019-07-07T19:17:54Ztuananhbirmscavenge_one: strange object 47```
Hi, i am running GHC 6.4, in Redhat 9, running
sometimes with flag -threaded on.
Please look at the file Mult.hs
and function: startM1 (17-20)
run this function for different inputs (orignially,
multiply (1%7) with (0%2)) try to ...```
Hi, i am running GHC 6.4, in Redhat 9, running
sometimes with flag -threaded on.
Please look at the file Mult.hs
and function: startM1 (17-20)
run this function for different inputs (orignially,
multiply (1%7) with (0%2)) try to run with : (1%3) and
(0%1)
(2%3) and (0%1)
(1%2) and (0%1)
(1%5) and (0%1)
Best regards
TuanAnh
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | None |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | None |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"scavenge_one: strange object 47","status":"New","operating_system":"","component":"None","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"None","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\n\nHi, i am running GHC 6.4, in Redhat 9, running\nsometimes with flag -threaded on.\n\n\nPlease look at the file Mult.hs\n\nand function: startM1 (17-20)\n\nrun this function for different inputs (orignially,\nmultiply (1%7) with (0%2)) try to run with : (1%3) and\n(0%1)\n (2%3) and (0%1)\n (1%2) and (0%1)\n (1%5) and (0%1)\n\n\nBest regards\nTuanAnh\n\n\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/454hPutBuf doesn't respect LineBuffering2019-07-07T19:17:54ZSimon MarlowhPutBuf doesn't respect LineBuffering```
On 15 April 2005 02:39, Ian Lynagh wrote:
> If I run this program:
>
> --------------------------------------------------
> import System.Cmd (system)
> import Foreign.C.String (castCharToCChar)
> import Foreign.Marshal.Array (newA...```
On 15 April 2005 02:39, Ian Lynagh wrote:
> If I run this program:
>
> --------------------------------------------------
> import System.Cmd (system)
> import Foreign.C.String (castCharToCChar)
> import Foreign.Marshal.Array (newArray)
> import System.IO (hSetBinaryMode, hPutBuf, stdout,
hSetBuffering,
> BufferMode(..))
>
> main = do hSetBinaryMode stdout True
> hSetBuffering stdout LineBuffering
> p <- newArray (map castCharToCChar "foo\n")
> hPutBuf stdout p 4
> system "sleep 5"
> putStr "bar\n"
> --------------------------------------------------
>
> compiled by GHC then it waits 5 seconds and then
prints foo and bar
> together.
>
> With hugs, foo is printed and then 5 seconds later
bar is printed, as
> I would expect.
True, the implementation doesn't respect LineBuffering
(though it does
respect the other buffering modes, I believe). That's
a bug.
```6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/455mkProtoBCO: stack use won't fit in 16 bits 791412019-07-07T19:17:54ZSimon MarlowmkProtoBCO: stack use won't fit in 16 bits 79141```
ERROR MESSAGE:
Prelude> :r
Compiling BookData ( ./BookData.hs, interpreted )
ghc-6.2.2: panic! (the `impossible' happened, GHC
version 6.2.2):
mkProtoBCO: stack use won't fit in 16 bits 79141
Test case and rest of m...```
ERROR MESSAGE:
Prelude> :r
Compiling BookData ( ./BookData.hs, interpreted )
ghc-6.2.2: panic! (the `impossible' happened, GHC
version 6.2.2):
mkProtoBCO: stack use won't fit in 16 bits 79141
Test case and rest of message here:
http://www.haskell.org//pipermail/glasgow-haskell-bugs/2005-March/004871.html
```6.6.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/456panic:Unify.unifyTauTyLists2019-07-07T19:17:54Zvolkersfpanic:Unify.unifyTauTyLists```
The attached sample program triggers a panic because I forgot to
pass the type argument in the recursive algebraic datatype
construction. The commented line is correct.
GHC should not panic but instead provide a helpful error messa...```
The attached sample program triggers a panic because I forgot to
pass the type argument in the recursive algebraic datatype
construction. The commented line is correct.
GHC should not panic but instead provide a helpful error message.
(Unluckily, I won't be able to test this with -HEAD atm)
Compiling Main ( bugs.hs, interpreted )
ghc-6.4: panic! (the `impossible' happened, GHC version 6.4):
Unify.unifyTauTyLists: mismatched type lists!
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedDuplicate |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"panic:Unify.unifyTauTyLists","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"ResolvedDuplicate","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"6.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nThe attached sample program triggers a panic because I forgot to \npass the type argument in the recursive algebraic datatype \nconstruction. The commented line is correct.\nGHC should not panic but instead provide a helpful error message.\n(Unluckily, I won't be able to test this with -HEAD atm)\n\nCompiling Main ( bugs.hs, interpreted )\nghc-6.4: panic! (the `impossible' happened, GHC version 6.4):\n Unify.unifyTauTyLists: mismatched type lists!\n\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/457Strictness problem2019-07-07T19:17:53ZnilsandersStrictness problem```
As requested, this is a resubmission (and update) of a
previously reported bug, to get it into the bug tracker.
The following program should output something involving
Correct:
> module Main where
> f x = case x of
> x@True -> ...```
As requested, this is a resubmission (and update) of a
previously reported bug, to get it into the bug tracker.
The following program should output something involving
Correct:
> module Main where
> f x = case x of
> x@True -> \y -> x && y
> x@False -> \y -> x && y
> main = putStrLn $ f (error "Correct") `seq` "Error"
However, whether it does so is a non-trivial function
of the GHC version and optimisation settings:
GHC version -O2? Correct?
------------------------------
4.08.1 No Yes
4.08.1 Yes No
5.04.2 No No
5.04.2 Yes Yes
6.0.1 _ No
6.2.2 _ No
6.4 _ No
6.4.1.20050820 _ No
All tests were run on a Solaris system.
Different fs give different behaviour, at least for
6.0.1. Try e.g.
> f x = case x of
> True -> id
> False -> id
```Jan Stolarekjan.stolarek@ed.ac.ukJan Stolarekjan.stolarek@ed.ac.ukhttps://gitlab.haskell.org/ghc/ghc/-/issues/458Warning -fwarn-unused-imports does not go away2019-07-07T19:17:53ZnobodyWarning -fwarn-unused-imports does not go away```
When I compile the attached file, where I only want to
import the instance declarations of the module
Control.Monad.Reader, I still get an error with the
flag -fwarn-unused-imports, even though this idiom is
regarded OK according to ...```
When I compile the attached file, where I only want to
import the instance declarations of the module
Control.Monad.Reader, I still get an error with the
flag -fwarn-unused-imports, even though this idiom is
regarded OK according to the user manual.
So, I would like GHC not to report this warning even
with -fwarn-unused-imports.
/Koen Claessen
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | None |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Warning -fwarn-unused-imports does not go away","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"None","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nWhen I compile the attached file, where I only want to\nimport the instance declarations of the module\nControl.Monad.Reader, I still get an error with the\nflag -fwarn-unused-imports, even though this idiom is\nregarded OK according to the user manual.\n\nSo, I would like GHC not to report this warning even\nwith -fwarn-unused-imports.\n\n/Koen Claessen\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/459Bad parse error message2019-07-07T19:17:53ZnobodyBad parse error message```
Simon asked me to report this very minor "bug".
When compiling a file that looks like:
main = print (1+2
the parser complains (and rightly so). However, it
blames the above on "possibly incorrect indentation",
whereas it is obviou...```
Simon asked me to report this very minor "bug".
When compiling a file that looks like:
main = print (1+2
the parser complains (and rightly so). However, it
blames the above on "possibly incorrect indentation",
whereas it is obvious I just forgot a parenthesis.
/Koen Claessen
```https://gitlab.haskell.org/ghc/ghc/-/issues/460reporting the origin of kind errors2019-07-07T19:17:53Znokta_kantoreporting the origin of kind errors```
This code produces a kind error in the class declaration.
There is indeed a kind error, but I think the error message
is somewhat misleading. It reports a kind error in the class
declaration. The kind error is due to an inconsi...```
This code produces a kind error in the class declaration.
There is indeed a kind error, but I think the error message
is somewhat misleading. It reports a kind error in the class
declaration. The kind error is due to an inconsistency
between usage of "Name" in the class and data
declarations.
It would make more sense to me if the kind error were
reported in the data declaration, or if it contained some
information on how the expected kind was inferred.
-- beginning of code
class (Show a, Eq a, Monad m) => Name m a where
hashName :: a -> Int
newName :: m a
data Name a => Exp a
-- end of code
The error reported is:
test2.hs:1:0:
Couldn't match kind `*' against `k_a16S -> *'
In the class declaration for `Name'
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"reporting the origin of kind errors","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"6.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nThis code produces a kind error in the class declaration. \nThere is indeed a kind error, but I think the error message \nis somewhat misleading. It reports a kind error in the class \ndeclaration. The kind error is due to an inconsistency \nbetween usage of \"Name\" in the class and data \ndeclarations. \n \nIt would make more sense to me if the kind error were \nreported in the data declaration, or if it contained some \ninformation on how the expected kind was inferred. \n \n-- beginning of code \nclass (Show a, Eq a, Monad m) => Name m a where \n hashName :: a -> Int \n newName :: m a \n \ndata Name a => Exp a \n-- end of code \n \nThe error reported is: \ntest2.hs:1:0: \n Couldn't match kind `*' against `k_a16S -> *' \n In the class declaration for `Name' \n \n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/461ghc-6.4.1: ghc-6.4.1: panic2019-07-07T19:17:52Zggdghc-6.4.1: ghc-6.4.1: panic```
While trying to build hIDE with the latest code
pulled on 23rd of Sept. 2005, I get the following:
Building hide-yi-0.1.0...
/usr/bin/ghc -package-name hide-yi -odir dist/build
-hidir dist/build -hide-all-packages --make ...```
While trying to build hIDE with the latest code
pulled on 23rd of Sept. 2005, I get the following:
Building hide-yi-0.1.0...
/usr/bin/ghc -package-name hide-yi -odir dist/build
-hidir dist/build -hide-all-packages --make -i -isrc
-Wall -Werror -fglasgow-exts -package base-1.0
-package gtk-0.9.9.5 -package sourceview-0.9.9.5
-package mtl-1.0 -package hide-shell-0.1.0
-package yi-0.2 Hide.Yi -v
Glasgow Haskell Compiler, Version 6.4.1, for
Haskell 98, compiled by GHC version
6.4.1.20050801
Using package config
file: /usr/lib64/ghc-6.4.1/package.conf
Using package config
file: /home/gour/.ghc/x86_64-linux-6.4.1/package.conf
*** Deleting temp files
Deleting:
ghc-6.4.1: ghc-6.4.1: panic! (the `impossible'
happened, GHC version 6.4.1):
unknown exception
Please report it as a compiler bug to
glasgow-haskell-bugs@haskell.org,
or http://sourceforge.net/projects/ghc/.
********************
setup build failed for plugins/yiBase
Here is the snippet from 'darcs changes, so you
can discern the state of the hIDE repo
(http://www.scannedinavian.org/repos/hIDE):
gour@gaura-nitai ~/repos/hIDE $ darcs changes
--human-readable
Fri Sep 23 00:30:07 CEST 2005 Duncan Coutts
<duncan.coutts@worc.ox.ac.uk>
* More GUI tweaks and demo editor
improvements
Thu Sep 22 17:06:16 CEST 2005 Duncan Coutts
<duncan.coutts@worc.ox.ac.uk>
* Fix up yiBase so it still works
Fro the moment the yi widget gets it's own top
level window, just until it is
adapted to use the new ide shell interface
Thu Sep 22 16:51:22 CEST 2005 Duncan Coutts
<duncan.coutts@worc.ox.ac.uk>
* More build.sh portability fixes
Thu Sep 22 16:48:40 CEST 2005 Duncan Coutts
<duncan.coutts@worc.ox.ac.uk>
* Do not build with -threaded, use the gtk2hs
thread hack.
Thu Sep 22 16:46:31 CEST 2005 Duncan Coutts
<duncan.coutts@worc.ox.ac.uk>
* Add wadges of new GUI stuff
This now has the file browser and a demo text
editor using the model/view
split. You can open multiple top level windows
(View->New Window) and edit the
same buffer from multiple windows.
...
The yi repo is at:
http://scannedinavian.com/repos/yi
My system is:
gour@gaura-nitai ~/repos/yi $ uname -a
Linux gaura-nitai 2.6.12-gentoo #3 Fri Aug 12
13:17:04 CEST 2005 x86_64 AMD Athlon(tm) 64
Processor 3000+ AuthenticAMD GNU/Linux
Any additional info required?
Sincerely,
Gour
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | None |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | None |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghc-6.4.1: ghc-6.4.1: panic","status":"New","operating_system":"","component":"None","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"None","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nWhile trying to build hIDE with the latest code \npulled on 23rd of Sept. 2005, I get the following: \n \nBuilding hide-yi-0.1.0... \n/usr/bin/ghc -package-name hide-yi -odir dist/build \n-hidir dist/build -hide-all-packages --make -i -isrc \n-Wall -Werror -fglasgow-exts -package base-1.0 \n-package gtk-0.9.9.5 -package sourceview-0.9.9.5 \n-package mtl-1.0 -package hide-shell-0.1.0 \n-package yi-0.2 Hide.Yi -v \nGlasgow Haskell Compiler, Version 6.4.1, for \nHaskell 98, compiled by GHC version \n6.4.1.20050801 \nUsing package config \nfile: /usr/lib64/ghc-6.4.1/package.conf \nUsing package config \nfile: /home/gour/.ghc/x86_64-linux-6.4.1/package.conf \n*** Deleting temp files \nDeleting: \nghc-6.4.1: ghc-6.4.1: panic! (the `impossible' \nhappened, GHC version 6.4.1): \n unknown exception \n \nPlease report it as a compiler bug to \nglasgow-haskell-bugs@haskell.org, \nor http://sourceforge.net/projects/ghc/. \n \n******************** \nsetup build failed for plugins/yiBase \n \n \nHere is the snippet from 'darcs changes, so you \ncan discern the state of the hIDE repo \n(http://www.scannedinavian.org/repos/hIDE): \n \ngour@gaura-nitai ~/repos/hIDE $ darcs changes \n--human-readable \nFri Sep 23 00:30:07 CEST 2005 Duncan Coutts \n<duncan.coutts@worc.ox.ac.uk> \n * More GUI tweaks and demo editor \nimprovements \n \nThu Sep 22 17:06:16 CEST 2005 Duncan Coutts \n<duncan.coutts@worc.ox.ac.uk> \n * Fix up yiBase so it still works \n Fro the moment the yi widget gets it's own top \nlevel window, just until it is \n adapted to use the new ide shell interface \n \nThu Sep 22 16:51:22 CEST 2005 Duncan Coutts \n<duncan.coutts@worc.ox.ac.uk> \n * More build.sh portability fixes \n \nThu Sep 22 16:48:40 CEST 2005 Duncan Coutts \n<duncan.coutts@worc.ox.ac.uk> \n * Do not build with -threaded, use the gtk2hs \nthread hack. \n \nThu Sep 22 16:46:31 CEST 2005 Duncan Coutts \n<duncan.coutts@worc.ox.ac.uk> \n * Add wadges of new GUI stuff \n This now has the file browser and a demo text \neditor using the model/view \n split. You can open multiple top level windows \n(View->New Window) and edit the \n same buffer from multiple windows. \n... \n \nThe yi repo is at: \n \nhttp://scannedinavian.com/repos/yi \n \n \nMy system is: \n \ngour@gaura-nitai ~/repos/yi $ uname -a \nLinux gaura-nitai 2.6.12-gentoo #3 Fri Aug 12 \n13:17:04 CEST 2005 x86_64 AMD Athlon(tm) 64 \nProcessor 3000+ AuthenticAMD GNU/Linux \n \n \nAny additional info required? \n \nSincerely, \nGour \n \n \n \n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/462Incomplete pattern warnings with GADTs2019-07-07T19:17:52ZbringIncomplete pattern warnings with GADTs```
{-
With GADTs, -fwarn-incomplete-patterns complains
about missing
impossible cases.
-}
{-# OPTIONS_GHC -fglasgow-exts
-fwarn-incomplete-patterns #-}
data Var = Var
data Typ = Typ
data Tree a where
V :: String -> Tree ...```
{-
With GADTs, -fwarn-incomplete-patterns complains
about missing
impossible cases.
-}
{-# OPTIONS_GHC -fglasgow-exts
-fwarn-incomplete-patterns #-}
data Var = Var
data Typ = Typ
data Tree a where
V :: String -> Tree Var
T_int :: Tree Typ
getId :: Tree Var -> String
getId (V x) = x
--getId T_int = "T_int"
{-
With the last line commented out:
gadt-pattern-warning.hs:11:0:
Warning: Pattern match(es) are non-exhaustive
In the definition of `getId': Patterns not
matched: T_int
Ok, modules loaded: Main.
With the last line not commented out:
gadt-pattern-warning.hs:12:6:
Inaccessible case alternative: Can't match types
`Typ' and `Var'
When checking the pattern: T_int
In the definition of `getId': getId T_int = "T_int"
Failed, modules loaded: none.
-}
```nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/463parse error on input `\' when using -cpp2019-07-07T19:17:52Zpeter26parse error on input `\' when using -cpp```
When compiling code like:
infixl 9 \\
(\\) = undefined
causes a parser error, when compiling with the -cpp option
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| -------------------...```
When compiling code like:
infixl 9 \\
(\\) = undefined
causes a parser error, when compiling with the -cpp option
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | None |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedWon'tFix |
| Component | None |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"parse error on input `\\' when using -cpp","status":"New","operating_system":"","component":"None","related":[],"milestone":"","resolution":"ResolvedWon'tFix","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"None","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nWhen compiling code like:\n\ninfixl 9 \\\\\n(\\\\) = undefined\n\ncauses a parser error, when compiling with the -cpp option\n\n\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/464Control.Exception.assert broken with -O2019-07-07T19:17:52ZfergusControl.Exception.assert broken with -O```
According to the ghc documentation
(section 4.9 "optimization" and section 7.8 "assertions" in
the user guide, and the documentation for Control.Exception
in the hierarchical libraries guide),
assertions should be checked unless expl...```
According to the ghc documentation
(section 4.9 "optimization" and section 7.8 "assertions" in
the user guide, and the documentation for Control.Exception
in the hierarchical libraries guide),
assertions should be checked unless explicitly disabled
with
"-fignore-asserts", and the "-O" option should have no
effect on them.
But in ghc version 6.4.1.20050801, "-O" seems to also
have the
effect of disabling assertions:
bash$ cat Test.hs
import Control.Exception
main = print (assert False (42::Int))
bash$ ghc -O Test.hs && ./a.out
42
This undocumented behaviour is an egregious violation
of the
principle of least surprise.
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Control.Exception.assert broken with -O","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"6.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nAccording to the ghc documentation\n(section 4.9 \"optimization\" and section 7.8 \"assertions\" in\nthe user guide, and the documentation for Control.Exception\nin the hierarchical libraries guide),\nassertions should be checked unless explicitly disabled\nwith\n\"-fignore-asserts\", and the \"-O\" option should have no\neffect on them.\n\nBut in ghc version 6.4.1.20050801, \"-O\" seems to also\nhave the\neffect of disabling assertions:\n\n bash$ cat Test.hs\n import Control.Exception\n main = print (assert False (42::Int))\n\n bash$ ghc -O Test.hs && ./a.out\n 42\n\nThis undocumented behaviour is an egregious violation\nof the\nprinciple of least surprise.\n\n\n\n\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/465in hdirect stdcall not supported on PPC Mac OS X 10.32019-07-07T19:17:52Zyaseppochiin hdirect stdcall not supported on PPC Mac OS X 10.3```
I'm building CVS HEAD from 2005-10-05 with 6.4.1.
I get the error in the attached log.
I'm not in a hurry, but in a couple of months one of my
projects will be to the point that I would like to call
some Haskell code from another p...```
I'm building CVS HEAD from 2005-10-05 with 6.4.1.
I get the error in the attached log.
I'm not in a hurry, but in a couple of months one of my
projects will be to the point that I would like to call
some Haskell code from another project written in C.
If there's anything I can do to help with getting
hdirect supported on
Mac PowerBook G4
Mac OS X 10.3.9 "panther"
Please let me know. (I probably will upgrade to 10.4
"Tiger" in the near future.)
It would be nice if the build could fail safely (ie,
not produce the hdirect library, but not stop the rest
of the fptools build). There doesn't seem to be a way
to disable the feature via configure.
Stephen Turnbull
stephen@xemacs.org
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | None |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedWon'tFix |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"in hdirect stdcall not supported on PPC Mac OS X 10.3","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"ResolvedWon'tFix","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"None","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nI'm building CVS HEAD from 2005-10-05 with 6.4.1.\n\nI get the error in the attached log.\n\nI'm not in a hurry, but in a couple of months one of my\nprojects will be to the point that I would like to call\nsome Haskell code from another project written in C. \nIf there's anything I can do to help with getting\nhdirect supported on\n\nMac PowerBook G4\nMac OS X 10.3.9 \"panther\"\n\nPlease let me know. (I probably will upgrade to 10.4\n\"Tiger\" in the near future.)\n\nIt would be nice if the build could fail safely (ie,\nnot produce the hdirect library, but not stop the rest\nof the fptools build). There doesn't seem to be a way\nto disable the feature via configure.\n\nStephen Turnbull\nstephen@xemacs.org\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/466GLUT: Visibility doc flipped2019-07-07T19:17:51ZnobodyGLUT: Visibility doc flipped```
The documentation for the Visibility datatype is flipped.
The problem is in the Window Callbacks page for GLUT:
http://www.haskell.org/ghc/docs/latest/html/libraries/GLUT/Graphics.UI.GLUT.Callbacks.Window.html
source:
http://cvs.ha...```
The documentation for the Visibility datatype is flipped.
The problem is in the Window Callbacks page for GLUT:
http://www.haskell.org/ghc/docs/latest/html/libraries/GLUT/Graphics.UI.GLUT.Callbacks.Window.html
source:
http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/GLUT/Graphics/UI/GLUT/Callbacks/Window.hs
The documentation for the two constructors, NotVisible
and Visible, is inverted. It is almost certain that
the order of the constructors was chosen to conform
with the "False < True" semantics, and therefore the
documentation should be swapped instead of swapping the
constructors.
The error was introduced when the constructors were
added in version 1.4, and has not been altered since.
Eric Etheridge
etherson @ yahoo . com
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | None |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | libraries (other) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GLUT: Visibility doc flipped","status":"New","operating_system":"","component":"libraries (other)","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"spanne"},"version":"None","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nThe documentation for the Visibility datatype is flipped.\n\nThe problem is in the Window Callbacks page for GLUT:\nhttp://www.haskell.org/ghc/docs/latest/html/libraries/GLUT/Graphics.UI.GLUT.Callbacks.Window.html\n\nsource:\nhttp://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/GLUT/Graphics/UI/GLUT/Callbacks/Window.hs\n\nThe documentation for the two constructors, NotVisible\nand Visible, is inverted. It is almost certain that\nthe order of the constructors was chosen to conform\nwith the \"False < True\" semantics, and therefore the\ndocumentation should be swapped instead of swapping the\nconstructors.\n\nThe error was introduced when the constructors were\nadded in version 1.4, and has not been altered since.\n\nEric Etheridge\netherson @ yahoo . com\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->spannespannehttps://gitlab.haskell.org/ghc/ghc/-/issues/467Win GHC 6.4.1 crashes while building FastPackedString2019-07-07T19:17:51ZwagerlabsWin GHC 6.4.1 crashes while building FastPackedString```
GHC 6.4.1, tried on Win2K and WinXP. To reproduce install GHC 6.
4.1 from the MSI, download the FastPackedString source code from
darcs and build it according to instructions.
Configure goes through but the build phases crashes wi...```
GHC 6.4.1, tried on Win2K and WinXP. To reproduce install GHC 6.
4.1 from the MSI, download the FastPackedString source code from
darcs and build it according to instructions.
Configure goes through but the build phases crashes with a memory
access error.
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | None |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | None |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Win GHC 6.4.1 crashes while building FastPackedString","status":"New","operating_system":"","component":"None","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"None","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nGHC 6.4.1, tried on Win2K and WinXP. To reproduce install GHC 6.\n4.1 from the MSI, download the FastPackedString source code from \ndarcs and build it according to instructions. \n\nConfigure goes through but the build phases crashes with a memory \naccess error.\n\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/468internal error: schedule: awaitEvent() in threaded RTS2019-07-07T19:17:51Znobodyinternal error: schedule: awaitEvent() in threaded RTS```
jfeingold@solsticesoftware.com
forked a thread that waits on a server socket. The main
thread goes on to call threadDelay and putStrLn
repeatedly.
using GHC 6.4.1 on WinXP workstation.
pls, find attached a build script and sour...```
jfeingold@solsticesoftware.com
forked a thread that waits on a server socket. The main
thread goes on to call threadDelay and putStrLn
repeatedly.
using GHC 6.4.1 on WinXP workstation.
pls, find attached a build script and source code. this
has been stripped down to a fairly minimal demonstration
of the error.
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"internal error: schedule: awaitEvent() in threaded RTS","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"6.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\njfeingold@solsticesoftware.com\n\nforked a thread that waits on a server socket. The main \nthread goes on to call threadDelay and putStrLn \nrepeatedly.\n\nusing GHC 6.4.1 on WinXP workstation.\n\npls, find attached a build script and source code. this \nhas been stripped down to a fairly minimal demonstration \nof the error.\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/469Corruption of expression typed at prompt2019-07-07T19:17:51ZnobodyCorruption of expression typed at prompt```
cjbackhouse@hotmail.com
WinXP SP2 GHC 6.4.1
On two occasions now I have loaded my program and typed
at the prompt "toFile blah" and got the error "Not in
scope 'goFile'". Repeating the expressione evaluates it
correctly. Is strange...```
cjbackhouse@hotmail.com
WinXP SP2 GHC 6.4.1
On two occasions now I have loaded my program and typed
at the prompt "toFile blah" and got the error "Not in
scope 'goFile'". Repeating the expressione evaluates it
correctly. Is strange that both times it was exactly
the same function whose name was corrupted.
Does not seem to particularly repeatable (I've had it
twice out of maybe a hundred times I've done this)
Doubt it has anything to do with the details of my code
(which has changed substantially since last time this
happened)
Assume some (completely random) part of ghc is
corrupting what was typed at the prompt. This will,
unfortunately, probably make it completely impossible
to find...
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 6.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedFixed |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Corruption of expression typed at prompt","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"ResolvedFixed","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"6.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\ncjbackhouse@hotmail.com\n\nWinXP SP2 GHC 6.4.1\n\nOn two occasions now I have loaded my program and typed\nat the prompt \"toFile blah\" and got the error \"Not in\nscope 'goFile'\". Repeating the expressione evaluates it\ncorrectly. Is strange that both times it was exactly\nthe same function whose name was corrupted.\nDoes not seem to particularly repeatable (I've had it\ntwice out of maybe a hundred times I've done this)\nDoubt it has anything to do with the details of my code\n(which has changed substantially since last time this\nhappened)\nAssume some (completely random) part of ghc is\ncorrupting what was typed at the prompt. This will,\nunfortunately, probably make it completely impossible\nto find...\n\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/470build fails on Linux/sparc (genprimopcode: parse error at)2019-07-07T19:17:50Zarekmbuild fails on Linux/sparc (genprimopcode: parse error at)```
Build fails when building ghc 6.4.x (tested 6.4 and 6.4.1) on Linux/
sparc and using ghc 6.4 binaries for bootstrap:
mkdir stage1/ndpFlatten
mkdir stage1/iface
mkdir stage1/cmm
mkdir stage1/ghci
Creating main/Config.hs ...
done.
Cre...```
Build fails when building ghc 6.4.x (tested 6.4 and 6.4.1) on Linux/
sparc and using ghc 6.4 binaries for bootstrap:
mkdir stage1/ndpFlatten
mkdir stage1/iface
mkdir stage1/cmm
mkdir stage1/ghci
Creating main/Config.hs ...
done.
Creating stage1/ghc_boot_platform.h...
Done.
sparc-pld-linux-gcc -E -undef -traditional -P -I../includes -x c
prelude/primops.txt.pp | \
grep -v '^#pragma GCC' > prelude/primops.txt
../utils/genprimopcode/genprimopcode --data-decl < prelude/
primops.txt > primop-data-decl.hs-incl
genprimopcode: parse error at (line 579, column 1):
unexpected "\t"
expecting "primop", "section" or "thats_all_folks"
make[2]: *** [primop-data-decl.hs-incl] Error 1
make[2]: *** Deleting file `primop-data-decl.hs-incl'
make[1]: *** [boot] Error 1
make[1]: Leaving directory `/home/users/builder/rpm/BUILD/ghc-6.
4.1/ghc'
The same problem doesn't exists when using ghc 6.2.x for
bootstrapping (generated primops.txt is the same in both cases,
tested via md5sum). Problem doesn't exists on other arch like x86,
ppc, amd64, too.
```6.4.2nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/471Windows HGL Thread problems2019-07-07T19:17:50ZmjthomasWindows HGL Thread problems```
With CVS HEAD (19 October 2005 Australian morning)
the following minimal modifications to the HGL library
give a runtime error in the "GTest.exe" example program:
=======================================
...
handleEvent: Before get...```
With CVS HEAD (19 October 2005 Australian morning)
the following minimal modifications to the HGL library
give a runtime error in the "GTest.exe" example program:
=======================================
...
handleEvent: Before getMessage.
handleEvent: Before yield.
GTest.exe: internal error: resumeThread: thread not
found
Please report this as a bug to glasgow-haskell-
bugs@haskell.org,
or http://www.sourceforge.net/projects/ghc/
=======================================
Without those two putStrLn () calls, none of the three
example programs "GTests.exe", "Tests.exe"
or "HelloWorld.exe" displays a Window.
With those two putStrLn () calls, all three example
programs present their windows and both "Tests.exe"
and "HelloWorld.exe" appear to run perfectly (although
note that I have not seen them running at all other than
in these tests).
Cheers
Mike Thomas
=========================================
==========================
RCS
file: /home/cvs/root/fptools/libraries/HGL/Graphics/HGL/
Win32/WND.hs,v
retrieving revision 1.9
diff -r1.9 WND.hs
130a131
> putStrLn "handleEvent: Before yield."
133a135
> putStrLn "handleEvent: Before getMessage."
```Not GHChttps://gitlab.haskell.org/ghc/ghc/-/issues/472Supertyping of classes2019-07-07T19:17:50ZnobodySupertyping of classessee
[Supertyping Suggestion for Haskell](http://repetae.net/john/recent/out/supertyping.html)
example:
```
class Num a <= Group a where
(+) :: a -> a -> a
negate :: a -> a
```
apart from multiple inheritance, it could work like thi...see
[Supertyping Suggestion for Haskell](http://repetae.net/john/recent/out/supertyping.html)
example:
```
class Num a <= Group a where
(+) :: a -> a -> a
negate :: a -> a
```
apart from multiple inheritance, it could work like this:
```
import Prelude hiding ((+),negate)
import qualified Prelude ((+),negate)
class Group a where
(+) :: a -> a -> a
negate :: a -> a
instance Num a => Group a where
(+) = (Prelude.+)
negate = Prelude.negate
```
- coeus_at_gmx_dehttps://gitlab.haskell.org/ghc/ghc/-/issues/473getOpt' checks "non-option options"2019-07-07T19:17:50ZnobodygetOpt' checks "non-option options"```
When given RequireOrder the getOpt' function should not
parse options
following a non-option. But currently (as of version
6.4.1 of ghc) it
does. E.g. when parsing with RequireOrder and if
invalid-opt3 is not a
recognized option th...```
When given RequireOrder the getOpt' function should not
parse options
following a non-option. But currently (as of version
6.4.1 of ghc) it
does. E.g. when parsing with RequireOrder and if
invalid-opt3 is not a
recognized option then the following produces an error:
progname --valid-opt1 --valid-opt2 non-opt --invalid-opt3
However, anything after non-opt should not be parsed.
The problem can be
fixed as follows:
164c164
< procNextOpt (NonOpt x) RequireOrder =
([],x:rest,us,[])
---
> procNextOpt (NonOpt x) RequireOrder =
([],x:rest,[],[])
Best
Sebastian
```nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/474Debug.Trace.trace should work on Show2019-07-07T19:17:50ZjchDebug.Trace.trace should work on Show```
Debug.Trace.trace has type
trace :: String -> a -> a
which forces me to insert calls to show. Could it be
generalised to
trace :: Show a => a -> b -> b
Thanks,
Juliusz Chroboczek
``````
Debug.Trace.trace has type
trace :: String -> a -> a
which forces me to insert calls to show. Could it be
generalised to
trace :: Show a => a -> b -> b
Thanks,
Juliusz Chroboczek
```6.10 branchIan Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/475GHC and GHCi hang when compiling simple program2023-03-21T15:17:29ZnobodyGHC and GHCi hang when compiling simple program```
When interpreting the following four-line program using
GHCi on Windows, GHCi hangs, never completing
compilation and giving no output:
data Paradox = Roll (Paradox -> Int)
unroll (Roll x) = x
selfapply x = unroll x x
uhoh = selfapp...```
When interpreting the following four-line program using
GHCi on Windows, GHCi hangs, never completing
compilation and giving no output:
data Paradox = Roll (Paradox -> Int)
unroll (Roll x) = x
selfapply x = unroll x x
uhoh = selfapply (Roll selfapply)
If I add a simple main method of the form 'main = do
print (fst ("Hello world", uhoh))', and then compile
with GHC, it hangs as well. However, if I use a main
method which does not mention uhoh, such as 'main = do
print "Hello world"', and then compile with GHC,
compilation is successful. However, in this case,
compilation with GHCi still hangs.
As it happens, I have seen this bug in both versions
6.4 and 6.4.1 of GHC for Windows.
-Sridhar Ramesh, sramesh@andrew.cmu.edu
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | None |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedWon'tFix |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC and GHCi hang when compiling simple program","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"ResolvedWon'tFix","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"None","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nWhen interpreting the following four-line program using\nGHCi on Windows, GHCi hangs, never completing\ncompilation and giving no output:\n\ndata Paradox = Roll (Paradox -> Int)\nunroll (Roll x) = x\nselfapply x = unroll x x\nuhoh = selfapply (Roll selfapply)\n\nIf I add a simple main method of the form 'main = do\nprint (fst (\"Hello world\", uhoh))', and then compile\nwith GHC, it hangs as well. However, if I use a main\nmethod which does not mention uhoh, such as 'main = do\nprint \"Hello world\"', and then compile with GHC,\ncompilation is successful. However, in this case,\ncompilation with GHCi still hangs.\n\nAs it happens, I have seen this bug in both versions\n6.4 and 6.4.1 of GHC for Windows.\n\n-Sridhar Ramesh, sramesh@andrew.cmu.edu\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->nobodynobodyhttps://gitlab.haskell.org/ghc/ghc/-/issues/476HUnit treats failures as errors2019-07-07T19:17:49ZstefanheimannHUnit treats failures as errors```
HUnit treats a failure in a testcase as an error. I
attached a patch that fixes the problem. I tested the
patch with ghc and hugs.
``````
HUnit treats a failure in a testcase as an error. I
attached a patch that fixes the problem. I tested the
patch with ghc and hugs.
```Not GHCrichardg@richardg.namerichardg@richardg.name