- ghc-tickets - Haskell.org

[GHC] #12882: Unexpected constraint when using ExistentialQuantification
by GHC 28 Nov '16

28 Nov '16

#12882: Unexpected constraint when using ExistentialQuantification -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- Hello! Consider this simple code: {{{ data Elem t = Typeable t => Elem Int tst1 :: forall a. Elem a -> TypeRep tst1 (Elem _) = typeRep (Proxy :: Proxy a) }}} It works and it should work. `Elem` is created only to be sure that if we've got a value of type `Elem t` we don't have to check that `t` is `Typeable`. <offtopic> By the way, exystential newtypes would be so awesome in GHC! </offtopic> And now a strange thing. If we create another function: {{{ tst2 :: forall a. Elem a -> TypeRep tst2 _ = typeRep (Proxy :: Proxy a) }}} GHC throws error that there is no `Typeable a` constraint. The only difference between `tst1` and `tst2` is different pattern binding. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12882> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #12883: Unexpected constraint when using ExistentialQuantification
by GHC 27 Nov '16

27 Nov '16

#12883: Unexpected constraint when using ExistentialQuantification -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hello! Consider this simple code: {{{ data Elem t = Typeable t => Elem Int tst1 :: forall a. Elem a -> TypeRep tst1 (Elem _) = typeRep (Proxy :: Proxy a) }}} It works and it should work. `Elem` is created only to be sure that if we've got a value of type `Elem t` we don't have to check that `t` is `Typeable`. <offtopic> By the way, exystential newtypes would be so awesome in GHC! </offtopic> And now a strange thing. If we create another function: {{{ tst2 :: forall a. Elem a -> TypeRep tst2 _ = typeRep (Proxy :: Proxy a) }}} GHC throws error that there is no `Typeable a` constraint. The only difference between `tst1` and `tst2` is different pattern binding. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12883> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #12753: GHCi/Template Haskell: Don't panic on linker errors.
by GHC 27 Nov '16

27 Nov '16

#12753: GHCi/Template Haskell: Don't panic on linker errors. -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System (Linker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHCi crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #11042 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When the link editor is called by `Linker.hs` as part of loading a library and an error occurs GHCi panics. As a consequence users submit bug reports because the panic message tells them do do so. The link editor process can fail because of missing libraries, failure to create a link file, missing linker program, etc., all of which are beyond the control of GHC and should not be considered a bug in GHC. When the link editor fails 1. an error message should be printed and GHC should terminate if the error is fatal. 1. a warning (that could be silenced) should be issued in non-fatal cases. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12753> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #11158: Combine exprIsTrivial and cpe_ExprIsTrivial
by GHC 26 Nov '16

26 Nov '16

#11158: Combine exprIsTrivial and cpe_ExprIsTrivial -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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: -------------------------------------+------------------------------------- Look at `CoreUtils.exprIsTrivial` and `CorePrep.cpe_ExprIsTrivial`. They are identical! The latter has a comment saying {{{ cpe_ExprIsTrivial :: CoreExpr -> Bool -- Version that doesn't consider an scc annotation to be trivial. }}} but the code does not treat ticks any differently. So the question is: '''are they supposed to be different'''? And if not, can we just combine them? Peter W, Simon M: this is your territory. I don't understand tick stuff well enough. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11158> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 38

[GHC] #12876: Appreciate your work!
by GHC 26 Nov '16

26 Nov '16

#12876: Appreciate your work! -------------------------------------+------------------------------------- Reporter: deech | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- Not a bug. Happy Thanksgiving and thanks for all your efforts! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12876> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #12867: Internal error while typechecking invalid program
by GHC 26 Nov '16

26 Nov '16

