January 2017 - ghc-tickets

[GHC] #13200: Old links to snapshot releases in GHC user's guide
by GHC 28 Jan '17

28 Jan '17

#13200: Old links to snapshot releases in GHC user's guide -------------------------------------+------------------------------------- Reporter: takenobu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Following links are out-of-date in GHC user's guide; secsion '2.4. GHC version numbering policy' [1]: * We may make snapshot releases of the current stable branch __available for download__ , * We may make snapshot releases of the HEAD __available for download__, Currently there are no snapshot releases? [1]: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/intro.html #ghc-version-numbering-policy -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13200> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13162: Testsuite driver has problems reliably removing files
by GHC 28 Jan '17

28 Jan '17

#13162: Testsuite driver has problems reliably removing files ----------------------------------------+---------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D2936 | Wiki Page: ----------------------------------------+---------------------------- Testsuite has sporadic failures while trying to remove the previous test output. This presents itself in a number of ways in the testsuite. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13162> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12661: Testsuite driver fails on Windows
by GHC 28 Jan '17

28 Jan '17

#12661: Testsuite driver fails on Windows --------------------------------------+--------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- I encountered the following failure in the testsuite driver while bringing up the new Windows build bot, {{{ PYTHON="python2" "python2" ../../driver/runtests.py -e ghc_compiler_always_flags="'-dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -dno- debug-output'" -e config.compiler_debugged=True -e ghc_with_native_codegen=1 -e config.have_vanilla=True -e config.have_dynamic=False -e config.have_profiling=False -e ghc_with_threaded_rts=1 -e ghc_with_dynamic_rts=0 -e config.have_interp=False -e config.unregisterised=False -e config.ghc_dynamic_by_default=False -e config.ghc_dynamic=False -e ghc_with_smp=1 -e ghc_with_llvm=0 -e windows=True -e darwin=False -e config.in_tree_compiler=True --threads=3 -e config.cleanup=True -e config.local=False --rootdir=. --configfile=../../config/ghc -e 'config.confdir="../../config"' -e 'config.platform="x86_64-unknown- mingw32"' -e 'config.os="mingw32"' -e 'config.arch="x86_64"' -e 'config.wordsize="64"' -e 'config.timeout=int() or config.timeout' -e 'config.exeext=".exe"' -e 'config.top="/home/drydock/ghc/testsuite"' --config 'compiler="/home/drydock/ghc/inplace/bin/ghc-stage1.exe"' --config 'ghc_pkg="/home/drydock/ghc/inplace/bin/ghc-pkg.exe"' --config 'haddock="/home/drydock/ghc/inplace/bin/haddock.exe"' --config 'hp2ps="/home/drydock/ghc/inplace/bin/hp2ps.exe"' --config 'hpc="/home/drydock/ghc/inplace/bin/hpc.exe"' --config 'gs="gs"' --config 'timeout_prog="../../timeout/install-inplace/bin/timeout.exe"' -e "config.stage=1" --summary-file "../../../testsuite_summary_stage1.txt" --no-print-summary 1 \ \ \ \ \ \ \ Warning: Ignoring request to use threads as running on Windows Traceback (most recent call last): File "../../driver/runtests.py", line 174, in <module> if mydll.kernel32.SetConsoleCP(65001) == 0: File "/usr/lib/python2.7/ctypes/__init__.py", line 435, in __getattr__ dll = self._dlltype(name) File "/usr/lib/python2.7/ctypes/__init__.py", line 365, in __init__ self._handle = _dlopen(self._name, mode) OSError: No such file or directory }}} From the repl it indeed seems that `ctypes.cdll.kernel32` is broken, {{{ $ python >>> import ctypes >>> ctypes.cdll.kernel32 Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib/python3.4/ctypes/__init__.py", line 421, in __getattr__ dll = self._dlltype(name) File "/usr/lib/python3.4/ctypes/__init__.py", line 351, in __init__ self._handle = _dlopen(self._name, mode) OSError: No such file or directory }}} Tamar, do you have any idea what is going on here? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12661> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23

[GHC] #13197: Perplexing levity polymorphism issue
by GHC 28 Jan '17

28 Jan '17

