August 2018 - ghc-tickets

[GHC] #13408: Consider inferring a higher-rank kind for type synonyms
by GHC 28 Feb '19

28 Feb '19

#13408: Consider inferring a higher-rank kind for type synonyms -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: TypeInType | 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 terms, a definition comprising one non-recursive equation may have a higher-rank type inferred. For example: {{{#!hs f :: (forall a. a -> a -> a) -> Int f z = z 0 1 g = f }}} `g` gets an inferred type equal to `f`'s. However, this fails at the type level: {{{#!hs type F (z :: forall a. a -> a -> a) = z 0 1 type G = F }}} If anything is strange here, it's that the term-level definition is accepted. GHC should not be in the business of inferring higher-rank types. But there is an exception for definitions comprising one non- recursive equation. This ticket proposes expanding this behavior to the type level, allowing `G` to be accepted. This is spun off from #13399, but is not tightly coupled to that ticket. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13408> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #15463: "Serious" validation failures on i686
by GHC 26 Feb '19

26 Feb '19

#15463: "Serious" validation failures on i686 -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: None/Unknown Test Case: T3171, | Blocked By: heapprof001 | Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- A very recent run of `./validate` on i686 revealed 6 failures, 4 of which I'm hopefully fixing with [https://phabricator.haskell.org/D5031 D5031], but the other two look more serious. The circle ci build logs are here: https://circleci.com/gh/ghc/ghc/7578 One of the remaining failures in particular seems somewhat critical: {{{ Wrong exit code for heapprof001(prof_hc_hb)(expected 0 , actual 139 ) Stdout ( heapprof001 ): a <= a <= a <= a <= a <= a <= a <= Stderr ( heapprof001 ): Segmentation fault *** unexpected failure for heapprof001(prof_hc_hb) }}} While the other one might be a lot simpler: {{{ Actual stdout output differs from expected: --- ./ghci/should_run/T3171.run/T3171.stdout.normalised 2018-07-31 05:27:01.821192706 +0000 +++ ./ghci/should_run/T3171.run/T3171.run.stdout.normalised 2018-07-31 05:27:01.821192706 +0000 @@ -1 +0,0 @@ -Interrupted. *** unexpected failure for T3171(normal) }}} I have not investigated any of those yet, but the first one does seem like a bug. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15463> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10170: Find versioned versions of LLVM tools
by GHC 26 Feb '19

26 Feb '19

#10170: Find versioned versions of LLVM tools -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 (LLVM) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Since it has become more widely know that the LLVM developers often make breaking changes to the IR language between releases, some Linu distributions (eg Debain and hence Ubuntu) have started doing multi- version LLVM installs. For instance on Debian, the llvm-3.6 programs are installed in `/usr/lib/llvm-3.6/bin` as `llc` and `opt`. I propose that the `configure.ac` and `aclocal.m4` configuration goop be modified to look for `llc` and `opt` in these versioned `/usr/lib/llvm-X.Y` locations. I'm also willing to do the hard yards on implementing this if people think its a good idea. This can be seen as a step along the way to more stringent LLVM versioning requirements. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10170> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #15029: haddock parsing fails with valid input
by GHC 23 Feb '19

23 Feb '19

#15029: haddock parsing fails with valid input -------------------------------------+------------------------------------- Reporter: lerkok | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Reported here: https://github.com/haskell/haddock/issues/798 This is really a GHC parsing issue, even though it only shows up in the haddock "route." -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15029> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #14198: Inconsistent treatment of implicitly bound kind variables as free-floating
by GHC 22 Feb '19

22 Feb '19

