June 2018 - ghc-tickets

[GHC] #13531: GHC fails with "Dynamic linker not initialised" when -j is on and trying to load nonexistent .so file
by GHC 07 Aug '18

07 Aug '18

#13531: GHC fails with "Dynamic linker not initialised" when -j is on and trying to load nonexistent .so file -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: #13137, #9868, | #10355 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- For ghc 8.0.2 (on Linux, in nixpkgs `0c041520c3` for exact reproducibility), when TH is used in a `ghc --make -j1` invocation, and thus ghc does the whole {{{ cc -fno-stack-protector -DTABLES_NEXT_TO_CODE '-std=c++14' -Wno- deprecated-declarations --print-file-name liblibglog.so Loading object (dynamic) glog ... done }}} business, and the `.so` file in question does not exist, then usually GHC prints {{{ <command line>: user specified .o/.so/.DLL could not be loaded (libglog.so: cannot open shared object file: No such file or directory) }}} However, I found that when parallel compilation is enabled, (e.g. `ghc -j4`), I can get this instead: {{{ [ 23 of 130] Compiling Mymodule ( Mymodule.hs, dist/build/Mymodule.o ) <no location info>: error: ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): Dynamic linker not initialised Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13531> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #13368: Derive superclasses automatically if possible
by GHC 05 Aug '18

05 Aug '18

#13368: Derive superclasses automatically if possible -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature | Status: new request | 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: #10607 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- So I don't forget, this is like #10607 along another axis. Instead of writing {{{#!hs newtype IO_ a = IO_ (IO a) deriving newtype (Functor, Applicative, Monad, MonadIO) }}} allow writing {{{#!hs newtype IO_ a = IO_ (IO a) deriving newtype MonadIO }}} with the same meaning, are there any technical restrictions to this? This gets annoying in large hierarchies where you need `Eq`, `Ord`, `Num`, `Fractional`, `Floating`, `Real` and `RealFrac` just to derive {{{#!hs newtype F32 = F32 Float deriving newtype RealFloat }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13368> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13555: Typechecker regression when combining PolyKinds and MonoLocalBinds
by GHC 03 Aug '18

03 Aug '18

#13555: Typechecker regression when combining PolyKinds and MonoLocalBinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 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: -------------------------------------+------------------------------------- `lol-0.6.0.0` from Hackage currently fails to build with GHC 8.2.1 because of this regression. Here is a minimized example: {{{#!hs {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE InstanceSigs #-} {-# LANGUAGE MonoLocalBinds #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} module Crypto.Lol.Types.FiniteField (GF(..)) where import Data.Functor.Identity (Identity(..)) data T a type Polynomial a = T a newtype GF fp d = GF (Polynomial fp) type CRTInfo r = (Int -> r, r) type Tagged s b = TaggedT s Identity b newtype TaggedT s m b = TagT { untagT :: m b } class Reflects a i where value :: Tagged a i class CRTrans mon r where crtInfo :: Reflects m Int => TaggedT m mon (CRTInfo r) instance CRTrans Maybe (GF fp d) where crtInfo :: forall m . (Reflects m Int) => TaggedT m Maybe (CRTInfo (GF fp d)) crtInfo = undefined }}} This typechecks OK with GHC 8.0.2, but with 8.2.1, it complains: {{{ $ /opt/ghc/8.2.1/bin/ghci Bug.hs GHCi, version 8.2.0.20170403: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Crypto.Lol.Types.FiniteField ( Bug.hs, interpreted ) Bug.hs:25:14: error: • Couldn't match type ‘k0’ with ‘k2’ because type variable ‘k2’ would escape its scope This (rigid, skolem) type variable is bound by the type signature for: crtInfo :: forall k2 (m :: k2). Reflects m Int => TaggedT m Maybe (CRTInfo (GF fp d)) at Bug.hs:25:14-79 Expected type: TaggedT m Maybe (CRTInfo (GF fp d)) Actual type: TaggedT m Maybe (CRTInfo (GF fp d)) • When checking that instance signature for ‘crtInfo’ is more general than its signature in the class Instance sig: forall (m :: k0). Reflects m Int => TaggedT m Maybe (CRTInfo (GF fp d)) Class sig: forall k2 (m :: k2). Reflects m Int => TaggedT m Maybe (CRTInfo (GF fp d)) In the instance declaration for ‘CRTrans Maybe (GF fp d)’ | 25 | crtInfo :: forall m . (Reflects m Int) => TaggedT m Maybe (CRTInfo (GF fp d)) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Bug.hs:25:14: error: • Could not deduce (Reflects m Int) from the context: Reflects m Int bound by the type signature for: crtInfo :: forall k2 (m :: k2). Reflects m Int => TaggedT m Maybe (CRTInfo (GF fp d)) at Bug.hs:25:14-79 The type variable ‘k0’ is ambiguous • When checking that instance signature for ‘crtInfo’ is more general than its signature in the class Instance sig: forall (m :: k0). Reflects m Int => TaggedT m Maybe (CRTInfo (GF fp d)) Class sig: forall k2 (m :: k2). Reflects m Int => TaggedT m Maybe (CRTInfo (GF fp d)) In the instance declaration for ‘CRTrans Maybe (GF fp d)’ | 25 | crtInfo :: forall m . (Reflects m Int) => TaggedT m Maybe (CRTInfo (GF fp d)) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} Notably, both `PolyKinds` and `MonoLocalBinds` are required to trigger this bug. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13555> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #15141: decideKindGeneralisationPlan is too complicated
by GHC 03 Aug '18