#13197: Perplexing levity polymorphism issue -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 (Type checker) | Keywords: typeable | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I would have expected this to compile since the levity polymorphism patch was merged, but sadly it seems the typechecker isn't quite clever enough yet (or perhaps I'm the not clever one), {{{#!hs {-# LANGUAGE GADTs, PolyKinds, PatternSynonyms, RankNTypes, TypeOperators, ViewPatterns #-} {-# LANGUAGE TypeInType #-} module Test where import Data.Kind import GHC.Exts data TypeRep (a :: k) where TypeCon :: String -> TypeRep a TypeApp :: forall k1 k2 (f :: k1 -> k2) (x :: k1). TypeRep f -> TypeRep x -> TypeRep (f x) TypeFun :: forall r1 r2 (a :: TYPE r1) (b :: TYPE r2). TypeRep a -> TypeRep b -> TypeRep (a -> b) data SomeTypeRep where SomeTypeRep :: forall k (a :: k). TypeRep a -> SomeTypeRep data (a :: k1) :~~: (b :: k2) where HRefl :: a :~~: a eqTypeRep :: TypeRep (a :: k1) -> TypeRep (b :: k2) -> Maybe (a :~~: b) eqTypeRep = undefined typeRepKind :: forall (k :: *). forall (a :: k). TypeRep a -> TypeRep k typeRepKind = undefined toApp :: SomeTypeRep -> SomeTypeRep -> Maybe SomeTypeRep toApp (SomeTypeRep f) (SomeTypeRep a) | TypeFun arg res <- typeRepKind f , Just HRefl <- arg `eqTypeRep` typeRepKind a = Just $ SomeTypeRep (TypeApp f a) toApp _ _ = Nothing }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13197> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13195: Ticks panic
by GHC 28 Jan '17

28 Jan '17

#13195: Ticks panic -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: MacOS X Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ Preprocessing test suite 'tests' for url-decoders-1... [1 of 1] Compiling Main ( tests/Main.hs, dist/build/tests /tests-tmp/Main.o ) <no location info>: error: ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-apple-darwin): Simplifier ticks exhausted When trying UnfoldingDone withForeignPtr1 To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 144969 }}} To reproduce the but, clone a repo under the specified commit from the following URL: https://github.com/nikita-volkov/url- decoders/tree/22410402a41b7524a1af03d78e381e9ea6354944 Then run the following command on the project: {{{ cabal configure --enable-tests && cabal build --ghc-options=-O2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13195> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11748: GHC runtime linker: fatal error: I found a duplicate definition for symbol
by GHC 27 Jan '17

27 Jan '17

#11748: GHC runtime linker: fatal error: I found a duplicate definition for symbol -------------------------------------+------------------------------------- Reporter: jeiea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (Linking) | Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I found GHC panic when using both inline-c and local Win32 package. I don't know whether it's related to #6107. {{{ D:\ghc-bug-maybe>stack build Win32a-2.3.1.0: build Win32a-2.3.1.0: copy/register ghc-bug-maybe-0.1.0.0: configure ghc-bug-maybe-0.1.0.0: build Completed 2 action(s). -- While building package ghc-bug-maybe-0.1.0.0 using: C:\AppData\Roaming\stack\setup-exe-cache\x86_64-windows\setup- Simple-Cabal-1.22.5.0-ghc-7.10.3.exe --builddir=.stack-work\dist\2672c1f3 build lib:ghc-bug-maybe exe:DualternativeH-exe --ghc-options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 Logs have been written to: D:\ghc-bug-maybe\.stack-work\logs\ghc-bug- maybe-0.1.0.0.log Configuring ghc-bug-maybe-0.1.0.0... Preprocessing library ghc-bug-maybe-0.1.0.0... [1 of 1] Compiling Lib ( src\Lib.hs, .stack- work\dist\2672c1f3\build\Lib.o ) GHC runtime linker: fatal error: I found a duplicate definition for symbol rgb whilst processing object file D:\ghc-bug-maybe\.stack-work\install\0464eb7a\lib\x86_64-windows- ghc-7.10.3\Win32a-2.3.1.0-JATTCAFziPX9UILXdwDTPA\HSWin32a-2.3.1.0-JATTCAFziPX9UILXdwDTPA.o This could be caused by: * Loading two different object files which export the same symbol * Specifying the same object file twice on the GHCi command line * An incorrect `package.conf' entry, causing some object to be loaded twice. ghc.exe: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-unknown-mingw32): loadObj "D:\\ghc-bug-maybe\\.stack- work\\install\\0464eb7a\\lib\\x86_64-windows- ghc-7.10.3\\Win32a-2.3.1.0-JATTCAFziPX9UILXdwDTPA\\HSWin32a-2.3.1.0-JATTCAFziPX9UILXdwDTPA.o": failed Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11748> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

[GHC] #9351: add ability to version symbols .c for packages with C code
by GHC 27 Jan '17

27 Jan '17

