June 2014 - ghc-tickets

[GHC] #8652: Cross-compiling broken for ARM/Linux target
by GHC 07 Jan '16

07 Jan '16

#8652: Cross-compiling broken for ARM/Linux target ----------------------------+---------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Linux Architecture: arm | Type of failure: Building GHC failed Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+---------------------------------------- I've attempted to cross compile GHC HEAD on Ubuntu 13.10 with ubuntu's hard-float tool-chain and LLVM. I've configured GHC with: {{{ $ ./configure --target=arm-linux-gnueabihf }}} and compiling by make works till it fails with: {{{ inplace/bin/deriveConstants --gen-header -o includes/dist- derivedconstants/header/DerivedConstants.h --tmpdir includes/dist- derivedconstants/header/ --gcc-program "/usr/bin/gcc" --gcc-flag -fno- stack-protector --gcc-flag -Iincludes --gcc-flag -Iincludes/dist --gcc- flag -Iincludes/dist-derivedconstants/header --gcc-flag -Iincludes/dist- ghcconstants/header --gcc-flag -Irts --gcc-flag -fcommon --nm-program "/usr/bin/arm-linux-gnueabihf-nm" /usr/bin/arm-linux-gnueabihf-nm: includes/dist- derivedconstants/header/tmp.o: File format not recognized deriveConstants: readProcess: /usr/bin/arm-linux-gnueabihf-nm "includes /dist-derivedconstants/header/tmp.o" (exit 1): failed make[1]: *** [includes/dist-derivedconstants/header/DerivedConstants.h] Error 1 }}} As a workaround for this issue, it's possible to use --with-gcc= and this way deriveConstants gets the right cross GCC. Looks like a bug somewhere in make machinery or configure itself. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8652> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8560: undeducable Typeable error with data kinds when deriving Data for GADT in GHC version 7.7.20131122
by GHC 05 Jan '16

05 Jan '16

#8560: undeducable Typeable error with data kinds when deriving Data for GADT in GHC version 7.7.20131122 ------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- This may be an artifact of issue #8128 (see https://ghc.haskell.org/trac/ghc/ticket/8128#comment:5) but I'm seeing examples involving data kinds where Typeable isn't deducible. This could be an artifact of other problems, BUT since with 7.7 onwards, we have baked in polykinded Typeable, things should always "just work™" right? the error with current head is as follows (and i'm attaching the code + current finger print too) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8560> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #8182: Parser.y.pp needs special treatment with -fcmm-sink
by GHC 31 Dec '15

31 Dec '15

#8182: Parser.y.pp needs special treatment with -fcmm-sink ------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Build System | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- This bug is really more of a reminder, but it's critical for the 7.8.1 release. Right now, `Parser.y.pp` uses a very weird hack to pass `-fcmm-sink` to the compiler. Here's the relevant comment: {{{ -- CPP tricks because we want the directives in the output of the -- first CPP pass. -- -- Clang note, 6/17/2013 by aseipp: It is *extremely* important (for -- some reason) that there be a line of whitespace between the two -- definitions here, and the subsequent use of __IF_GHC_77__ - this -- seems to be a bug in clang or something, where having the line of -- whitespace will make the preprocessor correctly format the rendered -- lines in the 'two step' CPP pass. No, this is not a joke. #define __IF_GHC_77__ #if __GLASGOW_HASKELL__ >= 707 #define __ENDIF__ #endif __IF_GHC_77__ -- Required on x86 to avoid the register allocator running out of -- stack slots when compiling this module with -fPIC -dynamic. {-# OPTIONS_GHC -fcmm-sink #-} __ENDIF__ }}} This is because the parser is first preprocessed before being run with GHC (which again preprocesses,) so we want the resulting `#ifdef` in the final `.hs` file. Things to note: * We really shouldn't be doing this, it's amazingly fragile. I think the correct thing to do is to ensure the build system correctly passes `-fcmm- sink` during the stage[2,3] build. * `./configure.ac` needs to check to see if the bootstrapping compiler is `ghc >= 7.7` (or `7.8`) and if it is, ''also'' pass `-fcmm-sink` during the stage1 build. * This hack needs to be removed once we can rely on >= 7.8 for bootstrap. Probably something like the hypothetical 7.12-7.14 timeframe. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8182> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9237: GHC not recognizing "-llibrary" form in implicit linker scripts
by GHC 31 Dec '15

31 Dec '15

