September 2014 - ghc-tickets

[GHC] #9106: GHC Panic related to functional dependencies - kindFunResult
by GHC 18 Jun '18

18 Jun '18

#9106: GHC Panic related to functional dependencies - kindFunResult ----------------------------+--------------------------------------- Reporter: yuriy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+--------------------------------------- Minimal example: {{{ {-# LANGUAGE MultiParamTypeClasses, DataKinds, FunctionalDependencies, TypeOperators, KindSignatures, PolyKinds, FlexibleInstances, FlexibleContexts, UndecidableInstances #-} import GHC.TypeLits data Proxy (a :: k) = Proxy class FunctorN n f a fa | n f a -> fa where fmapn :: Proxy n -> Proxy f -> (a -> a) -> fa -> fa instance FunctorN 0 f a a where fmapn _ _ a = a instance (Functor f, FunctorN (n - 1) f a fa) => FunctorN n f a (f fa) where fmapn _ pf f = fmap (fmapn (Proxy :: Proxy (n-1)) pf f) }}} Crashes with ghc and ghci: {{{ >ghc test [1 of 1] Compiling Main ( test.hs, test.o ) ghc.exe: panic! (the 'impossible' happened) (GHC version 7.8.20140130 for x86_64-unknown-mingw32): kindFunResult k{tv azb} [sk] >ghci test GHCi, version 7.8.20140130: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Main ( test.hs, interpreted ) ghc.exe: panic! (the 'impossible' happened) (GHC version 7.8.20140130 for x86_64-unknown-mingw32): kindFunResult k{tv aPm} [sk] }}} Removing the functional dependency makes the code compile. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9106> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #8619: Support anonymous string literals in C-- (OR) give better ASSERT failure messages in C--
by GHC 18 Jun '18

18 Jun '18

#8619: Support anonymous string literals in C-- (OR) give better ASSERT failure messages in C-- ------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- So if I say "foobar" in C--, it turns into: {{{ section "rodata" { fresh_name : bits8[] "foobar\0"; } }}} This would let us fix the ASSERT macro in Cmm.h to also get the filename. Requires parser changes. Alternatively, we can redefine the ASSERT macro per C-- file to have a hardcoded filename with some preprocessor trickery. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8619> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9539: TQueue can lead to thread starvation
by GHC 12 Jun '18

12 Jun '18

#9539: TQueue can lead to thread starvation -------------------------------------+------------------------------------- Reporter: jwlato | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.8.2 Keywords: stm | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- For background, please see [http://stackoverflow.com/questions/25536604 /huge-memory-consumption-for-simple-multithreaded- haskell/25560047#25560047 this SO question] When using TQueue, a sufficiently fast/persistent writer can result in the reader never getting scheduled, causing the queue to continually grow and lost concurrency. I believe the issue is caused by the definition of readTQueue: {{{ readTQueue :: TQueue a -> STM a readTQueue (TQueue read write) = do xs <- readTVar read case xs of (x:xs') -> do writeTVar read xs' return x [] -> do ys <- readTVar write case ys of [] -> retry _ -> case reverse ys of [] -> error "readTQueue" (z:zs) -> do writeTVar write [] writeTVar read zs return z }}} Note that the last `case` needs to traverse the write-end of the queue within the STM transaction. If the list is sufficiently large, a writer can commit a new transaction much more quickly, invalidating the read transaction. If threads continue to write to the queue, the reader will never get an opportunity to commit (and the list will grow, exacerbating the problem). This alternative definition seems to fix the problem, but I don't know if there are other drawbacks to using it. {{{ readTQueue' :: TQueue a -> STM a readTQueue' (TQueue read write) = do xs <- readTVar read case xs of (x:xs') -> do writeTVar read xs' return x [] -> do ys <- readTVar write case ys of [] -> retry _ -> do writeTVar write [] let (z:zs) = reverse ys writeTVar read zs return z }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9539> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23

[GHC] #8516: Add (->) representation and the Invariant class to GHC.Generics
by GHC 05 Jun '18

05 Jun '18

