June 2016 - ghc-tickets

[GHC] #9940: GHCi crashes when I hold down control-c for a short time, and then hold down any key that would normally result in typing.
by GHC 16 Nov '16

16 Nov '16

#9940: GHCi crashes when I hold down control-c for a short time, and then hold down any key that would normally result in typing. -------------------------------------------+------------------------------- Reporter: Dingus | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.6.3 Keywords: crash, control-c | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------------+------------------------------- This is printed: (without the quotes at the beginning or end) " ghc.exe: panic! (the 'impossible' happened) (GHC version 7.6.3 for i386-unknown-mingw32): thread blocked indefinitely in an MVar operation Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug " I am able to reproduce it by: 1. starting ghci (with no arguments, or a file as an argument) 2. holding down contol-c for 2 seconds 3. holding down spacebar/a letter key for 2 seconds The timing varies. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9940> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11832: Allow reify to yield types in the current declaration group
by GHC 16 Nov '16

16 Nov '16

#11832: Allow reify to yield types in the current declaration group -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: template- | Operating System: Unknown/Multiple haskell reify | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: | TemplateHaskell/Reify -------------------------------------+------------------------------------- Here is the motivation TemplateHaskell/Reify. It would be useful to have a way to obtain types of identifiers in the current declaration group in splices. However, {{{reify}}} is defined to provide information about identifiers in previous declaration groups only. It would be fine to allow {{{reify}}} to work in a scheme combined with {{{addModFinalizer}}} or similar so it is executed when the types are known. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11832> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #10771: Installation of Ivory - Static flags have not been initialised
by GHC 14 Nov '16

14 Nov '16

#10771: Installation of Ivory - Static flags have not been initialised -------------------------------------+------------------------------------- Reporter: stiege | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: Runtime crash (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Unfortunately I'm a Haskell newbie and can't provide very good detail for this report (I struggled to pass the Captcha!). However I will attach the output from a "make all" from the Ivory repository: https://github.com/GaloisInc/ivory.git Commit: '7ecea5839898b65430ca298fd1f3af4d2272e3fb'. Basically from what I can see, looks like it didn't work, output ends with: examples\Coroutine.hs:26:50: Warning: Unticked promoted constructor: `:->'. Use ':-> instead of `:->'. ghc.exe: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-mingw32): Static flags have not been initialised! Please call GHC.parseStaticFlags early enough. Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug ghc.exe: warning: _tzset from msvcrt is linked instead of __imp__tzset -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10771> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11660: Remove Type pretty-printer in favor of IfaceType
by GHC 13 Nov '16

13 Nov '16

#11660: Remove Type pretty-printer in favor of IfaceType -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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: -------------------------------------+------------------------------------- The `Type` pretty-printer has a fair amount of code in common with the pretty-printer for `IfaceType`. Moreover, both cases handle a number of special cases. With the introduction of `-fprint-explicit-runtime-reps` (Phab:D1961), there is now an inconsistency between these two. Let's resolve this inconsistency by eliminating the `Type` pretty-printer in favor of using the `IfaceType` printer. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11660> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #12021: Type variable escapes its scope
by GHC 11 Nov '16

11 Nov '16

#12021: Type variable escapes its scope -------------------------------------+------------------------------------- Reporter: ttuegel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc3 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: GHC rejects (amd64) | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In the following example, I believe a type variable is incorrectly escaping its scope. The example produces the error: {{{ Bug.hs:20:20: error: • Expected kind ‘Cat k’, but ‘(:-)’ has kind ‘Constraint -> Constraint -> *’ • In the first argument of ‘Iso’, namely ‘(:-)’ In the type signature: functor :: forall a b. Iso (:-) (:-) (Ob (Dom f) a) (Ob (Dom f) b) (Ob (Cod f) (f a)) (Ob (Cod f) (f b)) In the class declaration for ‘Functor’ }}} If the definition of `Iso` is changed from {{{#!hs type Iso (c :: Cat k) (d :: Cat k) s t a b = forall p. (Cod p ~ Nat d (->)) => p a b -> p s t }}} to {{{#!hs type Iso (c :: Cat k) (d :: Cat k) s t a b = forall p. p a b -> p s t }}} then this error does not occur. (The example still will not compile because I have omitted almost the entire implementation, but it should not fail here.) I am not certain what is really happening here, but it seems to me that when the RHS of `Iso` is constrained, then the type variable `k` introduced on the LHS of `Iso` is being unified incorrectly with the type variable `k` introduced in the definition of the `Functor` class. When the constraint is removed, GHC seems to recognize (correctly!) that the type variables are distinct. (This bug actually occurs with GHC 8.0.1-rc4, but the "Version" menu doesn't give me that option.) {{{#!hs {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE NoImplicitPrelude #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} import GHC.Base ( Constraint, Type ) type Cat k = k -> k -> Type class Category (p :: Cat k) where type Ob p :: k -> Constraint class (Category (Dom f), Category (Cod f)) => Functor (f :: j -> k) where type Dom f :: Cat j type Cod f :: Cat k functor :: forall a b. Iso (:-) (:-) (Ob (Dom f) a) (Ob (Dom f) b) (Ob (Cod f) (f a)) (Ob (Cod f) (f b)) class (Functor f , Dom f ~ p, Cod f ~ q) => Fun (p :: Cat j) (q :: Cat k) (f :: j -> k) | f -> p q instance (Functor f , Dom f ~ p, Cod f ~ q) => Fun (p :: Cat j) (q :: Cat k) (f :: j -> k) data Nat (p :: Cat j) (q :: Cat k) (f :: j -> k) (g :: j -> k) type Iso (c :: Cat k) (d :: Cat k) s t a b = forall p. (Cod p ~ Nat d (->)) => p a b -> p s t data (p :: Constraint) :- (q :: Constraint) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12021> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11369: Suppress redundant-constraint warnings in case of empty classes
by GHC 07 Nov '16