03 Aug '18

#15141: decideKindGeneralisationPlan is too complicated -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Consider this program, which originally comes from #14846. I have decorated it with kind signatures so you can see what is going on {{{ {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE EmptyCase #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE InstanceSigs #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeInType #-} module T14846 where import Data.Kind import Data.Proxy -- Cat :: * -> * type Cat ob = ob -> ob -> Type -- Struct :: forall k. (k -> Constraint) -> * data Struct :: (k -> Constraint) -> Type where S :: Proxy (a::k) -> Struct (cls::k -> Constraint) -- Structured :: forall k -- forall (a:k) (cls:k->Constraint) -> Struct k cls type Structured a cls = (S ('Proxy :: Proxy a) :: Struct cls) -- AStruct :: forall k (cls : k->Constraint). Struct cls -> Type data AStruct :: Struct cls -> Type where AStruct :: cls a => AStruct (Structured a cls) -- StructI :: forall k1 k2 (cls :: k2 -> Constraint). -- k1 -> Struct k2 cls -> Constraint class StructI xx (structured::Struct (cls :: k -> Constraint)) where struct :: AStruct structured -- Hom :: forall k1 k2 (cls :: k2 -> Constraint). -- Cat k1 -> Cat (Struct {k2} cls) data Hom :: Cat k -> Cat (Struct cls) where -- Category :: forall ob. Cat ob -> Constraint class Category (cat::Cat ob) where i :: StructI xx a => ríki a a instance forall (riki :: Cat kx) (cls :: kk -> Constraint). Category riki => Category (Hom riki :: Cat (Struct cls)) where i :: forall xx a. StructI xx a => Hom riki a a i = case struct :: AStruct (Structured a cls) of }}} Focus on the final instance declaration. Do kind inference on the type signature for `i`. I think we should get {{{ i :: forall {k1} {k2} {cls1 :: k2 -> Constraint} forall (xx :: k1) (a :: Struct {k2} cls1). StructI {k1} {k2} xx a => Hom {kx} {k2} riki a a }}} Nothing about `i`'s type signature constraints the `cls` to be the same as the in-scope `cls`. Yes `riki` is in scope, but its kind is unrelated. But at present GHC does not kind-generalise `i`'s type (because of `kindGeneralisationPlan`), so random things in the body of `i` may influence how its kinds get fixed. And if we changed the signature a bit so that it didn't mention `riki` any more, suddenly it ''would'' be kind-generalised. This seems incomprehensibly complicated to me. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15141> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10087: DefaultSignatures: error message mentions internal name
by GHC 03 Aug '18

