June 2014 - ghc-tickets

[GHC] #8403: Pretty-printing of long types
by GHC 23 Jan '16

23 Jan '16

#8403: Pretty-printing of long types ------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Low priority, but this ghci output could be more packed. {{{ λ> :t (,,,,,,,,,,,,,,,,,,,,,,,) (,,,,,,,,,,,,,,,,,,,,,,,) :: a -> b -> c -> d -> e -> f -> g -> h -> i -> j -> k -> l -> m -> n -> o -> p -> q -> r -> s -> t -> u -> v -> w -> x -> (a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, q, r, s, t, u, v, w, x) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8403> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8064: Warning out when "undefined" value has been used.
by GHC 23 Jan '16

23 Jan '16

#8064: Warning out when "undefined" value has been used. ------------------------------------+------------------------------------- Reporter: freizl | 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: | ------------------------------------+------------------------------------- Programmer may like to use "undefined" to define a function or value, which usually means "later implementation". However, people might forget to implement it thus cause run time error. Wish GHC will show some warning/errors at compilation. This idea comes from this article (http://www.devalot.com/articles/2013/07 /why-haskell.html) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8064> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8422: type nats solver is too weak!
by GHC 23 Jan '16

23 Jan '16

#8422: type nats solver is too weak! -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler (Type | Version: 7.7 checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: Unknown/Multiple | valid program Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- I just built ghc HEAD today, and the type nat solver can't handle the attached program, which *should* be simple to check! (and while I could use unsafeCoerce to "prove" it correct, that defeats the purpose of having the type nat solver!) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8422> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8618: can't load .so/.DLL
by GHC 22 Jan '16

22 Jan '16

#8618: can't load .so/.DLL -----------------------------------+--------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- This happens in a fresh sandbox: {{{ % cabal install uniplate -j Resolving dependencies... Configuring syb-0.4.1... Configuring text-1.0.0.0... Building syb-0.4.1... Building text-1.0.0.0... Installed syb-0.4.1 Installed text-1.0.0.0 Configuring hashable-1.2.1.0... Building hashable-1.2.1.0... Installed hashable-1.2.1.0 Configuring unordered-containers-0.2.3.3... Building unordered-containers-0.2.3.3... Installed unordered-containers-0.2.3.3 Configuring uniplate-1.6.12... Building uniplate-1.6.12... Failed to install uniplate-1.6.12 Last 10 lines of the build log ( /home/feuerbach/.cabal/logs/uniplate-1.6.12.log ): Preprocessing library uniplate-1.6.12... [ 1 of 21] Compiling Data.Generics.Uniplate.Data.Instances ( Data/Generics/Uniplate/Data/Instances.hs, dist/build/Data/Generics/Uniplate/Data/Instances.o ) [ 2 of 21] Compiling Data.Generics.Uniplate.Internal.Utils ( Data/Generics/Uniplate/Internal/Utils.hs, dist/build/Data/Generics/Uniplate/Internal/Utils.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package bytestring-0.10.4.0 ... linking ... done. Loading package text-1.0.0.0 ... <command line>: can't load .so/.DLL for: libHStext-1.0.0.0.so (libHStext-1.0.0.0.so: cannot open shared object file: No such file or directory) cabal: Error: some packages failed to install: uniplate-1.6.12 failed during the building phase. The exception was: ExitFailure 1 }}} I have shared: False in cabal.config, so it's not surprising that libHStext-1.0.0.0.so is not found. What is surprising is that it's needed. uniplate doesn't use TemplateHaskell, from what I can tell. This is GHC 7.7.20131217. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8618> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #8586: internal error: evacuate(static): strange closure type 5189
by GHC 22 Jan '16

22 Jan '16