07 Nov '16

#11369: Suppress redundant-constraint warnings in case of empty classes -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 (Type checker) | 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: -------------------------------------+------------------------------------- The technique described in http://www.well-typed.com/blog/2015/07/checked-exceptions/ makes use of a class without any methods, i.e. {{{#!hs class Throws e }}} However, this by definition results in redundant constraints, e.g. {{{#!hs readFoo :: Throws IOError => FilePath -> IO Foo readFoo fn = {- ... -} }}} which GHC 8.0 warns about. I propose to suppress warnings in case a class which has no methods is used as seemingly redundant constraint. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11369> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #12220: TypeApplications and DefaultSignatures - problems deducing type variables.
by GHC 07 Nov '16

07 Nov '16

#12220: TypeApplications and DefaultSignatures - problems deducing type variables. -------------------------------------+------------------------------------- Reporter: mkloczko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux DefaultSignatures, | TypeApplications | Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following example code throws an error. The example code: {{{#!hs {-#LANGUAGE TypeApplications#-} {-#LANGUAGE MultiParamTypeClasses #-} {-#LANGUAGE AllowAmbiguousTypes #-} {-#LANGUAGE FlexibleInstances #-} {-#LANGUAGE ScopedTypeVariables #-} {-#LANGUAGE DefaultSignatures #-} module Test1 where -- | Type a is only used for -- type application. class ToUse a where toUse :: Int -> Int -- | The type used for -- type application data Default -- | The instance using Default as type application. -- To call use: -- > toUse @Default instance ToUse Default where toUse a = 3*a -- | Typeclass whose methods work -- only with type application. class (ToUse a) => Uses a b where uses :: b -> [b] -- | Default Signature, which generates the problem. -- It is the same as the normal one -- Comment it to 'fix' the bug. default uses :: b -> [b] uses v = [v] -- | Normal instances, nothing special instance Uses Default Int where uses v = take (toUse @Default 3) $ repeat v -- | Another normal one instance Uses Default String where uses v = take (toUse @Default 2) $ repeat v -- | This one works nicely instance (ToUse t, Uses t a, Uses t b) => Uses t (a,b) where uses (vl,vr) = zip ls rs where ls = uses @t vl rs = uses @t vr -- | But this one doesn't. -- Unless you comment the default signature. instance (ToUse t, Uses t a, Uses t b, Uses t c) => Uses t (a,b,c) }}} The error: {{{ • Could not deduce (Uses a0 a) arising from a use of ‘Test1.$dmuses’ from the context: (ToUse t, Uses t a, Uses t b, Uses t c) bound by the instance declaration at Test1.hs:47:10-66 The type variable ‘a0’ is ambiguous Relevant bindings include uses :: (a, b, c) -> [(a, b, c)] (bound at Test1.hs:47:10) • In the expression: Test1.$dmuses In an equation for ‘uses’: uses = Test1.$dmuses In the instance declaration for ‘Uses t (a, b, c)’ }}} Commenting out the default signature fixes the problem. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12220> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #11571: Need more intelligent conditionalization of libgcc rts symbols for x32
by GHC 05 Nov '16

05 Nov '16

