February 2016 - ghc-tickets

[GHC] #11508: QuickCheck application hangs with concurrent read/write of Chan
by GHC 30 Mar '16

30 Mar '16

#11508: QuickCheck application hangs with concurrent read/write of Chan -------------------------------------+------------------------------------- Reporter: orion | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: FreeBSD Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: https://github.com/centromere | /ghc-bug-testcase | Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If you configure the test case like so: {{{ $ cabal configure --enable-tests -fbad }}} The QuickCheck application will hang when executed: {{{ $ ./dist/build/properties/properties --quickcheck-verbose --quickcheck- tests 10 10 9 8 7 6 5 4 3 2 1 10 testCase 1 a: }}} If you compile it without the 'bad' flag, it will execute successfully. The problem is reproducible on both FreeBSD 10 and Ubuntu 15.10. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11508> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #11639: `:print` being wacky
by GHC 29 Mar '16

29 Mar '16

#11639: `:print` being wacky ----------------------------------------+------------------------------- Reporter: TheKing42 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+------------------------------- {{{ $ ghci GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help Prelude> let x = 1:x Prelude> :print x x = (_t1::Num a => [a]) Prelude> head _t1 ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-unknown-linux): tcTyVarDetails a_avB Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11639> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11386: Improve error message
by GHC 29 Mar '16

29 Mar '16

#11386: Improve error message -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | 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: -------------------------------------+------------------------------------- {{{ Prelude> class (A, B) <interactive>:16:8: error: Unexpected type ‘A’ In the class declaration for ‘GHC.Classes.(%,%)’ A class declaration should have form class GHC.Classes.(%,%) a b where ... }}} in 7.10.2 it gave the more sensible {{{ ghci> class (A, B) <interactive>:30:7: Malformed head of type or class declaration: (A, B) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11386> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10853: Refine addTopDecls
by GHC 29 Mar '16

29 Mar '16

#10853: Refine addTopDecls -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Template | Version: 7.10.2 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- This suggested refactoring/documentation task is spurred on by #10486. Readers do not have to read that ticket to understand this task. Currently, `addTopDecls` is restricted in what it can add. In an email exchange with Geoff Mainland (the original implementor of `addTopDecls`), it was unclear exactly why this restriction is in place. So, I propose lifting the restriction. We do have to be careful about ordering. As it is currently implemented, here is what happens: {{{ -- region A, including everything up to but not including a top-level splice $( {- region B, the contents of a top-level splice -} ) -- region C, everything after the splice }}} In addition to those regions, we also have {{{ -- region D, consisting of all declarations added with `addTopDecls`. }}} By reading the code (`TcRnDriver.tc_rn_src_decls`), it seems that the expected behavior should be this: 1. Rename region A. Anything defined in other regions is not in scope. 2. Rename region D, with declarations from region A in scope. 3. Type-check regions A and D together. 4. When running TH code in region B, all declarations from A and D are in scope and can be accessed via `reify` and friends. 5. Combine regions B and C together, and recur to step 1 (where the combined B and C is now a new region A). This all means that A and D are mutually recursive w.r.t. the type-checker but not the renamer. This is a bit peculiar, but not terrible. For example, this means that there could be a function whose definition is in A and type signature in D. Proper mutual recursion would be hard (impossible?) without better renaming support. In any case, I don't see a reason to restrict what's allowed in `addTopDecls`. So, at a minimum, I propose: * Remove restrictions in `addTopDecls` * Document `addTopDecls` generally * Document the above behavior, detailing the interaction between these regions Perhaps better, we could do: * Remove restrictions in `addTopDecls` * Rejigger the implementation of `addTopDecls` to lump region D in with B and C. This looks quite straightforward, and it makes for a simpler story about mutual recursion. This is a potentially-breaking change, if existing code has, say, a function defined in A with its type signature in D. * Document the new, simpler behavior Regardless of which proposal we go with, some testing is in order, to make sure that this is all correct. I've done no testing in formulating this ticket, just reading code. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10853> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11473: Levity polymorphism checks are inadequate
by GHC 28 Mar '16

28 Mar '16