#8586: internal error: evacuate(static): strange closure type 5189 ----------------------------+------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: crash | Operating System: Windows Architecture: x86 | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+------------------------------- I cannot reproduce this reliably, but it happened once. Here’s what I did: * Install Yesod * Scaffold a blank Yesod project with no DB * Run GHCi * :l Foundation.hs * :info AForm Output: {{{ newtype AForm m a = AForm {unAForm :: (HandlerSite m, [Text]) -> Maybe (Env, FileEnv) -> Ints -> m (FormResult a, [FieldView (HandlerSite m)] -> [FieldView (HandlerSite m)], Ints, Enctype)} -- Defined in `Yesod.Form.Types' instance Monad m => Functor (AForm m) -- Defined in `Yesod.Form.Types' instance (Monad m, Monoid a) => Monoid (AForm m a) -- Defined in `Yesod.Form.Types' instance MonadTransghc.exe: internal error: evacuate(static): strange closure type 5189 (GHC version 7.6.3 for i386_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. }}} (P.S. I chose 'x86' for the Architecture because it’s running as 32-bit, but I’m actually using 64-bit Windows.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8586> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8605: Alternative, guard-like syntax for view patterns
by GHC 22 Jan '16

22 Jan '16

#8605: Alternative, guard-like syntax for view patterns ------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Implement the alternative syntax for view patterns described on the ViewPatternsAlternative wiki page -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8605> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8907: Un-zonked kind variable passes through type checker
by GHC 22 Jan '16

22 Jan '16

#8907: Un-zonked kind variable passes through type checker -------------------------------------------+------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.1-rc2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- I have this module: {{{ {-# LANGUAGE PolyKinds #-} module Bug where data Poly a }}} Now, I say this: {{{ > ghc Bug.hs -fforce-recomp -dppr-debug -fprint-explicit-foralls -ddump-tc }}} The following is produced: {{{ [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) TYPE SIGNATURES TYPE CONSTRUCTORS main:Bug.Poly{tc rn2} :: k{tv ao6} [sk] -> ghc-prim:GHC.Prim.*{(w) tc 34d} data Poly{tc} (k::ghc-prim:GHC.Prim.BOX{(w) tc 347}) (a::k) No C type associated Roles: [nominal, phantom] RecFlag NonRecursive, Not promotable = FamilyInstance: none COERCION AXIOMS Dependent modules: [] Dependent packages: [base, ghc-prim, integer-gmp] ==================== Typechecker ==================== }}} My concern is the `[sk]` that appears after the kind variable `k_ao6`. It would appear that a ''skolem'' type variable passes out of the type- checker and is used as the binder for polymorphic kind of `Poly`. Should this get zonked somewhere? My guess is that there is no way to get this apparent misbehavior to trigger some real failure, given that the variable will be substituted away before much else happens. Yet, when I saw a skolem appear in a similar position after modifying the type-checker, I was sure I had done something wrong somewhere. So, is this intended or accidental behavior? If accidental, should we be scared? If we needn't be scared, I'm happy to close this as wontfix, but a Note would probably be helpful somewhere. Apologies if that Note is already written and I missed it! The same behavior is present in 7.8.1 RC 2 and in HEAD. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8907> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8666: integer-gmp fails to compile on Debian Squeeze
by GHC 22 Jan '16

22 Jan '16