#11571: Need more intelligent conditionalization of libgcc rts symbols for x32 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.1 System (Linker) | Keywords: | Operating System: Unknown/Multiple Architecture: Other | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In `rts/RtsSymbols.c` we have {{{ // 64-bit support functions in libgcc.a #if defined(__GNUC__) && SIZEOF_VOID_P <= 4 && !defined(_ABIN32) #define RTS_LIBGCC_SYMBOLS \ SymI_NeedsProto(__divdi3) \ SymI_NeedsProto(__udivdi3) \ ... }}} The purpose is to provide these symbols to `.o` files that use these symbols, expecting to be linked against libgcc. These symbols are for things like 64-bit integer division that aren't available as machine instructions on some platforms. But the `#if` is wrong on x32, which, despite having `sizeof(void *) == 4`, naturally has a full complement of 64-bit arithmetic instructions, since its registers are 64 bits wide. So libgcc does not provide these symbols, and as a result we eventually encounter missing symbol errors when linking the rts. Some possible solutions include * Figure out if there is a CPP variable set for x32 and don't include these symbols if that variable is set. I'm not sure whether `__ILP32__` is such a variable (after all x86 is also an architecture on which int, long and pointers are 32-bits). * Use autoconf to detect the presence of these symbols in libgcc. (Probably just pick one, like `__divdi3`, and hope they are all present or all missing.) * Use weak symbols somehow to add these symbols to the RTS's internal symbol table if and only if the RTS was linked against a libgcc that provides these symbols. My Android ghci also needs lots more of these, including `__modsi3`, `__umodsi3`, `__ctzdi2`, a bunch of `__aeabi_*` and `__sync_*`, and `__sF` (no idea what that is). So I'm inclined towards the last option. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11571> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9010: TemplateHaskell leads to an "unknown symbol" error
by GHC 04 Nov '16

04 Nov '16

#9010: TemplateHaskell leads to an "unknown symbol" error ------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | 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: | ------------------------------------+------------------------------------- Code: {{{ {-# LANGUAGE TemplateHaskell #-} module M where import System.Console.Editline import Data.Lens.Template data S = S { _a :: EditLine } makeLens ''S }}} When compiled with `ghc link.hs`, everything is fine; {{{ [1 of 1] Compiling M ( link.hs, link.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.4.0.1 ... linking ... done. Loading package deepseq-1.3.0.1 ... linking ... done. Loading package containers-0.5.0.0 ... linking ... done. Loading package bytestring-0.10.0.2 ... linking ... done. Loading package tagged-0.7.1 ... linking ... done. Loading package transformers-0.3.0.0 ... linking ... done. Loading package transformers-compat-0.1.1.1 ... linking ... done. Loading package contravariant-0.4.4 ... linking ... done. Loading package distributive-0.4.3.1 ... linking ... done. Loading package mtl-2.1.3.1 ... linking ... done. Loading package text-1.1.0.1 ... linking ... done. Loading package hashable-1.2.1.0 ... linking ... done. Loading package nats-0.1.2 ... linking ... done. Loading package unordered-containers-0.2.3.3 ... linking ... done. Loading package semigroups-0.12.2 ... linking ... done. Loading package comonad-4.0.1 ... linking ... done. Loading package semigroupoids-4.0.1 ... linking ... done. Loading package data-lens-2.10.4 ... linking ... done. Loading package pretty-1.1.1.0 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package data-lens-template-2.1.8 ... linking ... done. }}} However, when compiling with `ghc -package-id editline-0.2.1.1-ef91ae78e7ea1b9142c2fb0b84e85c11 link.hs`, I get {{{ [1 of 1] Compiling M ( link.hs, link.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package editline-0.2.1.1 ... linking ... ghc: /home/feuerbach/work /.cabal-sandbox/lib/i386-linux- ghc-7.6.3/editline-0.2.1.1/HSeditline-0.2.1.1.o: unknown symbol `el_reset' ghc: unable to load package `editline-0.2.1.1' }}} This is a problem because that's how cabal invokes ghc. This looks similar to #4899, except there's nothing "non-standard" here (no profiling or dynamic linking). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9010> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

[GHC] #11184: panic tcMonoExpr _ with bad indentation in TH code
by GHC 02 Nov '16

02 Nov '16

#11184: panic tcMonoExpr _ with bad indentation in TH code -------------------------------------+------------------------------------- Reporter: TeroLaitinen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE TemplateHaskell #-} import Data.Aeson.TH data Record = Record { type_ :: Int } $(deriveJSON defaultOptions{ fieldLabelModifier = \x -> case x of "type_" -> "type" _ -> x } ''Record) }}} gives {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): tcMonoExpr _ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11184> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8