#11473: Levity polymorphism checks are inadequate -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple LevityPolymorphism | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Ben found {{{ {-# LANGUAGE PolyKinds, TypeFamilies, MagicHash, DataKinds, TypeInType, RankNTypes #-} import GHC.Exts import GHC.Types type family Boxed (a :: k) :: * type instance Boxed Char# = Char type instance Boxed Char = Char class BoxIt (a :: TYPE lev) where boxed :: a -> Boxed a instance BoxIt Char# where boxed x = C# x instance BoxIt Char where boxed = id hello :: forall (lev :: Levity). forall (a :: TYPE lev). BoxIt a => a -> Boxed a hello x = boxed x {-# NOINLINE hello #-} main :: IO () main = do print $ boxed 'c'# print $ boxed 'c' print $ hello 'c' print $ hello 'c'# }}} This is plainly wrong because we have a polymorphic function `boxed` that is being passed both boxed and unboxed arguments. You do get a Lint error with `-dcore-lint`. But the original problem is with the type signature for `boxed`. We should never have a levity-polymorphic type to the left of an arrow. To the right yes, but to the left no. I suppose we could check that in `TcValidity`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11473> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #10338: GHC Forgets Constraints
by GHC 26 Mar '16

26 Mar '16

#10338: GHC Forgets Constraints -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- This is possibly fixed by #10195, but I don't have a convenient means of testing it. At any rate, this testcase is considerably simpler than the one in #10195. {{{#!hs {-# LANGUAGE TypeFamilies, FlexibleContexts, GADTs, MultiParamTypeClasses #-} type family F r class (Functor t) => T t r where fromScalar :: r -> t r data Foo t r where Foo :: t (F r) -> Foo t r Scalar :: r -> Foo t r toF :: r -> F r toF = undefined convert :: (T t (F r)) => Foo t r -> Foo t r convert (Scalar c) = let fromScalar' = fromScalar in Foo $ fromScalar' $ toF c }}} This code compiles with GHC 7.8.4. When I add a generic instance for `T` (which requires `FlexibleInstances`): `instance (Functor t, Num r) => T t r` GHC complains: {{{#!hs Could not deduce (Num (F r)) arising from a use of ‘fromScalar’ from the context (T t (F r)) bound by the type signature for convert :: (T t (F r)) => Foo t r -> Foo t r at Main.hs:(17,12)-(18,23) In the expression: fromScalar In an equation for ‘fromScalar'’: fromScalar' = fromScalar In the expression: let fromScalar' = fromScalar in Foo $ fromScalar' $ toF c }}} Of course the problem can be fixed by adding a type signature to `fromScalar` and adding `ScopedTypeVariables`: {{{#!hs convert :: forall t r . (T t (F r)) => Foo t r -> Foo t r convert (Scalar c) = let fromScalar' = fromScalar :: F r -> t (F r) in Foo $ fromScalar' $ toF c }}} Like #10195, this is triggered when a generic instance is in scope. The (main) problem of course is that GHC tries to match the generic instance instead of using the `T (F r)` constraint supplied by `convert`. A secondary issue is that I think the example should have the same behavior pre- and post-instance, i.e either both should compile or both should not compile. I'm not sure if a monomorphism restriction is actually being triggered here or if that's just a red herring. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10338> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #11626: type variable out of scope core lint error when compiling attoparsec
by GHC 25 Mar '16

25 Mar '16

#11626: type variable out of scope core lint error when compiling attoparsec -------------------------------------+------------------------------------- Reporter: luite | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 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: -------------------------------------+------------------------------------- I'm getting a core lint error when compiling attoparsec with the `-dcore- lint` option {{{ *** Core Lint errors : in result of SpecConstr *** <no location info>: warning: In the type ‘Buffer -> Pos -> More -> a_aaPH -> IResult Text r_aaPI’ @ a_aaPH is out of scope *** Offending Program *** ... 57000 lines of offending program cut *** End of Offense *** }}} * attoparsec 0.13.0.2 commit 4f137347be02106765f6897059b88219c79bb86c * ghc 8.0.1-rc2 and also 892de051aaaf9a346dadc74592a9cc375b3223a4 (feb 20) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11626> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11644: Core lint error in result of Specialise for TEST=T3220 WAY=profasm
by GHC 25 Mar '16

25 Mar '16