03 Aug '18

#10087: DefaultSignatures: error message mentions internal name -------------------------------------+------------------------------------- Reporter: | Owner: andreas.abel | Status: new Type: feature | Milestone: request | Version: 7.8.4 Priority: normal | Operating System: Unknown/Multiple Component: Compiler | Type of failure: Other (Type checker) | Blocked By: Keywords: | Related Tickets: Architecture: | Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE DefaultSignatures #-} class C a where reflexive :: a -> Bool default reflexive :: Eq a => a -> Bool reflexive x = x == x data D instance C D where -- /home/abel/play/haskell/bugs/DefaultSig.hs:10:10: -- No instance for (Eq D) arising from a use of ‘Main.$gdmreflexive’ -- In the expression: Main.$gdmreflexive -- In an equation for ‘reflexive’: reflexive = Main.$gdmreflexive -- In the instance declaration for ‘C D’ }}} Error looks odd: The user has not written $gdmreflexive in his code. TODO: Better error message. Maybe this should just trigger a warning that method {{{reflexive}}} is undefined for instance {{{D}}} of {{{C}}}. Like when I remove the default method. {{{ /home/abel/play/haskell/bugs/DefaultSig.hs:10:10: Warning: No explicit implementation for ‘reflexive’ In the instance declaration for ‘C D’ }}} It seems the semantics of a default signature is that each instance *must* implement this method. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10087> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #12096: Attach stacktrace information to SomeException
by GHC 02 Aug '18

02 Aug '18

#12096: Attach stacktrace information to SomeException -------------------------------------+------------------------------------- Reporter: ndtimofeev | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 8.0.1 libraries/base | 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: -------------------------------------+------------------------------------- Now (base 4.9.0.0) ErrorCall contain field for stacktrace information and error fills it. If you add field for stacktrace information to SomeException {{{#!hs data SomeException where SomeExceptionWithLocation :: Exception e => String -> e -> SomeException pattern SomeException :: () => Exception e => e -> SomeException pattern SomeException err <- SomeExceptionWithLocation _ err where SomeException err = SomeExceptionWithLocation "" err }}} and will fills it in throw {{{#!hs throw :: (HasCallStack, Exception e) => e -> a throw e = unsafeDupablePerformIO $ do stack <- currentCallStack raise# (CallStackException e $ if stack /= [] then prettyCallStack ?callStack ++ "\n" ++ renderStack stack else prettyCallStack ?callStack) }}} it will be more useful for ghci users. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12096> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 28

[GHC] #11759: can't decompose ghc.exe path
by GHC 02 Aug '18

02 Aug '18

#11759: can't decompose ghc.exe path --------------------------------------+---------------------------- Reporter: erisco | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------- {{{ erisco@ERICWIN C:\Users\erisco\haskell-platform-bin $ ghc.exe ghc.exe: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-unknown-mingw32): can't decompose ghc.exe path: "C:\\Users\\erisco\\haskell- platform-bin\\ghc.exe" }}} haskell-platform-bin is a symbolic directory link to "C:\Program Files\Haskell Platform\2014.2.0.0\bin". I did this so there would not be spaces in the path because this is causing other issues for me. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11759> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #15148: Allow setting of custom alignments
by GHC 01 Aug '18

01 Aug '18

#15148: Allow setting of custom alignments -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 (NCG) | Keywords: CodeGen | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #15124 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Alignment can introduce a bias to benchmarking results which isn't obvious. To help deal with that I want to add some options adjusting alignment for generated code. To give one example I came across while looking into #15124: Padding a function that **is not even called** in nofib/real/eff/FS by multiples of 8 bytes gave runtimes of ~240ms, ~220ms and ~210ms depending on the padding. At 64 byte it seems to loop around (size of a cache line). At a minimum it should be possible to specify alignment of functions. Potentially we could also consider: * Padding for sections. * Padding for functions * Alignment for info tables. * Padding for info tables. * Alignment for Data The cases where this could have benefits: ---- Problem: We optimize one subroutine changing it's size. This leads to alignment changes for the following functions making overall performance potentially worse. Here aligning functions along cache lines would make benchmarks more resilient against accidental alignment changes. ---- Problem: We might try to optimize code based on a specific benchmark. Going purely by performance of this benchmark we might end up optimizing our code for this specific benchmark instead of the general case. Varying the alignment would to check if our code simply found a optimum for the alignment caused by this benchmark or if it is generally better. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15148> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14928: TH eats 50 GB memory when creating ADT with multiple constructors
by GHC 01 Aug '18