#9237: GHC not recognizing "-llibrary" form in implicit linker scripts ----------------------------------+--------------------------------------- Reporter: mmikolajczyk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------------- I have tried to build accelerate-llvm package and encountered an invalid behaviour of linker. I am using Arch Linux and GHC 7.8.2. I have installed llvm-general-3.4.2.2 and llvm-general-pure-3.4.2.2 from this branch: https://github.com/tvh/llvm- general/tree/curatedTargetMachine, and accelerate from HEAD to common sandbox. Then I tried to build accelerate-llvm using the sandbox and got this output during building: {{{ Building accelerate-llvm-0.15.0.0... Preprocessing library accelerate-llvm-0.15.0.0... [ 1 of 30] Compiling Data.Range.Range ( Data/Range/Range.hs, dist/build/Data/Range/Range.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package primitive-0.5.3.0 ... linking ... done. Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package old-locale-1.0.0.6 ... linking ... done. Loading package time-1.4.2 ... linking ... done. Loading package vector-0.10.11.0 ... linking ... done. Loading package mwc-random-0.13.1.2 ... linking ... done. Loading package bytestring-0.10.4.0 ... linking ... done. Loading package containers-0.5.5.1 ... linking ... done. Loading package transformers-0.4.1.0 ... linking ... done. Loading package mtl-2.2.1 ... linking ... done. Loading package text-1.1.1.3 ... linking ... done. Loading package parsec-3.1.5 ... linking ... done. Loading package unix-2.7.0.1 ... linking ... done. Loading package setenv-0.1.1.1 ... linking ... done. Loading package pretty-1.1.1.1 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package llvm-general-pure-3.4.2.2 ... linking ... done. Loading package utf8-string-0.3.8 ... linking ... done. Loading package llvm-general-3.4.2.2 ... <command line>: can't load .so/.DLL for: /usr/lib/libcurses.so (-lncursesw: cannot open shared object file: No such file or directory) }}} After some searching I narrowed down the issue to `/usr/lib/libcurses.so` file. In Arch, this file contains `INPUT(-lncursesw)`. If I change it to `INPUT(libncursesw.so)` or `INPUT(/usr/lib/libncursesw.so)` it works fine. Symlinking `/usr/lib/libcurses.so` to `/usr/lib/libncursesw.so` also works. This bug seems to be connected to #2615. GHC still doesn't follow `INPUT` commands containing `-llibrary` form. Ld documentation allows this: {{{If you use `INPUT (-lfile)', ld will transform the name to libfile.a, as with the command line argument `-l'}}}. (https://sourceware.org/binutils/docs/ld/File-Commands.html) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9237> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #9176: GHC not generating dyn_hi files
by GHC 25 Dec '15

25 Dec '15

#9176: GHC not generating dyn_hi files ----------------------------------+---------------------------- Reporter: heatsink | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: dynamic | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------- In some situations, GHC terminates successfully and generates a `dyn_o` file, but no `dyn_hi` file. As a result, a package that contains a library seems to build successfully, but fails to install. I narrowed the problem down to the following test case. I compile it with `ghc --make -shared -dynamic-too Foo`. It seems to be Parsec-related, but I don't know how to trace it further. {{{ module Foo where import Text.ParserCombinators.Parsec }}} Parsec was installed with `cabal install --reinstall --user --enable- shared --disable-library-profiling parsec-3.1.5`. Some Parsec modules do not cause the missing `dyn_hi` file. For instance, all output files are created if Foo imports `Text.Parsec.Pos` instead of `Text.ParserCombinators.Parsec`. GHC was built from source, commit 9e10963e394680dbb1b964c66cb428a2aa03df09, compiled by GHC 7.6.3 with XCode 5.1.1 on OS X 10.9.3. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9176> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #8347: Add a Strict LANGUAGE pragma
by GHC 16 Dec '15

16 Dec '15

#8347: Add a Strict LANGUAGE pragma ------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- A `Strict` `LANGUAGE` pragma would allow us to experiment with writing in a strict sub-language. Since this pragma works on a per module basis, it needs to be modular. I propose the following semantics: * Patterns are strict at the top-level, as if they had a top-level bang, unless an explicit ~ is used to make the pattern lazy. * Functions evaluate their parameters to WHNF. * Data type fields are strict (as if they had a bang-pattern). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8347> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #8424: quasi-quotes have carriage returns on Windows
by GHC 16 Dec '15

16 Dec '15