#12867: Internal error while typechecking invalid program -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- While trying to reduce #12866 I encountered this program, {{{#!hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE FlexibleContexts #-} module T12866 where type Test2 a = (Eq (TestM a)) class Test a where type TestM :: * }}} which gives rise to this internal GHC error during typechecking, {{{ $ ghc Hi2.hs Hi2.hs:7:21: error: • GHC internal error: ‘TestM’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [ap0 :-> Type variable ‘a’ = a] • In the first argument of ‘Eq’, namely ‘TestM a’ In the type ‘Eq (TestM a)’ In the type declaration for ‘Test2’ Hi2.hs:9:1: error: • The associated type ‘TestM’ mentions none of the type or kind variables of the class ‘Test a’ • In the class declaration for ‘Test’ }}} Clearly the program is bogus, but the first error message is quite suspicious. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12867> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12845: -XPartialTypeSignatures results in unbound variables
by GHC 26 Nov '16

26 Nov '16

#12845: -XPartialTypeSignatures results in unbound variables -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following code fails to compile, but I think it should. {{{ {-# LANGUAGE DataKinds #-} {-# LANGUAGE PartialTypeSignatures #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} import Data.Proxy data Foo (m :: Bool) type family Head (xs :: [(Bool, Bool)]) where Head (x ': xs) = x type family Bar (x :: Bool) (y :: Bool) :: Bool -- to trigger the bug, r and r' cannot *both* appear on the RHS broken :: forall r r' rngs . ('(r,r') ~ Head rngs, Bar r r' ~ 'True, _) => Foo r -> Proxy rngs -> () broken x _ = let y = requireBar x :: Foo r' in () requireBar :: (Bar m m' ~ 'True) => Foo m -> Foo m' requireBar = undefined }}} The error is: {{{ > ghci UnboundVar.hs GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( UnboundVar.hs, interpreted ) UnboundVar.hs:18:1: error: • Could not deduce: Bar r r'0 ~ 'True from the context: ('(r, r') ~ Head rngs, Bar r r' ~ 'True, Bar r r' ~ 'True) bound by the inferred type for ‘broken’: ('(r, r') ~ Head rngs, Bar r r' ~ 'True, Bar r r' ~ 'True) => Foo r -> Proxy rngs -> () at UnboundVar.hs:18:1-49 The type variable ‘r'0’ is ambiguous • When checking that the inferred type broken :: forall (r :: Bool) (r' :: Bool) (rngs :: [(Bool, Bool)]). Bar r r' ~ 'True => Foo r -> Proxy rngs -> () is as general as its (partial) signature broken :: forall (r :: Bool) (r' :: Bool) (rngs :: [(Bool, Bool)]). ('(r, r') ~ Head rngs, Bar r r' ~ 'True, Bar r r' ~ 'True) => Foo r -> Proxy rngs -> () }}} If I remove the partial type signature (i.e., remove the `_` constraint from `broken`), then GHC happily accepts the code. I'm not sure why adding a `_` introduces ambiguity; it seems GHC is forgetting that `r'` is bound by the `forall` (and that `-XScopedTypeVariables` is enabled). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12845> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12826: TyVar ASSERT failure in type family checking: T12041
by GHC 25 Nov '16

25 Nov '16

#12826: TyVar ASSERT failure in type family checking: T12041 -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- In HEAD, if you build the compiler with -DDEBUG, test `indexed- types/should_fail/T12041` fails thus {{{ +ghc: panic! (the 'impossible' happened) + (GHC version 8.1.20161109 for x86_64-unknown-linux): + ASSERT failed! + i_axb + Call stack: + CallStack (from HasCallStack): + prettyCurrentCallStack, called at compiler/utils/Outputable.hs:<line>:<column> in <package-id>:Outputable + callStackDoc, called at compiler/utils/Outputable.hs:<line>:<column> in <package-id>:Outputable + assertPprPanic, called at compiler/typecheck/TcType.hs:<line>:<column> in <package-id>:TcType + Call stack: + CallStack (from HasCallStack): + prettyCurrentCallStack, called at compiler/utils/Outputable.hs:<line>:<column> in <package-id>:Outputable + callStackDoc, called at compiler/utils/Outputable.hs:<line>:<column> in <package-id>:Outputable + pprPanic, called at compiler/utils/Outputable.hs:<line>:<column> in <package-id>:Outputable + assertPprPanic, called at compiler/typecheck/TcType.hs:<line>:<column> in <package-id>:TcType }}} A `TyVar` is showing up where a `TcTyVar` is expected. I'm pretty certain this is harmless in a production compiler, but reflects an infelicity somewhere. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12826> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12821: Find the incredible vanishing [The improvement story]
by GHC 25 Nov '16