#8516: Add (->) representation and the Invariant class to GHC.Generics ----------------------------------------------+---------------------------- Reporter: nfrisby | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type checker) | Version: 7.7 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less than a day) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: ----------------------------------------------+---------------------------- We currently disallow any use of the parameter in the domain of (->). {{{ newtype F a = F ((a -> Int) -> Int) deriving Generic1 <interactive>:4:38: Can't make a derived instance of `Generic1 (F g)': Constructor `F' must use the last type parameter only as the last argument of a data type, newtype, or (->) In the data declaration for `F' }}} !DeriveFunctor succeeds for this F. I'd like to add this representation type to GHC.Generics and !DeriveGeneric. {{{ newtype (f :->: g) a = FArrow1 (f a -> g a) }}} We could then represent the first example above. We could also derive the more interesting Generic1 (F g). {{{ newtype F g a = F (g a -> Int) deriving Generic1 type instance Rep1 (F g) = Rec1 g :->: Rec0 Int instance Generic1 (F g) where to x = F $ unRec0 . unArrow1 x . Rec1 from (F x) = FArrow1 $ Rec0 . x . unRec1 }}} Admittedly, there's not many generic definitions impeded by not having (:->:). Contra- and in-variant types are uncommon. I'm suggesting this feature without strong motivating examples because I think this would streamline the implementation of -XDeriveGenerics in some ways while also making it more general — assuming that we added the Invariant class to base or ghc-prim. {{{ class Invariant t where invmap :: (a -> b) -> (b -> a) -> t a -> t b invmap_covariant :: Functor t => (a -> b) -> (b -> a) -> t a -> t b invmap_covariant f _ = fmap f instance (Invariant f,Invariant g) => Invariant (FArrow f g) where invmap co contra (FArrow h) = FArrow $ invmap co contra . h . invmap contra co }}} (Of course, Invariant should be a super class of Functor. :/ ) Now we can handle quite involved examples: {{{ newtype F g h a = F (g (h a)) deriving Generic1 instance Invariant g => Generic1 (F g h) where to x = invmap unRec1 Rec1 $ unComp1 x from (F x) = Comp1 $ invmap Rec1 unRec1 }}} All of that said, I'm mostly opening this ticket so I can get feedback on difficulties I might not be anticipating and have a place to reference from the compiler source code comments. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8516> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #9247: Document -XDatatypeContexts in flag reference
by GHC 03 Jun '18

03 Jun '18

#9247: Document -XDatatypeContexts in flag reference ------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: low | Milestone: Component: Documentation | 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: | ------------------------------------+------------------------------------- It may be a deprecated feature, but it still exists and should be listed. I can do this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9247> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9479: Report required constraints when reporting the type of a hole
by GHC 31 May '18

31 May '18

#9479: Report required constraints when reporting the type of a hole -------------------------------------+------------------------------------- Reporter: dominiquedevriese | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: Keywords: holes | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- For the following code {{{ module Test where test :: String test = show _h }}} GHC currently reports: {{{ Found hole ‘_h’ with type: a0 Where: ‘a0’ is an ambiguous type variable Relevant bindings include test :: String (bound at /tmp/Test.hs:4:1) In the first argument of ‘show’, namely ‘_h’ In the expression: show _h In an equation for ‘test’: test = show _h }}} It correctly does not report the lack of a `Show _a` instance as a separate type error. However, it would be useful if the report containing the type of the hole would also contain the constraints that apply to its type. Something like: {{{ Found hole ‘_h’ with type: a0 Where: ‘a0’ is an ambiguous type variable Applicable constraints: Show a0 Relevant bindings include test :: String (bound at /tmp/Test.hs:4:1) In the first argument of ‘show’, namely ‘_h’ In the expression: show _h In an equation for ‘test’: test = show _h }}} I am explicitly *not* suggesting to report a type like `Show a0 => a0` for the hole, because that might mistakenly suggest that we are looking for a value of type `forall a0. Show a0 => a0`, which we are not. A possible alternative is to use an imaginary exists type like `exists a0. Show a0 => a0` but that's probably just even more confusing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9479> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #9438: panic: loading archives not supported
by GHC 30 May '18

30 May '18

#9438: panic: loading archives not supported ----------------------------------+---------------------------------- Reporter: egl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+---------------------------------- Running {{{ ghci -L/opt/local/lib -latlas }}} eventually leads to {{{ Loading object (static archive) /opt/local/lib/libatlas.a ... ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-apple-darwin): Loading archives not supported Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} This looks similar to 8164 and 4828, which are marked closed. Mac OSX 10.9.4 Xcode 5.1.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9438> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #9427: Do finer-grained dependency analysis to infer more general kinds on type/class declarations
by GHC 27 May '18

27 May '18

#9427: Do finer-grained dependency analysis to infer more general kinds on type/class declarations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- In the resolution to #9200, as detailed [wiki:GhcKinds/KindInference#Apossiblevariation here], we identified an area for improvement. This improvement was not implemented in the fix for #9200. This ticket will track just this improvement. (In brief: we can do better dependency analysis on mutually recursive type/class declarations to allow more kinds to generalize earlier. This would lessen the burden on programmers to put in kind annotations. See the wiki page.) A solid but unfinished attempt is [https://github.com/goldfirere/ghc/tree /re-sort-non-cusk-decls here]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9427> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9587: Type checking with type functions introduces many type variables, which remain ambiguous. The code no longer type checks.
by GHC 26 May '18

