November 2017 - ghc-tickets

[GHC] #14428: Rework HsValBindsLR
by GHC 06 Nov '17

06 Nov '17

#14428: Rework HsValBindsLR -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Once Trees that Grow has been applied to the hsSyn AST, rework `HsValBindsLR` to simplify it. From a comment on https://phabricator.haskell.org/D4147 > Nothing here gives any clue that this is intended for the output of the renamer. And typechecker I think. > Plus I wonder if we'd be better served by {{{#!hs data HsValBindsLR idL idR = ValBinds [(RecFlag, LHsBindsLR idL idR)] [LSig GhcRn] }}} > Then the parser can generate a giant singleton Rec and the renamer can sort it out. Less fuss. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14428> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14426: Inferred type not principle/most general?
by GHC 06 Nov '17

06 Nov '17

#14426: Inferred type not principle/most general? -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- The type inferred for `(#)` is `H a a -> H a a -> H a a` (from [https://arxiv.org/pdf/1309.5135.pdf Coroutining Folds with Hyperfunctions]) {{{#!hs newtype H a b = Fn { invoke :: H b a -> b } -- ( # ) :: H a a -> H a a -> H a a f # g = Fn (\k -> invoke f (g # k)) }}} but a more general type is actually {{{#!hs ( # ) :: H b c -> H a b -> H a c f # g = Fn (\k -> invoke f (g # k)) }}} Is this expected or a blind spot in type inference ---- Same thing in ''ghci'' {{{ $ ghci -ignore-dot-ghci GHCi, version 8.3.20170920: http://www.haskell.org/ghc/ :? for help Prelude> :set prompt "> " > > newtype H a b = Fn { invoke :: H b a -> b } > > f # g = Fn (\k -> invoke f (g # k)) > :t ( # ) ( # ) :: H a a -> H a a -> H a a > > let ( # ) :: H b c -> H a b -> H a c; f # g = Fn (\k -> invoke f (g # k)) > :t ( # ) ( # ) :: H b c -> H a b -> H a c }}} Interestingly writing it in terms of `fix` does not type check with the more general type {{{ > import Data.Function > :t fix $ \self -> \f g -> Fn (\k -> invoke f (self g k)) fix $ \self -> \f g -> Fn (\k -> invoke f (self g k)) :: H a a -> H a a -> H a a > :t (fix $ \self -> \f g -> Fn (\k -> invoke f (self g k))) :: H b c -> H a b -> H a c <interactive>:1:2: error: • Couldn't match type ‘b1’ with ‘a1’ ‘b1’ is a rigid type variable bound by an expression type signature: forall b1 c1 a1. H b1 c1 -> H a1 b1 -> H a1 c1 at <interactive>:1:60-82 ‘a1’ is a rigid type variable bound by an expression type signature: forall b1 c1 a1. H b1 c1 -> H a1 b1 -> H a1 c1 at <interactive>:1:60-82 Expected type: H b1 c1 -> H a1 b1 -> H a1 c1 Actual type: H a1 a1 -> H a1 a1 -> H a1 a1 • In the expression: (fix $ \ self -> \ f g -> Fn (\ k -> ...)) :: H b c -> H a b -> H a c }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14426> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13824: ghc 8.2 does not build for me on ppc64le
by GHC 06 Nov '17

06 Nov '17

#13824: ghc 8.2 does not build for me on ppc64le ---------------------------------+---------------------------------------- Reporter: msuchanek | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Keywords: | Operating System: Linux Architecture: powerpc64 | Type of failure: Building GHC failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ---------------------------------+---------------------------------------- [ 5732s] ghc-stage1: panic! (the 'impossible' happened) [ 5732s] (GHC version 8.2.0.20170613 for powerpc64le-unknown-linux): [ 5732s] dwarfReturnRegNo: Unsupported platform! [ 5732s] CallStack (from HasCallStack): [ 5732s] error, called at compiler/nativeGen/Dwarf/Constants.hs:225:19 in ghc:Dwarf.Constants [ 5732s] [ 5732s] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13824> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14422: {-# complete #-} should be able to be at least partially type directed
by GHC 06 Nov '17

06 Nov '17

#14422: {-# complete #-} should be able to be at least partially type directed -------------------------------------+------------------------------------- Reporter: ekmett | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: 8779 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The fact that `{-# complete #-}` pragma that was added in#8779 is tied to the set of patterns only and not the types involved can make it rather awkward or impossible to use in practice. Say I have a bunch of types that happen to share a common `(:<)` and `Empty` pattern, for views. I'd like to be able to say that for one particular type `{-# complete (:<), Empty #-}` holds, but since both aren't defined in the same module and neither one mentions my type, I'm stuck in the same `-Wno-incomplete-patterns` mess I was in before. I cant move the pragma to the individual view patterns because in general they aren't known to be a complete pattern set. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14422> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14423: {-# complete #-} should be able to handle | like {-# minimal #-}
by GHC 06 Nov '17

06 Nov '17