#8424: quasi-quotes have carriage returns on Windows ------------------------------------+------------------------------------- Reporter: GregWeber | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- A Windows user rerported using Data.Text.IO.writeFile to write out quasi- quoted text. writeFile automatically translates '\r' to "\r\n", so the user ended up writing out "\r\r\n" to a file. Haskell seems to be adopting the policy or removing '\r' from Haskell land. Is there any reason why quasi-quotes should not automatically strip carriage returns? I asked this question on ghc-users and there was no response. I am willing to make this fix if it is deemed appropriate. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8424> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8294: T7478 fails on Mac OS X with "unexpected bindingNone" from ld
by GHC 15 Dec '15

15 Dec '15

#8294: T7478 fails on Mac OS X with "unexpected bindingNone" from ld -----------------------------------+--------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.7 Keywords: | Operating System: MacOS X Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: T7478 Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- (Tangentially, the test script was swallowing up relevant output; you need to get rid of the output hook to see any debugging output from GHC proper). Linker step fails: {{{ *** Linker: /usr/bin/gcc -m64 -fno-stack-protector -DTABLES_NEXT_TO_CODE -m64 -v -o A -Wl,-no_compact_unwind C.o -L/Users/ezyang/Dev/ghc-init/libraries/base /dist-install/build -L/Users/ezyang/Dev/ghc-init/libraries/integer-gmp /dist-install/build -L/Users/ezyang/Dev/ghc-init/libraries/ghc-prim/dist- install/build -L/Users/ezyang/Dev/ghc-init/rts/dist/build /var/folders/l8/1lth36c11yg8dv_3kz779_th0000gn/T/ghc26290_0/ghc26290_10.o -lHSbase-4.7.0.0-ghc7.7.20130913 -lHSinteger-gmp-0.5.1.0-ghc7.7.20130913 -lHSghc-prim-0.3.1.0-ghc7.7.20130913 -lHSrts-ghc7.7.20130913 -lffi -liconv -lm -ldl -Wl,-u,_ghczmprim_GHCziTypes_Izh_static_info -Wl,-u,_ghczmprim_GHCziTypes_Czh_static_info -Wl,-u,_ghczmprim_GHCziTypes_Fzh_static_info -Wl,-u,_ghczmprim_GHCziTypes_Dzh_static_info -Wl,-u,_base_GHCziPtr_Ptr_static_info -Wl,-u,_ghczmprim_GHCziTypes_Wzh_static_info -Wl,-u,_base_GHCziInt_I8zh_static_info -Wl,-u,_base_GHCziInt_I16zh_static_info -Wl,-u,_base_GHCziInt_I32zh_static_info -Wl,-u,_base_GHCziInt_I64zh_static_info -Wl,-u,_base_GHCziWord_W8zh_static_info -Wl,-u,_base_GHCziWord_W16zh_static_info -Wl,-u,_base_GHCziWord_W32zh_static_info -Wl,-u,_base_GHCziWord_W64zh_static_info -Wl,-u,_base_GHCziStable_StablePtr_static_info -Wl,-u,_ghczmprim_GHCziTypes_Izh_con_info -Wl,-u,_ghczmprim_GHCziTypes_Czh_con_info -Wl,-u,_ghczmprim_GHCziTypes_Fzh_con_info -Wl,-u,_ghczmprim_GHCziTypes_Dzh_con_info -Wl,-u,_base_GHCziPtr_Ptr_con_info -Wl,-u,_base_GHCziPtr_FunPtr_con_info -Wl,-u,_base_GHCziStable_StablePtr_con_info -Wl,-u,_ghczmprim_GHCziTypes_False_closure -Wl,-u,_ghczmprim_GHCziTypes_True_closure -Wl,-u,_base_GHCziPack_unpackCString_closure -Wl,-u,_base_GHCziIOziException_stackOverflow_closure -Wl,-u,_base_GHCziIOziException_heapOverflow_closure -Wl,-u,_base_ControlziExceptionziBase_nonTermination_closure -Wl,-u,_base_GHCziIOziException_blockedIndefinitelyOnMVar_closure -Wl,-u,_base_GHCziIOziException_blockedIndefinitelyOnSTM_closure -Wl,-u,_base_ControlziExceptionziBase_nestedAtomically_closure -Wl,-u,_base_GHCziWeak_runFinalizzerBatch_closure -Wl,-u,_base_GHCziTopHandler_flushStdHandles_closure -Wl,-u,_base_GHCziTopHandler_runIO_closure -Wl,-u,_base_GHCziTopHandler_runNonIO_closure -Wl,-u,_base_GHCziConcziIO_ensureIOManagerIsRunning_closure -Wl,-u,_base_GHCziConcziIO_ioManagerCapabilitiesChanged_closure -Wl,-u,_base_GHCziConcziSync_runSparks_closure -Wl,-u,_base_GHCziConcziSignal_runHandlers_closure -Wl,-search_paths_first Using built-in specs. Target: i686-apple-darwin11 Configured with: /private/var/tmp/llvmgcc42/llvmgcc42-2336.11~182/src/configure --disable- checking --enable-werror --prefix=/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2 --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program- prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with- slibdir=/usr/lib --build=i686-apple-darwin11 --enable- llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.11~182/dst- llvmCore/Developer/usr/local --program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11 --target=i686-apple-darwin11 --with-gxx- include-dir=/usr/include/c++/4.2.1 Thread model: posix gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00) /usr/llvm-gcc-4.2/bin/../libexec/gcc/i686-apple-darwin11/4.2.1/collect2 -dynamic -arch x86_64 -macosx_version_min 10.8.3 -weak_reference_mismatches non-weak -o A -lcrt1.10.6.o -L/Users/ezyang/Dev /ghc-init/libraries/base/dist-install/build -L/Users/ezyang/Dev/ghc- init/libraries/integer-gmp/dist-install/build -L/Users/ezyang/Dev/ghc- init/libraries/ghc-prim/dist-install/build -L/Users/ezyang/Dev/ghc- init/rts/dist/build -L/usr/llvm-gcc-4.2/bin/../lib/gcc/i686-apple- darwin11/4.2.1/x86_64 -L/Applications/Xcode.app/Contents/Developer/usr /llvm-gcc-4.2/lib/gcc/i686-apple-darwin11/4.2.1/x86_64 -L/usr/llvm- gcc-4.2/bin/../lib/gcc/i686-apple-darwin11/4.2.1 -L/usr/llvm- gcc-4.2/bin/../lib/gcc -L/Applications/Xcode.app/Contents/Developer/usr /llvm-gcc-4.2/lib/gcc/i686-apple-darwin11/4.2.1 -L/usr/llvm- gcc-4.2/bin/../lib/gcc/i686-apple-darwin11/4.2.1/../../.. -L/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2/lib/gcc/i686 -apple-darwin11/4.2.1/../../.. -no_compact_unwind C.o /var/folders/l8/1lth36c11yg8dv_3kz779_th0000gn/T/ghc26290_0/ghc26290_10.o -lHSbase-4.7.0.0-ghc7.7.20130913 -lHSinteger-gmp-0.5.1.0-ghc7.7.20130913 -lHSghc-prim-0.3.1.0-ghc7.7.20130913 -lHSrts-ghc7.7.20130913 -lffi -liconv -lm -ldl -u _ghczmprim_GHCziTypes_Izh_static_info -u _ghczmprim_GHCziTypes_Czh_static_info -u _ghczmprim_GHCziTypes_Fzh_static_info -u _ghczmprim_GHCziTypes_Dzh_static_info -u _base_GHCziPtr_Ptr_static_info -u _ghczmprim_GHCziTypes_Wzh_static_info -u _base_GHCziInt_I8zh_static_info -u _base_GHCziInt_I16zh_static_info -u _base_GHCziInt_I32zh_static_info -u _base_GHCziInt_I64zh_static_info -u _base_GHCziWord_W8zh_static_info -u _base_GHCziWord_W16zh_static_info -u _base_GHCziWord_W32zh_static_info -u _base_GHCziWord_W64zh_static_info -u _base_GHCziStable_StablePtr_static_info -u _ghczmprim_GHCziTypes_Izh_con_info -u _ghczmprim_GHCziTypes_Czh_con_info -u _ghczmprim_GHCziTypes_Fzh_con_info -u _ghczmprim_GHCziTypes_Dzh_con_info -u _base_GHCziPtr_Ptr_con_info -u _base_GHCziPtr_FunPtr_con_info -u _base_GHCziStable_StablePtr_con_info -u _ghczmprim_GHCziTypes_False_closure -u _ghczmprim_GHCziTypes_True_closure -u _base_GHCziPack_unpackCString_closure -u _base_GHCziIOziException_stackOverflow_closure -u _base_GHCziIOziException_heapOverflow_closure -u _base_ControlziExceptionziBase_nonTermination_closure -u _base_GHCziIOziException_blockedIndefinitelyOnMVar_closure -u _base_GHCziIOziException_blockedIndefinitelyOnSTM_closure -u _base_ControlziExceptionziBase_nestedAtomically_closure -u _base_GHCziWeak_runFinalizzerBatch_closure -u _base_GHCziTopHandler_flushStdHandles_closure -u _base_GHCziTopHandler_runIO_closure -u _base_GHCziTopHandler_runNonIO_closure -u _base_GHCziConcziIO_ensureIOManagerIsRunning_closure -u _base_GHCziConcziIO_ioManagerCapabilitiesChanged_closure -u _base_GHCziConcziSync_runSparks_closure -u _base_GHCziConcziSignal_runHandlers_closure -search_paths_first -lSystem -lgcc -lSystem ld: warning: PIE disabled. Absolute addressing (perhaps -mdynamic-no-pic) not allowed in code signed PIE, but used in _Main_main_info from C.o. To fix this warning, don't compile with -mdynamic-no-pic or link with -Wl,-no_pie final section layout: __TEXT/__text addr=0x100000D30, size=0x00000218, fileOffset=0x00000D30, type=1 __TEXT/__stubs addr=0x100000F48, size=0x0000001E, fileOffset=0x00000F48, type=27 __TEXT/__stub_helper addr=0x100000F68, size=0x00000042, fileOffset=0x00000F68, type=31 __TEXT/__eh_frame addr=0x100000FB0, size=0x00000048, fileOffset=0x00000FB0, type=18 __DATA/__program_vars addr=0x100001000, size=0x00000028, fileOffset=0x00001000, type=29 __DATA/__got addr=0x100001028, size=0x00000020, fileOffset=0x00001028, type=28 __DATA/__nl_symbol_ptr addr=0x100001048, size=0x00000010, fileOffset=0x00001048, type=28 __DATA/__la_symbol_ptr addr=0x100001058, size=0x00000028, fileOffset=0x00001058, type=26 __DATA/__data addr=0x100001080, size=0x00000040, fileOffset=0x00001080, type=0 __DATA/__const addr=0x1000010C0, size=0x00000018, fileOffset=0x000010C0, type=0 __DATA/__common addr=0x1000010D8, size=0x00000020, fileOffset=0x00000000, type=24 ld: unexpected bindingNone in '_Main_main_info' from C.o for architecture x86_64 collect2: ld returned 1 exit status T7478: T7478: phase `Linker' failed (exitcode = 1) }}} Unfortunately, I don't know what a bindingNone is... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8294> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8566: Panic with kindFunResult
by GHC 12 Dec '15