#9351: add ability to version symbols .c for packages with C code -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: backpack | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Let's consider an example: We have a haskell package with some C code imported in haskell: {{{ // a.h file int get_something(void); // a.c file #include "a.h" int get_something(void) { return 42; } // M.hs file module M where foreign import ccall "a.h get_something" :: IO Int }}} The problem here is we can't mix that package with other packages having global 'get_something' symbol. Sometimes it happens when a package copies part of implementation from another package with .c bits under different haskell namespace. Haskell parts would coexist freely, but not C symbols. Would be great if ghc would export some unique package identifier in a way C code could attach it to all exported symbols making linking possible. Something like that: {{{ // a.h file #include "HsFFI.h" /* #define FOR_HASKELL(__sym) package_id_##__sym */ int FOR_HASKELL(get_something)(void); // a.c file #include "a.h" int FOR_HASKELL(get_something)(void) { return 42; } // M.hs file module M where foreign import ccall-for-haskell "a.h get_something" :: IO Int }}} That way we explicitly mark symbol as inaccessible to external plain C code. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9351> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13082: GHCi segfaults with the flag -llibopenal, but not with -lopenal
by GHC 27 Jan '17

27 Jan '17

#13082: GHCi segfaults with the flag -llibopenal, but not with -lopenal -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.2 System (Linker) | Keywords: | Operating System: Windows Architecture: | Type of failure: GHCi crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I noticed this bug when I installed the `OpenAL` library from Hackage, ran it in GHCi 8.0.2, and segfaulted. Note that I've also reproduced the same error in GHC HEAD. To reproduce this bug, you'll need MSYS2. First install OpenAL: {{{ pacman -S mingw-w64-$(uname -m)-openal }}} With this Haskell file: {{{#!hs module Main (main) where import Foreign.C.Types foreign import ccall unsafe "alGetError" alGetError :: IO CInt main :: IO () main = alGetError >>= print }}} You can compile and run it without issue, using either the flag `-llibopenal` or `-lopenal` to link against OpenAL: {{{ $ ghc-8.0.2/bin/ghc -fforce-recomp -llibopenal OpenAL.hs [1 of 1] Compiling Main ( OpenAL.hs, OpenAL.o ) Linking OpenAL.exe ... $ ./OpenAL 40964 $ ghc-8.0.2/bin/ghc -fforce-recomp -lopenal OpenAL.hs $ ./OpenAL 40964 $ ghc/inplace/bin/ghc-stage2 -fforce-recomp -llibopenal OpenAL.hs [1 of 1] Compiling Main ( OpenAL.hs, OpenAL.o ) Linking OpenAL.exe ... $ ./OpenAL 40964 $ ghc/inplace/bin/ghc-stage2 -fforce-recomp -lopenal OpenAL.hs [1 of 1] Compiling Main ( OpenAL.hs, OpenAL.o ) Linking OpenAL.exe ... $ ./OpenAL 40964 }}} With GHCi, however, it gets funkier. If you pass the `-lopenal` flag, it seems to work OK: {{{ $ ghc-8.0.2/bin/runghc -lopenal OpenAL.hs 40964 $ ghc/inplace/bin/runghc -lopenal OpenAL.hs 40964 }}} But if you use the `-llibopenal` flag, it segfaults! {{{ $ runghc -llibopenal -v3 OpenAL.hs Glasgow Haskell Compiler, Version 8.0.2, stage 2 booted by GHC version 8.0.1 Using binary package database: C:\Users\RyanGlScott\Software\ghc-8.0.2\lib\package.conf.d\package.cache Using binary package database: C:\Users\RyanGlScott\AppData\Roaming\ghc\x86_64-mingw32-8.0.2\package.conf.d\package.cache loading package database C:\Users\RyanGlScott\Software\ghc-8.0.2\lib\package.conf.d loading package database C:\Users\RyanGlScott\AppData\Roaming\ghc\x86_64-mingw32-8.0.2\package.conf.d wired-in package ghc-prim mapped to ghc-prim-0.5.0.0 wired-in package integer-gmp mapped to integer-gmp-1.0.0.1 wired-in package base mapped to base-4.9.1.0 wired-in package rts mapped to rts wired-in package template-haskell mapped to template-haskell-2.11.1.0 wired-in package ghc mapped to ghc-8.0.2 wired-in package dph-seq not found. wired-in package dph-par not found. Hsc static flags: *** Parser [source]: !!! Parser [source]: finished in 0.00 milliseconds, allocated 0.212 megabytes *** Desugar: *** Simplify [expr]: !!! Simplify [expr]: finished in 0.00 milliseconds, allocated 0.133 megabytes *** CorePrep [expr]: !!! CorePrep [expr]: finished in 0.00 milliseconds, allocated 2.731 megabytes *** ByteCodeGen [Ghci1]: !!! ByteCodeGen [Ghci1]: finished in 0.00 milliseconds, allocated 0.182 megabytes *** gcc: "C:\Users\RyanGlScott\Software\ghc-8.0.2\lib/../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "-BC:\Users\RyanGlScott\Software\ghc-8.0.2\lib\ghc-prim-0.5.0.0" "--print- file-name" "mingw32.lib" *** gcc: "C:\Users\RyanGlScott\Software\ghc-8.0.2\lib/../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "-BC:\Users\RyanGlScott\Software\ghc-8.0.2\lib\ghc-prim-0.5.0.0" "--print- file-name" "libmingw32.lib" *** gcc: "C:\Users\RyanGlScott\Software\ghc-8.0.2\lib/../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "-BC:\Users\RyanGlScott\Software\ghc-8.0.2\lib\ghc-prim-0.5.0.0" "--print- file-name" "libmingw32.dll.a" *** gcc: "C:\Users\RyanGlScott\Software\ghc-8.0.2\lib/../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "-BC:\Users\RyanGlScott\Software\ghc-8.0.2\lib\ghc-prim-0.5.0.0" "--print- file-name" "mingw32.dll" *** gcc: "C:\Users\RyanGlScott\Software\ghc-8.0.2\lib/../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "-BC:\Users\RyanGlScott\Software\ghc-8.0.2\lib\ghc-prim-0.5.0.0" "--print- file-name" "libmingw32.dll" *** gcc: "C:\Users\RyanGlScott\Software\ghc-8.0.2\lib/../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "-BC:\Users\RyanGlScott\Software\ghc-8.0.2\lib\ghc-prim-0.5.0.0" "--print- file-name" "libmingw32.a" *** gcc: "C:\Users\RyanGlScott\Software\ghc-8.0.2\lib/../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "-BC:\Users\RyanGlScott\Software\ghc-8.0.2\lib\ghc-prim-0.5.0.0" "--print- file-name" "mingwex.lib" *** gcc: "C:\Users\RyanGlScott\Software\ghc-8.0.2\lib/../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "-BC:\Users\RyanGlScott\Software\ghc-8.0.2\lib\ghc-prim-0.5.0.0" "--print- file-name" "libmingwex.lib" *** gcc: "C:\Users\RyanGlScott\Software\ghc-8.0.2\lib/../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "-BC:\Users\RyanGlScott\Software\ghc-8.0.2\lib\ghc-prim-0.5.0.0" "--print- file-name" "libmingwex.dll.a" *** gcc: "C:\Users\RyanGlScott\Software\ghc-8.0.2\lib/../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "-BC:\Users\RyanGlScott\Software\ghc-8.0.2\lib\ghc-prim-0.5.0.0" "--print- file-name" "mingwex.dll" *** gcc: "C:\Users\RyanGlScott\Software\ghc-8.0.2\lib/../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "-BC:\Users\RyanGlScott\Software\ghc-8.0.2\lib\ghc-prim-0.5.0.0" "--print- file-name" "libmingwex.dll" *** gcc: "C:\Users\RyanGlScott\Software\ghc-8.0.2\lib/../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "-BC:\Users\RyanGlScott\Software\ghc-8.0.2\lib\ghc-prim-0.5.0.0" "--print- file-name" "libmingwex.a" Loading package ghc-prim-0.5.0.0 ... linking ... done. Loading package integer-gmp-1.0.0.1 ... linking ... done. *** gcc: "C:\Users\RyanGlScott\Software\ghc-8.0.2\lib/../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "-BC:\Users\RyanGlScott\Software\ghc-8.0.2\lib\base-4.9.1.0" "--print- file-name" "mingw32.lib" *** gcc: "C:\Users\RyanGlScott\Software\ghc-8.0.2\lib/../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "-BC:\Users\RyanGlScott\Software\ghc-8.0.2\lib\base-4.9.1.0" "--print- file-name" "libmingw32.lib" *** gcc: "C:\Users\RyanGlScott\Software\ghc-8.0.2\lib/../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "-BC:\Users\RyanGlScott\Software\ghc-8.0.2\lib\base-4.9.1.0" "--print- file-name" "libmingw32.dll.a" *** gcc: "C:\Users\RyanGlScott\Software\ghc-8.0.2\lib/../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "-BC:\Users\RyanGlScott\Software\ghc-8.0.2\lib\base-4.9.1.0" "--print- file-name" "mingw32.dll" *** gcc: "C:\Users\RyanGlScott\Software\ghc-8.0.2\lib/../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "-BC:\Users\RyanGlScott\Software\ghc-8.0.2\lib\base-4.9.1.0" "--print- file-name" "libmingw32.dll" *** gcc: "C:\Users\RyanGlScott\Software\ghc-8.0.2\lib/../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "-BC:\Users\RyanGlScott\Software\ghc-8.0.2\lib\base-4.9.1.0" "--print- file-name" "libmingw32.a" *** gcc: "C:\Users\RyanGlScott\Software\ghc-8.0.2\lib/../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "-BC:\Users\RyanGlScott\Software\ghc-8.0.2\lib\base-4.9.1.0" "--print- file-name" "mingwex.lib" *** gcc: "C:\Users\RyanGlScott\Software\ghc-8.0.2\lib/../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "-BC:\Users\RyanGlScott\Software\ghc-8.0.2\lib\base-4.9.1.0" "--print- file-name" "libmingwex.lib" *** gcc: "C:\Users\RyanGlScott\Software\ghc-8.0.2\lib/../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "-BC:\Users\RyanGlScott\Software\ghc-8.0.2\lib\base-4.9.1.0" "--print- file-name" "libmingwex.dll.a" *** gcc: "C:\Users\RyanGlScott\Software\ghc-8.0.2\lib/../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "-BC:\Users\RyanGlScott\Software\ghc-8.0.2\lib\base-4.9.1.0" "--print- file-name" "mingwex.dll" *** gcc: "C:\Users\RyanGlScott\Software\ghc-8.0.2\lib/../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "-BC:\Users\RyanGlScott\Software\ghc-8.0.2\lib\base-4.9.1.0" "--print- file-name" "libmingwex.dll" *** gcc: "C:\Users\RyanGlScott\Software\ghc-8.0.2\lib/../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "-BC:\Users\RyanGlScott\Software\ghc-8.0.2\lib\base-4.9.1.0" "--print- file-name" "libmingwex.a" Loading package base-4.9.1.0 ... linking ... done. *** gcc: "C:\Users\RyanGlScott\Software\ghc-8.0.2\lib/../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "--print-file-name" "libopenal.lib" *** gcc: "C:\Users\RyanGlScott\Software\ghc-8.0.2\lib/../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "--print-file-name" "liblibopenal.lib" *** gcc: "C:\Users\RyanGlScott\Software\ghc-8.0.2\lib/../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "--print-file-name" "liblibopenal.dll.a" *** gcc: "C:\Users\RyanGlScott\Software\ghc-8.0.2\lib/../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "--print-file-name" "libopenal.dll" *** gcc: "C:\Users\RyanGlScott\Software\ghc-8.0.2\lib/../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "--print-file-name" "liblibopenal.dll" *** gcc: "C:\Users\RyanGlScott\Software\ghc-8.0.2\lib/../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "--print-file-name" "liblibopenal.a" Loading object (dynamic) libopenal ... ghc.exe: addDLL: libopenal (Win32 error 126): The specified module could not be found. }}} At that point, GHC segfaults and force-quits (if you run this on PowerShell, a "ghc.exe has stopped working" message box will pop up). I don't know if #12771 is relevant. You can't test this on GHC 8.0.1 or earlier because they didn't have support for Windows import libs, which OpenAL uses. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13082> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13183: Template Haskell needlessly pretty-prints empty instance contexts
by GHC 27 Jan '17