#8666: integer-gmp fails to compile on Debian Squeeze -----------------------------------+--------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries | Version: 7.7 (other) | Operating System: Linux Keywords: | Type of failure: Compile-time crash Architecture: x86_64 (amd64) | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- I get an error when compiling recent HEAD on Debian Squeeze: {{{ "inplace/bin/ghc-stage1" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H64m -O0 -fasm -package-name integer-gmp-0.5.1.0 -hide-all- packages -i -ilibraries/integer-gmp/. -ilibraries/integer-gmp/dist- install/build -ilibraries/integer-gmp/dist-install/build/autogen -Ilibraries/integer-gmp/dist-install/build -Ilibraries/integer-gmp/dist- install/build/autogen -Ilibraries/integer-gmp/. -optP-include -optPlibraries/integer-gmp/dist-install/build/autogen/cabal_macros.h -package ghc-prim-0.3.1.0 -Wall -package-name integer-gmp -XHaskell2010 -O -fasm -no-user-package-db -rtsopts -Ilibraries/integer- gmp/mkGmpDerivedConstants/dist -odir libraries/integer-gmp/dist- install/build -hidir libraries/integer-gmp/dist-install/build -stubdir libraries/integer-gmp/dist-install/build -fno-use-rpaths -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../ghc-prim-0.3.1.0' -optl-Wl,-rpath -optl- Wl,'$ORIGIN/../rts-1.0' -optl-Wl,-zorigin libraries/integer-gmp/dist- install/build/GHC/Integer.dyn_o libraries/integer-gmp/dist- install/build/GHC/Integer/GMP/Internals.dyn_o libraries/integer-gmp/dist- install/build/GHC/Integer/GMP/Prim.dyn_o libraries/integer-gmp/dist- install/build/GHC/Integer/Logarithms.dyn_o libraries/integer-gmp/dist- install/build/GHC/Integer/Logarithms/Internals.dyn_o libraries/integer-gmp /dist-install/build/GHC/Integer/Type.dyn_o libraries/integer-gmp/dist- install/build/cbits/gmp-wrappers.dyn_o libraries/integer-gmp/dist- install/build/cbits/cbits.dyn_o libraries/integer-gmp/gmp/objs/*.o -shared -dynamic -dynload deploy -no-auto-link-packages -o libraries /integer-gmp/dist-install/build/libHSinteger- gmp-0.5.1.0-ghc7.7.20140113.so Warning: -rtsopts and -with-rtsopts have no effect with -shared. Call hs_init_ghc() from your main() function to set these options. /usr/bin/ld: libraries/integer-gmp/gmp/objs/aors.o: relocation R_X86_64_32 against `__gmpz_sub' can not be used when making a shared object; recompile with -fPIC libraries/integer-gmp/gmp/objs/aors.o: could not read symbols: Bad value collect2: ld returned 1 exit status make[1]: *** [libraries/integer-gmp/dist-install/build/libHSinteger- gmp-0.5.1.0-ghc7.7.20140113.so] Error 1 make: *** [all] Error 2 }}} I can build in-tree `libgmp` by extracting it and running `./configure make`. Following Austin's and Herbert's suggestions I tried adding `-fPIC` to command line options but with no result - see attachements. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8666> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #8782: Using GADT's to maintain invariant in GHC libraries
by GHC 22 Jan '16

22 Jan '16

#8782: Using GADT's to maintain invariant in GHC libraries ------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I rewrote `compiler/utils/OrdList.lhs` using a GADT to preserve some invariants stated only in comments — an excellent chance for `ghc` to eat its own proverbial dog food I feel :) The type signatures remain the same so it should be a drop-in replacement but it does use some GHC features that are too recent (closed type families in particular, the `IsList` instance can be removed) making it ineligible for inclusion I believe. hvr on `#ghc` suggested that I submit a patch anyway and that it could be implemented at a later date (they said `ghc` must be able to be compiled by the last two previous major versions), if this is useful then I will translate `Bag.hls` which has the same invariants but more complicated functions. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8782> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #8830: internal error: Misaligned section: 18206e5b on Windows
by GHC 21 Jan '16

21 Jan '16

#8830: internal error: Misaligned section: 18206e5b on Windows ----------------------------+------------------------------- Reporter: joeyhess | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+------------------------------- Loading package gnutls-0.1.5 ... ghc.exe: internal error: Misaligned section: 18206e5b (GHC version 7.6.3 for i386_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. Only occurs when loading the module in as part of a build involving TH. A non-TH-using program using this library links successfully. I have installed a gnutls built for Windows, from http://josefsson.org/gnutls4win/. Different versions have different section offsets, but all the versions I've tried fail like this. I've also gotten the same error linking gnuidn, instead of gnutls, with gnuidn from ftp://ftp.gnu.org/gnu/libidn/libidn-1.28-win32.zip This makes me think this may be a general ghci on windows bug, rather than a misbuilt library. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8830> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5