12 Dec '15

#8566: Panic with kindFunResult ------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The following program: {{{ {-# LANGUAGE DataKinds #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE MultiParamTypeClasses #-} module Bug where data U (s :: *) = forall k. AA k [U s] data I (u :: U *) (r :: [*]) :: * where A :: I (AA t as) r -- fs unused, but needs to be present for the bug class C (u :: U *) (r :: [*]) (fs :: [*]) where c :: I u r -> I u r instance (C (AA (t (I a ps)) as) ps fs) => C (AA t (a ': as)) ps fs where c A = c undefined }}} crashes a fresh copy of GHC HEAD with the following: {{{ ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20131126 for i386-unknown-linux): kindFunResult k1{tv a24f} [ssk] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8566> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #9017: Confusing error message with PolyKinds
by GHC 12 Dec '15

12 Dec '15

#9017: Confusing error message with PolyKinds ------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Consider the following example code: {{{ import Control.Arrow foo :: a b (m b) foo = arr return }}} if we typecheck this we rightly get two errors about missing instances (Arrow a, Monad m). However, if we enable `PolyKinds` we get the following error message: {{{ T.hs:4:7: Kind incompatibility when matching types: a0 :: * -> * -> * a :: k1 -> k -> * Expected type: a b (m b) Actual type: a0 b0 (m0 b0) Relevant bindings include foo :: a b (m b) (bound at T.hs:4:1) In the expression: arr return In an equation for ‘foo’: foo = arr return }}} I can ''sort of'' see where this is coming from if I think really hard :), so perhaps it's not a bug per se, but it's definitely confusing; and it's a pity that a type error (forgotten type qualifier) is reported as a kind error. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9017> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5