27 Jan '17

#13183: Template Haskell needlessly pretty-prints empty instance contexts -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Template | Version: 8.1 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This code: {{{#!hs {-# LANGUAGE TemplateHaskell #-} {-# OPTIONS -ddump-splices #-} module Bug where $([d| class Foo a instance Foo Int |]) }}} Used to pretty-print like this on GHC 8.0.2: {{{ Bug2.hs:(5,3)-(7,6): Splicing declarations [d| class Foo_a13B a_a13C instance Foo_a13B Int |] ======> class Foo_a3Jo a_a3Jp instance Foo_a3Jo Int }}} But on GHC HEAD, it prints a redundant instance context! {{{ Bug2.hs:(5,3)-(7,6): Splicing declarations [d| class Foo_a1eh a_a1ei instance Foo_a1eh Int |] ======> class Foo_a4ly a_a4lz instance () => Foo_a4ly Int }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13183> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12805: Generalise type of asProxyTypeOf
by GHC 27 Jan '17

27 Jan '17

#12805: Generalise type of asProxyTypeOf -------------------------------------+------------------------------------- Reporter: tomjaguarpaw | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 8.0.1 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Could we please generalise the type of `asProxyTypeOf` to `asProxyTypeOf :: a -> proxy a -> a`? https://hackage.haskell.org/package/base-4.9.0.0/docs/Data- Proxy.html#v:asProxyTypeOf -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12805> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10