#14423: {-# complete #-} should be able to handle | like {-# minimal #-} -------------------------------------+------------------------------------- Reporter: ekmett | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: 8779 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It'd be really convenient to be able to specify these like we can with `minimal` pragmas, mixing ands and ors. I wind up with a combinatorial explosion of such annotations for the cases where it works when I have large numbers of patterns. I have at least one use case where something that would be a trivial pattern to express with one (complicated) expression involving `|` becomes 64 lines of complete pragmas, and every time I extend it this count doubles. Consider what happens if you add a mix of actual and smart views of a data type: {{{#!hs {-# language ViewPatterns, PatternSynonyms, GeneralizedNewtypeDeriving #-} newtype Delta = Delta Int deriving (Eq,Num) instance Monoid Delta where mempty = 0 mappend = (+) data Exp = Var !Int | AP !Delta !Exp !Exp | LAM !Delta !Exp rel 0 xs = xs rel d (AP d' l r) = AP (d + d') l r rel d (LAM d' b) = LAM (d + d') b rel _ (Var n) = Var n pattern Ap a b <- AP d (rel d -> a) (rel d -> b) where Ap a b = AP 0 a b pattern Lam b <- LAM d (rel d -> b) where Lam b = LAM 0 b {-# complete Var, AP, Lam #-} {-# complete Var, Ap, LAM #-} {-# complete Var, AP, LAM #-} }}} Every data constructor I add with a smart view adds to the powerset of complete pragmas I should supply. On the other hand with `|` patterns: {{{#!hs {-# complete Var, (Ap | AP), (Lam | LAM) #-} }}} extends linearly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14423> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #1460: Problem with Monoid instance of Data.Map
by GHC 06 Nov '17

06 Nov '17

#1460: Problem with Monoid instance of Data.Map -------------------------------------+------------------------------------- Reporter: ahey@… | Owner: (none) Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.6.1 Resolution: fixed | Keywords: Data.Map | Monoid Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by txnull): I find both instances useful. Maybe there should not be a instance at all and everybody has to create one as needed or create both using newtypes? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1460#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5889: -fno-prof-count-entries leads to linking errors
by GHC 05 Nov '17

05 Nov '17

#5889: -fno-prof-count-entries leads to linking errors -------------------------------------+------------------------------------- Reporter: akio | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by duog): See Phab:D4158 for a testcase that demonstrates this. Replying to [comment:13 simonpj]: > > However, the tick remains in the unfolding > > * Why? If it is dropped in the RHS why isn't it dropped in the unfolding too? At the risk of stating the obvious, because the tick is around a `Case`, not a `Var`. > > * Also, when that unfolding is later inlined at a call site, why isn't the tick eliminated then? My test case illustrates an example of this, hopefully it is clear from the comments what is going on. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5889#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11267: Can't parse type with kind ascription with GHCi's :kind command
by GHC 04 Nov '17

04 Nov '17

#11267: Can't parse type with kind ascription with GHCi's :kind command -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.3 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: -------------------------------------+------------------------------------- I was playing around with GHCi's `:kind` command and noticed that trying to ascribe a type with a kind doesn't parse: {{{ $ inplace/bin/ghc-stage2 --interactive GHCi, version 7.11.20151219: http://www.haskell.org/ghc/ :? for help λ> :set -XTypeInType λ> :kind 'True :: Bool <interactive>:1:7: error: parse error on input ‘::’ }}} This seems like something that should be able to parse, given that `:type True :: Bool` parses just fine. Is there a reason it couldn't? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11267> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14418: Compile errors wxcore-0.92.3.0
by GHC 04 Nov '17

04 Nov '17

#14418: Compile errors wxcore-0.92.3.0 --------------------------------------+--------------------------------- Reporter: WinKlim | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: wxcore | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- I downloaded wxInstall-Achelanne-64-0.1 and started install.bat. The building of wxcore-0.92.3.0 didn't work because of compile errors, e.g. : {{{ src\haskell\Graphics\UI\WXCore\WxcTypes.hs:752:20: error: Ambiguous occurrence `CBool' It could refer to either `Foreign.C.CBool', imported from `Foreign.C' at src\haskell\Graphics\UI\WXCore\WxcTypes.hs:126:1-16 (and originally defined in `Foreign.C.Types') or `Graphics.UI.WXCore.WxcTypes.CBool', defined at src\haskell\Graphics\UI\WXCore\WxcTypes.hs:750:1 | 752 | toCBool :: Bool -> CBool }}} See attachement for full log. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14418> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12199: GHC is oblivious to injectivity when a type family is used in a GADT type
by GHC 04 Nov '17

04 Nov '17

#12199: GHC is oblivious to injectivity when a type family is used in a GADT type -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: TypeFamilies, | Operating System: Unknown/Multiple Injective | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- [https://www.reddit.com/r/haskell/comments/4oeidw/type_family_dependencies_a… A reddit post] points out a limitation of injective type families: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE TypeFamilyDependencies #-} type family Foo a = b | b -> a where Foo Int = Bool data Bar :: * -> * where Bar :: a -> Bar (Foo a) oink :: Bar Bool -> Int oink (Bar x) = x -- type error }}} Compiling this fails with: {{{ Could not deduce: a ~ Int from the context: Bool ~ Foo a }}} Which seems odd, given that `Bool ~ Foo a` should imply `a ~ Int` by injectivity. Even if you change the type signature of `oink` to `Bar (Foo Int) -> Int`, it fails with: {{{ Could not deduce: a ~ Int from the context: Foo Int ~ Foo a }}} which makes it even more apparent that it isn't aware of the fact that `Foo` is injective. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12199> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5