#14198: Inconsistent treatment of implicitly bound kind variables as free-floating -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new 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: #7873 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- (Spun off from the discussion starting at https://phabricator.haskell.org/D3872#109927.) This program is accepted: {{{#!hs {-# LANGUAGE ExistentialQuantification #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} import Data.Proxy data Foo = MkFoo (forall a. Proxy a) }}} There's something interesting going on here, however. Because `PolyKinds` is enabled, the kind of `a` is generalized to `k`. But where does `k` get quantified? It turns out that it's implicitly quantified as an existential type variable to `MkFoo`: {{{ λ> :i Foo data Foo = forall k. MkFoo (forall (a :: k). Proxy a) }}} This was brought up some time ago in #7873, where the conclusion was to keep this behavior. But to make things stranger, it you write out the kind of `a` explicitly: {{{#!hs {-# LANGUAGE ExistentialQuantification #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} import Data.Proxy data Foo2 = MkFoo2 (forall (a :: k). Proxy a) }}} Then GHC will reject it: {{{ Bug.hs:7:1: error: Kind variable ‘k’ is implicitly bound in data type ‘Foo2’, but does not appear as the kind of any of its type variables. Perhaps you meant to bind it (with TypeInType) explicitly somewhere? | 7 | data Foo2 = MkFoo2 (forall (a :: k). Proxy a) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} So GHC's treatment is inconsistent. What should GHC do? We could: * Have both be an error. * Have both be accepted, and implicitly quantify `k` as an existential type variable * Have both be accepted, and implicitly quantify `k` in the `forall` itself. That is: {{{#!hs MkFoo :: (forall {k} (a :: k). Proxy k a) -> Foo }}} * Something else. When you try a similar trick with type synonyms: {{{#!hs {-# LANGUAGE ExistentialQuantification #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} import Data.Proxy type Foo3 = forall a. Proxy a }}} Instead of generalizing the kind of `a`, its kind will default to `Any`: {{{ λ> :i Foo3 type Foo3 = forall (a :: GHC.Types.Any). Proxy a }}} Would that be an appropriate trick for data types as well? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14198> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #15227: Add PrelRules for par#
by GHC 21 Feb '19

21 Feb '19

#15227: Add PrelRules for par# -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: Newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `seq#` and `spark#` are elided when their arguments are known to be evaluated. `par#`, however, is not. Presumably this leads to sparks being created and then immediately going away. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15227> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12564: Type family in type pattern kind
by GHC 20 Feb '19

20 Feb '19

#12564: Type family in type pattern kind -------------------------------------+------------------------------------- Reporter: int-index | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: TypeInType, | Operating System: Unknown/Multiple TypeFamilies | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I want to write a type family that is analogous to `!!` for lists but requires the index to be no bigger than the length of the list. Usually, in dependently typed languages finite sets are used for this purpose, here's an attempt to do so in Haskell: {{{#!haskell {-# LANGUAGE TypeInType, TypeFamilies, GADTs, TypeOperators #-} import Data.Kind data N = Z | S N type family Len (xs :: [a]) :: N where Len '[] = Z Len (_ ': xs) = S (Len xs) data Fin :: N -> Type where FZ :: Fin (S n) FS :: Fin n -> Fin (S n) type family At (xs :: [a]) (i :: Fin (Len xs)) :: a where At (x ': _) FZ = x At (_ ': xs) (FS i) = At xs i }}} It fails to compile with this error: {{{ FinAt.hs:16:3: error: • Illegal type synonym family application in instance: 'FZ • In the equations for closed type family ‘At’ In the type family declaration for ‘At’ }}} That's because the kind of the `FZ` pattern (first clause of `At`) has the kind `Fin (Len xs)` and the application of `Len` cannot reduce completely. `checkValidTypePat` then disallows the pattern, as it contains a type family application. I tried to suppress `checkValidTypePat` and the definition of `At` has compiled; however, it's of little use, since `At` doesn't reduce: {{{#!haskell x :: At '[Bool] FZ x = True }}} results in {{{ FinAt.hs:20:5: error: • Couldn't match expected type ‘At * ((':) * Bool ('[] *)) ('FZ 'Z)’ with actual type ‘Bool’ • In the expression: True In an equation for ‘x’: x = True }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12564> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #15176: Superclass `Monad m =>` makes program run 100 times slower
by GHC 20 Feb '19

20 Feb '19