26 May '18

#9587: Type checking with type functions introduces many type variables, which remain ambiguous. The code no longer type checks. -------------------------------------+------------------------------------- Reporter: oleg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: Keywords: type family, | Unknown/Multiple ambiguity check | Type of failure: GHC Architecture: Unknown/Multiple | rejects valid program Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Before the type ambiguity check was introduced, I could write the following code {{{ {-# LANGUAGE NoMonomorphismRestriction #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE ScopedTypeVariables #-} -- {-# LANGUAGE AllowAmbiguousTypes #-} module T where type family Arr (repr :: * -> *) (a :: *) (b :: *) :: * class ESymantics repr where int :: Int -> repr Int add :: repr Int -> repr Int -> repr Int lam :: (repr a -> repr b) -> repr (Arr repr a b) app :: repr (Arr repr a b) -> repr a -> repr b {- te4 :: (Arr repr (Arr repr Int Int) (Arr repr Int Int) ~ Arr repr (Arr repr Int Int) (Arr repr Int b), ESymantics repr) => repr b -} te4 = let c3 = lam (\f -> lam (\x -> f `app` (f `app` (f `app` x)))) in (c3 `app` (lam (\x -> x `add` int 14))) `app` (int 0) -- t = lam (\f -> f `app` int 0) newtype R a = R{unR :: a} type instance Arr R a b = a -> b instance ESymantics R where int = R add (R x) (R y) = R $ x + y lam f = R $ unR . f . R app (R f) (R x) = R $ f x tR = unR te4 }}} (This is a simple code abstracted from a longer code that for sure worked in 2010: I showed it in a SSGIP lecture at Oxford.) The inferred type of te4 is shown in comments. The type is not ideal but the best what can be done under circumstances. In tR, repr is instantiated to R and the type function Arr can finally be applied and the equality constraint resolved. Since then, the type inference has changed and the code no longer type checks: {{{ Could not deduce (Arr repr (Arr repr a0 b0) (Arr repr a2 b0) ~ Arr repr (Arr repr a b) (Arr repr a4 b)) from the context (ESymantics repr, Arr repr a4 a3 ~ Arr repr a b, Arr repr a3 a ~ Arr repr a b) bound by the inferred type for ‘c3’: (ESymantics repr, Arr repr a4 a3 ~ Arr repr a b, Arr repr a3 a ~ Arr repr a b) => repr (Arr repr (Arr repr a b) (Arr repr a4 b)) }}} What is worse, there does not appear to be *any* way to get the code to type check. No amount of type annotations helps. The code has to be dramatically re-written, or just given up. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9587> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #9607: Type checking regression between GHC 7.6 and 7.8
by GHC 26 May '18

26 May '18

#9607: Type checking regression between GHC 7.6 and 7.8 -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: GHC Difficulty: Unknown | rejects valid program Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Jason McCarty [http://www.haskell.org/pipermail/haskell- cafe/2014-September/116076.html reported on Haskell-cafe] that this code used to work with GHC 7.6 but in GHC 7.8 it requires `AllowAmbiguousTypes`: {{{#!hs -- The code below is simplified from code that computes a tensor product of -- a tensor with an identity matrix whose size is determined from the -- shapes of the input and output tensors. {-# LANGUAGE DataKinds, KindSignatures, TypeFamilies, TypeOperators #-} --{-# LANGUAGE AllowAmbiguousTypes #-} module Tensors where import GHC.TypeLits type family (as :: [Nat]) ++ (bs :: [Nat]) :: [Nat] type instance '[] ++ bs = bs type instance (a ': as) ++ bs = a ': (as ++ bs) data Tensor (s :: [Nat]) = Tensor -- content elided -- apparently GHC reduces (++) enough to see that n is determined leftUnit :: Tensor s -> Tensor ('[n, n] ++ s) leftUnit Tensor = Tensor -- accepted in 7.6, not accepted in 7.8 without AllowAmbiguousTypes rightUnit :: Tensor s -> Tensor (s ++ '[n, n]) rightUnit Tensor = Tensor -- also accepted without AllowAmbiguousTypes outsideUnit :: Tensor s -> Tensor ('[n] ++ s ++ '[n]) outsideUnit Tensor = Tensor useleftUnit :: Tensor '[1,1,2] useleftUnit = leftUnit Tensor -- type of Tensor is inferred userightUnit :: Tensor '[1,2,2] userightUnit = rightUnit (Tensor :: Tensor '[1]) -- type must be provided }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9607> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10