#11644: Core lint error in result of Specialise for TEST=T3220 WAY=profasm -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: indexed- | Blocked By: types/should_compile/T3220 | Blocking: | Related Tickets: #11371, #11643 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is the code: {{{ {-# LANGUAGE TypeFamilies, ScopedTypeVariables#-} module T3220 where class Foo m where type Bar m :: * action :: m -> Bar m -> m right x m = action m (Right x) right' :: (Either a b ~ Bar m, Foo m) => b -> m -> m right' x m = action m (Right x) instance Foo Int where type Bar Int = Either Int Int action m a = either (*) (+) a m instance Foo Float where type Bar Float = Either Float Float action m a = either (*) (+) a m foo = print $ right (1::Int) (3 :: Int) bar = print $ right (1::Float) (3 :: Float) }}} Invocation: {{{ $ ghc-8.0.1 T3220.hs -prof -O -dcore-lint }}} {{{ [1 of 1] Compiling T3220 ( T3220.hs, T3220.o ) *** Core Lint errors : in result of Specialise *** <no location info>: warning: In the expression: action @ Float $fFooFloat m_ayb ((Right @ Float @ Float x_aya) `cast` (Sub (Sym cobox_aUe) :: Either a_aU3 b_aU4 ~R# Bar m_aU1)) cobox_aUe :: Bar m_aU1 ~# Either a_aU3 b_aU4 [LclId[CoVarId], Str=DmdType] is out of scope }}} Interestingly, with HEAD (2aee41960aa00fe09a2cd1983e02c15e06013037), it hits an assert from #11371. {{{ =====> T3220(profasm) 12 of 21 [0, 11, 0] cd ./indexed-types/should_compile && "/home/thomas/ghc- validate/inplace/test spaces/ghc-stage2" -c T3220.hs -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-warn-missed-specialisations -fno-ghci-history -O -prof -static -auto-all > T3220.comp.stderr 2>&1 Compile failed (status 256) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20160221 for x86_64-unknown-linux): ASSERT failed! CallStack (from HasCallStack): assertPprPanic, called at compiler/types/TyCoRep.hs:1942:51 in ghc:TyCoRep checkValidSubst, called at compiler/types/TyCoRep.hs:2076:17 in ghc:TyCoRep substCo, called at compiler/coreSyn/CoreSubst.hs:605:20 in ghc:CoreSubst in_scope InScope {x_axS m_axT $caction_a1dp $caction_a1dR right right' foo bar $tcFoo $tc'C:Foo $fFooFloat $fFooInt $trModule a_s1fZ a_s1g0 a_s1g1 a_s1g2} tenv [aTT :-> Float, aTV :-> Float, aTW :-> Float] cenv [] tys [] cos [Sub (Sym cobox_aU6)] needInScope [aU6 :-> cobox_aU6] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} This is a regression from 7.10.3. Setting priority=highest. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11644> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #11580: panic on incompatible options
by GHC 25 Mar '16

25 Mar '16

#11580: panic on incompatible options -------------------------------------+------------------------------------- Reporter: dougm | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This torture test causes ghc to panic for incompatible options Unsafe and Trustworthy {{{ ghc `ghc --supported-languages | sed 's/^/-X/'` }}} The two options alone lead to a correct diagnostic. So does deletion of either from the full list. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11580> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #11145: Template Haskell quotes of data instance GADTs is totally broken
by GHC 24 Mar '16

24 Mar '16

#11145: Template Haskell quotes of data instance GADTs is totally broken -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.10.2 Haskell | 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: -------------------------------------+------------------------------------- When I say {{{ data family Fuggle x y [d| data instance Fuggle Int (Maybe (a,b)) where MkFuggle :: Fuggle Int (Maybe Bool) |] }}} I get (with `-ddump-splices`) {{{ [d| data instance Fuggle Int (Maybe (a_ajz6, b_ajz7)) where MkFuggle_ajz5 :: Fuggle Int (Maybe Bool) |] ======> data instance Fuggle Int (Maybe (a_ajAf, b_ajAg)) = (b_ajAg ~ Maybe Bool, a_ajAf ~ Int) => MkFuggle_ajAe }}} But that's not at all what I said! Admittedly, what I said was garbage, but it should fail outright. Is this addressed by Phab:D1465? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11145> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7