#15176: Superclass `Monad m =>` makes program run 100 times slower -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hi! I've just encountered a very bizarre error. === General description === The code: {{{ class LayersFoldableBuilder__ t (layers :: [Type]) m where buildLayersFold__ :: SomePtr -> m (Fold.Result t) -> m (Fold.Result t) instance Monad m => LayersFoldableBuilder__ t '[] m where buildLayersFold__ = \_ a -> a {-# INLINE buildLayersFold__ #-} instance ( MonadIO m , Storable.Storable (Layer.Cons l ()) , Layer.StorableLayer l m , LayerFoldableBuilder__ (EnabledLayer t l) t m l , LayersFoldableBuilder__ t ls m ) => LayersFoldableBuilder__ t (l ': ls) m where buildLayersFold__ = \ptr mr -> do let fs = buildLayersFold__ @t @ls ptr' ptr' = Ptr.plusPtr ptr $ Layer.byteSize @l layerBuild__ @(EnabledLayer t l) @t @m @l ptr $! fs mr {-# INLINE buildLayersFold__ #-} }}} This is a typeclass `LayersFoldableBuilder__` and ALL of its instances. Please note, that every instance has a `Monad m` or `MonadIO m` constraint. The program which uses this code heavily runs in 40ms. If we only add constraint `Monad m =>` to the class definition: {{{ class Monad m => LayersFoldableBuilder__ t (layers :: [Type]) m where buildLayersFold__ :: SomePtr -> m (Fold.Result t) -> m (Fold.Result t) }}} The program runs in 3.5s , which is almost 100 times slower. Unfortunatelly I do not have minimal example, but it is reproducible. It is a part of the Luna Language codebase: https://github.com/luna/luna- core/blob/60bf6130691c23e52b97b067b52becb8fdb0c72e/core/src/Data/Graph/Traversal/Scoped.hs#L102 it was introduced in the commit 60bf6130691c23e52b97b067b52becb8fdb0c72e on branch static-layers . However, building this is simple: stack bench luna-core . After invoking it we see the described results. === Why its important and what should we do to fix it === 1. I am writing this because I care about Haskell community. I want GHC and Haskell to be widely used. Right now, the only thing I hear from all companies around our company is that impredicative performance, even when following rules "how to write efficient code" is the biggest pain people have. Haskell is gathering attention - pure functional programming, immutability etc - are great. But it will not become a popular choice unless we care about predictive performance. 2. Such performance changes are unacceptable when thinking about Haskell and GHC as production ready systems. We need a clear way how to write high performance Haskell without the need to benchmark every part of our programs even when refactoring things. GHC has enough information to discover that we want high performance here and there (even by looking at INLINE pragmas) and should warn us about lack of optimization. We should also have a way to force GHC to apply optimizations in particular places - for example by explicit marking code to be always specialized during compilation, so GHC would never fall back to dict-passing in such places. Such possibility would solve MANY related problems and user fears. 3. The point 2 also applies to strictness. In my opinion, having more clear strictness resolution rules / tools is important. Right now the only way to know if strictness analysis did a good job and we are not constantly boxing / unboxing things is to read core, which is tedious and 99% of Haskell users do not even know how to do it (We've got 10 really, really good Haskellers here, 2 of them are capable of reading core, but not very fluently). I would love to chat more about these topics, because they are crucial for growing Haskell community and making Haskell more popular choice, which is waht we want, right? We don't want Haskell to be just a research project with "all its users being its authors" at the same time, am I === What happens in core === I inspected core and have found that indeed, after adding the constraint, GHC does not apply all optimizations to the definitions. To be honest, I completely don't understand it, because the code uses everywhere explicit `INLINE` pragma to be sure everything is optimized away in the compilation stage: {{{ -------------------------------------------------------------------------------- SLOW, without Monad m => -------------------------------------------------------------------------------- -- RHS size: {terms: 5, types: 12, coercions: 4, joins: 0/0} buildLayersFold__ [InlPrag=INLINE] :: forall t (layers :: [*]) (m :: * -> *). LayersFoldableBuilder__ t layers m => SomePtr -> m (Fold.Result t) -> m (Fold.Result t) [GblId[ClassOp], Arity=1, Caf=NoCafRefs, Str=<S,U>, Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=1,unsat_ok=False,boring_ok=True) Tmpl= \ (@ t_ao0O) (@ (layers_ao0P :: [*])) (@ (m_ao0Q :: * -> *)) (v_B1 [Occ=Once] :: LayersFoldableBuilder__ t_ao0O layers_ao0P m_ao0Q) -> v_B1 `cast` (Data.Graph.Traversal.Scoped.N:LayersFoldableBuilder__[0] <t_ao0O>_N <layers_ao0P>_N <m_ao0Q>_N :: (LayersFoldableBuilder__ t_ao0O layers_ao0P m_ao0Q :: Constraint) ~R# (SomePtr -> m_ao0Q (Fold.Result t_ao0O) -> m_ao0Q (Fold.Result t_ao0O) :: *))}] buildLayersFold__ = \ (@ t_ao0O) (@ (layers_ao0P :: [*])) (@ (m_ao0Q :: * -> *)) (v_B1 :: LayersFoldableBuilder__ t_ao0O layers_ao0P m_ao0Q) -> v_B1 `cast` (Data.Graph.Traversal.Scoped.N:LayersFoldableBuilder__[0] <t_ao0O>_N <layers_ao0P>_N <m_ao0Q>_N :: (LayersFoldableBuilder__ t_ao0O layers_ao0P m_ao0Q :: Constraint) ~R# (SomePtr -> m_ao0Q (Fold.Result t_ao0O) -> m_ao0Q (Fold.Result t_ao0O) :: *)) -------------------------------------------------------------------------------- FAST, without Monad m => -------------------------------------------------------------------------------- -- RHS size: {terms: 8, types: 25, coercions: 0, joins: 0/0} Data.Graph.Traversal.Scoped.$p1LayersFoldableBuilder__ :: forall t (layers :: [*]) (m :: * -> *). LayersFoldableBuilder__ t layers m => Monad m [GblId[ClassOp], Arity=1, Caf=NoCafRefs, Str=<S(SL),U(U,A)>, RULES: Built in rule for Data.Graph.Traversal.Scoped.$p1LayersFoldableBuilder__: "Class op $p1LayersFoldableBuilder__"] Data.Graph.Traversal.Scoped.$p1LayersFoldableBuilder__ = \ (@ t_ao0P) (@ (layers_ao0Q :: [*])) (@ (m_ao0R :: * -> *)) (v_B1 :: LayersFoldableBuilder__ t_ao0P layers_ao0Q m_ao0R) -> case v_B1 of v_B1 { Data.Graph.Traversal.Scoped.C:LayersFoldableBuilder__ v_B2 v_B3 -> v_B2 } -- RHS size: {terms: 8, types: 25, coercions: 0, joins: 0/0} buildLayersFold__ :: forall t (layers :: [*]) (m :: * -> *). LayersFoldableBuilder__ t layers m => SomePtr -> m (Fold.Result t) -> m (Fold.Result t) [GblId[ClassOp], Arity=1, Caf=NoCafRefs, Str=<S(LS),U(A,U)>, RULES: Built in rule for buildLayersFold__: "Class op buildLayersFold__"] buildLayersFold__ = \ (@ t_ao0P) (@ (layers_ao0Q :: [*])) (@ (m_ao0R :: * -> *)) (v_B1 :: LayersFoldableBuilder__ t_ao0P layers_ao0Q m_ao0R) -> case v_B1 of v_B1 { Data.Graph.Traversal.Scoped.C:LayersFoldableBuilder__ v_B2 v_B3 -> v_B3 } }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15176> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