25 Nov '16

#12821: Find the incredible vanishing [The improvement story] -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- Somehow we lost Note [The improvement story] in `TcInteract`. There are references to it in `TcInteract` and `TcRnTypes` but the note itself is nowhere to be found. Someone must find it before it reaches the county border! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12821> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12526: regression in type inference with respect to type families
by GHC 25 Nov '16

25 Nov '16

#12526: regression in type inference with respect to type families -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following bug is present in ghc-8.0.1.20160725, ghc-8.0.1.20160822 (ghc-8.0.2) and ghc-8.1.20160819 (ghc-head) and was not there in ghc-8.0.1. When compiling the head version of synthesizer-llvm package from http://code.haskell.org/synthesizer/llvm/ I get the following error: {{{ src/Synthesizer/LLVM/Server/CausalPacked/Instrument.hs:296:23: error: • Couldn't match type ‘Synthesizer.Causal.Class.ProcessOf t0’ with ‘CausalP.T (SampleRate Real, ())’ Expected type: CausalP.T (SampleRate Real, ()) (Serial.T (LLVM.Value (LLVM.Vector (TypeNum.Pos Type.Data.Num.Decimal.Digit.Dec4 TypeNum.EndDesc) Float)), (Serial.Value (TypeNum.Pos Type.Data.Num.Decimal.Digit.Dec4 TypeNum.EndDesc) Real, VectorValue)) (Serial.T (LLVM.Value (LLVM.Vector (TypeNum.Pos Type.Data.Num.Decimal.Digit.Dec4 TypeNum.EndDesc) Float))) Actual type: Synthesizer.Causal.Class.ProcessOf t0 (Serial.T (LLVM.Value (LLVM.Vector (TypeNum.Pos Type.Data.Num.Decimal.Digit.Dec4 TypeNum.EndDesc) Float)), (Serial.Value (TypeNum.Pos Type.Data.Num.Decimal.Digit.Dec4 TypeNum.EndDesc) Float, Serial.Value (TypeNum.Pos Type.Data.Num.Decimal.Digit.Dec4 TypeNum.EndDesc) Float)) (Serial.T (LLVM.Value (LLVM.Vector (TypeNum.Pos Type.Data.Num.Decimal.Digit.Dec4 TypeNum.EndDesc) Float))) The type variable ‘t0’ is ambiguous • In the first argument of ‘($&)’, namely ‘osci’ In the second argument of ‘liftA2’, namely ‘(osci $& shapeCtrl &|& (expo &|& fmap Stereo.left freqs))’ In the expression: liftA2 Stereo.cons (osci $& shapeCtrl &|& (expo &|& fmap Stereo.left freqs)) (osci $& shapeCtrl &|& (negate expo &|& fmap Stereo.right freqs)) • Relevant bindings include osci :: Synthesizer.Causal.Class.ProcessOf t0 (Serial.T (LLVM.Value (LLVM.Vector (TypeNum.Pos Type.Data.Num.Decimal.Digit.Dec4 TypeNum.EndDesc) Float)), (Serial.Value (TypeNum.Pos Type.Data.Num.Decimal.Digit.Dec4 TypeNum.EndDesc) Float, Serial.Value (TypeNum.Pos Type.Data.Num.Decimal.Digit.Dec4 TypeNum.EndDesc) Float)) (Serial.T (LLVM.Value (LLVM.Vector (TypeNum.Pos Type.Data.Num.Decimal.Digit.Dec4 TypeNum.EndDesc) Float))) (bound at src/Synthesizer/LLVM/Server/CausalPacked/Instrument.hs:294:19) }}} The type for `t0` should be known and then the type checker should be able to check that `ProcessOf t0` equals `CausalP.T`. It did so in earlier versions but now fails on that part. I still have to reduce that example, but for now I want to alert you that there seems to be a regression in the type inference. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12526> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16