01 Aug '18

#14928: TH eats 50 GB memory when creating ADT with multiple constructors -------------------------------------+------------------------------------- Reporter: YitzGale | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.2.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 TH creates a data type with multiple constructors, GHC consumes huge amounts of memory in what appears to be a highly superlinear manner. A common use case: in the Yesod web framework, localized strings are represented by constructors of a Messages data type, created by a TH splice. There is one constructor for each localized string on the site, possibly hundreds. The splice also creates a class instance for the data type whose method matches against all the constructors for each language for which localizations are provided; this may or may not play a role in the memory leak. This Trac ticket corresponds to this Yesod issue: https://github.com/yesodweb/yesod/issues/1487 Here are two reproductions, and one NON-reproduction: 1. A blank "hello world" Yesod web site, with 500 messages defined for about 30 languages. The single page displays the messages in the user's language. Compiling this program in GHC 8.2.2 (stackage lts-10.5) on Ubuntu 16.04 eats over 50 GB of memory. https://gitub.com/ygale/yesod-bug1487 2. @snoyberg has cut down this reproduction to avoid using any libraries not included with GHC. It is in the same repo, on the {{{snoyberg- master}}} branch. NON-reproduction: The code in this gist, which is similar to what is generated by the TH in the above reproductions, is compiled by GHC without the bat of an eyelash. This demonstrates that the bug requires TH to reproduce. https://gist.github.com/92347aa93d226e31f977a0b62b443aa7 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14928> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #15316: Regarding coherence and implication loops in presence of QuantifiedConstraints
by GHC 31 Jul '18

31 Jul '18

#15316: Regarding coherence and implication loops in presence of QuantifiedConstraints -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (Type checker) | Keywords: | Operating System: Unknown/Multiple QuantifiedConstraints | Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- First of all this piece of code: {{{#!hs {-# LANGUAGE RankNTypes, QuantifiedConstraints #-} -- NB: disabling these if enabled: {-# LANGUAGE NoUndecidableInstances, NoUndecidableSuperClasses #-} import Data.Proxy class Class a where method :: a subsume :: (Class a => Class b) => Proxy a -> Proxy b -> ((Class a => Class b) => r) -> r subsume _ _ x = x value :: Proxy a -> a value p = subsume p p method }}} This produces a nonterminating `value` even though nothing warranting recursion was used. Adding: {{{#!hs value' :: Class a => Proxy a -> a value' p = subsume p p method }}} Produces a `value'` that is legitimately equivalent to `method` in that it equals to the value in the dictionary whenever an instance exists (and doesn't typecheck otherwise). Thus two identical expressions in different instance contexts end up having different values (violating coherence?) If we add: {{{#!hs joinSubsume :: Proxy a -> ((Class a => Class a) => r) -> r joinSubsume p x = subsume p p x }}} The fact that this typechecks suggests that GHC is able to infer `Class a => Class a` at will, which doesn't seem wrong. However, the fact that `Class a` is solved from `Class a => Class a` via an infinite loop of implication constraints is questionable. Probably even outright wrong in absence of `UndecidableInstances`. Another issue is the following: {{{#!hs {-# LANGUAGE ConstraintKinds #-} subsume' :: Proxy c -> ((c => c) => r) -> r subsume' _ x = x }}} {{{ • Reduction stack overflow; size = 201 When simplifying the following type: c Use -freduction-depth=0 to disable this check (any upper bound you could choose might fail unpredictably with minor updates to GHC, so disabling the check is recommended if you're sure that type checking should terminate) • In the type signature: subsume' :: Proxy c -> ((c => c) => r) -> r }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15316> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12