[GHC] #13971: Misleading "Kind mis-match on LHS of default declaration" error
by GHC 19 Feb '19

19 Feb '19

#13971: Misleading "Kind mis-match on LHS of default declaration" error -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: TypeFamilies | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This program fails to typecheck, unsurprisingly: {{{#!hs {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} module Bug where class C a where type T a :: k type T a = Int }}} But the error message it gives threw me for a loop initially: {{{ $ /opt/ghc/8.2.1/bin/ghci Bug.hs GHCi, version 8.2.0.20170704: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:7:3: error: • Kind mis-match on LHS of default declaration for ‘T’ • In the default type instance declaration for ‘T’ In the class declaration for ‘C’ | 7 | type T a = Int | ^^^^^^^^^^^^^^ Failed, 0 modules loaded. }}} The LHS of the default declaration is perfectly fine - the real source of the error is the RHS! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13971> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13706: ghci messages like "Ok, modules loaded: ..." are impractical for large sets of modules
by GHC 19 Feb '19

19 Feb '19

#13706: ghci messages like "Ok, modules loaded: ..." are impractical for large sets of modules -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Ghci (in the default config) wants to show me all the modules that are currently loaded. If I have a great many of these (think: hundreds) then this is impractical, because I have to scroll back to see what actually interests me (output of last command). I can change the prompt (`:set prompt "> "`), but I don't see how to switch off the display of all module names in `:r` command. I have to scroll back (several screenfulls) to even find out whether the reload was successful, since the status (OK/Failed) is at the very beginning - and the reason for the Failure is before that. Cf. https://mail.haskell.org/pipermail/haskell-cafe/2017-May/126983.html (but there was no reaction) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13706> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2