November 2018 - ghc-tickets

[GHC] #15762: ghci command: report function's inferred visible type applications
by GHC 05 Dec '18

05 Dec '18

#15762: ghci command: report function's inferred visible type applications -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: GHCi | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #15610 #15613 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Example inspired by #40. ghci already has a [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ghci.html #ghci-cmd-:type-at :type-at] command for reporting a type in a range {{{ >> :type-at X.hs 6 6 6 7 f Int -> Int }}} A similar thing (for integrating into IDEs) is doing the same for visible type applications. An innocent expression like `x y` has a lot going on under the surface {{{#!hs {-# Language RankNTypes #-} {-# Language PolyKinds #-} {-# Language KindSignatures #-} import Data.Kind f :: forall res . (forall k (f :: k -> Type) (a :: k). f a -> res) -> (forall (f :: Type -> Type) . f res) -> res f x y = x y }}} How hard would it be to expand that to `(x @Type @f @res) (y @f)` or (x @Type @Any @res) (y @Any) {{{#!hs f :: forall res (f :: Type -> Type) . (forall k (f :: k -> Type) (a :: k). f a -> res) -> (forall (f :: Type -> Type) . f res) -> res f x y = (x @Type @f @res) (y @f) }}} ---- Other ghci ideas: #15610, #15613 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15762> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13064: Incorrect redudant imports warning
by GHC 05 Dec '18

05 Dec '18

#13064: Incorrect redudant imports warning -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- With a simple package: issue.cabal: {{{ name: issue version: 0 cabal-version: >= 1.10 build-type: Simple library build-depends: base, binary, binary-orphans==0.1.5.2 exposed-modules: Issue }}} Issue.hs: {{{ {-# LANGUAGE DeriveGeneric #-} {-# OPTIONS_GHC -Wall #-} module Issue (T (..)) where import Prelude () import Data.Binary.Orphans import Data.Binary (Binary (..)) import GHC.Generics (Generic) import Data.Aeson (Value) data T = T Value deriving (Generic) instance Binary T }}} GHC 7.10.3 correctly reports: {{{ Issue.hs:7:1: Warning: The import of ‘Data.Binary’ is redundant except perhaps to import instances from ‘Data.Binary’ To import instances alone, use: import Data.Binary() }}} GHC 8.0.1 incorrectly (!!!) reports: {{{ Issue.hs:6:1: warning: [-Wunused-imports] The import of ‘Data.Binary.Orphans’ is redundant except perhaps to import instances from ‘Data.Binary.Orphans’ To import instances alone, use: import Data.Binary.Orphans( }}} but `Binary Value` instance is imported from `Data.Binary.Orphans`. --- In real life while compiling https://github.com/futurice/haskell-mega- repo/blob/93c3f111f39c973769c35725d90c9b8ef9a57de3/futurice- github/src/Futurice/GitHub.hs the `Data.Binary` redundant import isn't reported, as `Futurice.Prelude` exports other stuff, which is used. See https://gist.github.com/phadej/bb26df19c611260ab8f867729def39b9 for minimal imports reported with `-ddump-minimal-imports`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13064> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 51

[GHC] #9221: (super!) linear slowdown of parallel builds on 40 core machine
by GHC 04 Dec '18

04 Dec '18

#9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------+------------------------------------------------- Reporter: | Owner: carter | Status: new Type: bug | Milestone: Priority: high | Version: 7.8.2 Component: | Operating System: Unknown/Multiple Compiler | Type of failure: Compile-time performance bug Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- im seeing slowdowns in parallel builds of a (simple!!) 6 module project when I build it on a 40 core server i'm using for work. for any given ghc invocation with -jn, once n>10, i start to see a super linear slow down as a function of n heres some basic numbers at -j1 0m2.693s at -j4 0m2.507s at -j10 0m2.763s at -j25 0m12.634s at -j30 : 0m39.154s at -j40 : 0m57.511s at -j60 : 2m21.821s these timings are another 2-4x worse if ghc is invoked indirectly via cabal-install / setup.hs according to the linux utility latencytop, 100% of ghc's cpu time was spent on user-space lock contention when I did the -j40 invocation. the timing in the -j40 case stayed the same even when ghc was also passed -O0 (and -fforce-recomp to ensure it did the same ) a bit of experimentation makes me believe that in *ANY* cabalized project on a 40 core machine will exhibit this perf issue. cabal clean ; cabal configure --ghc-options="-j" ; cabal build -j1 should be enough to trigger the lock contention. That said, I'll try to cook up a minimal repro that i can share the source for post haste. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9221> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 90

[GHC] #15937: CI strategy for Gitlab
by GHC 04 Dec '18

04 Dec '18

#15937: CI strategy for Gitlab -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: Component: Continuous | Version: Integration | 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 have been working on the configuration of the staging gitlab instance recently. We managed to hook it up with both Circle CI and Appveyor, for the `ghc/ghc` (''username/repo'') project on our instance. It all works. Things get tricky when it comes to running CI jobs for forks, though. Indeed, our Circle CI script relies on some CI env vars being defined in the CI settings of the project. Those are "secrets" (e.g circle ci API token) that we do not want to make public and encourage everyone to use, which means that CI simply won't work for forks, out of the box, with things as they stand. Ben and I have discussed this a bit and we see 3 different ways to go about this. 1) Forget about the fork-based workflow. We might consider having a reference repo where things get merged and a "sandbox" repo where people could push their branches and get some CI running. They could then create MRs against the "real" repo to get patches merged. This one way or another requires adding new contributors manually to the "sandbox repo". It is quite likely that they could also get "our secrets" by simply tweaking `.gitlab-ci.yml` to print the right env vars, in their branch. 2) We go for a "full gitlab CI" solution, which might require less work than it initially seems as it could use the same docker images and run roughly the same commands as Circle CI. That requires computational resources though, and makes the transition less smooth. We can certainly consider doing some ''additional'' CI with this, if we make the move definitive and end up refining our CI needs, but we definitely don't want to get rid of Circle CI/Appveyor now anyway. 3) We implement a "mediator" service that would have all our secrets and would get hit by gitlab CI jobs to launch builds and report the results & artifacts. It could therefore behave the same regardless of the user/repo/branch that triggers it without exposing anything. This could be put together somewhat quickly but requires enough work that we may not be able to set that up in time for the initial move. It is however the best solution from the user experience (ghc contributor) point of view. People with developer access to the main repo could push there, or in their forks. Others would only push to their forks and create MRs. CI would work the same in all those cases. In my opinion, going with 1) initially and then 3) as soon as possible is the best plan in the long term. It would make for a great contributor experience while requiring very little maintenance. This could also very easily live side by side with some "real" gitlab CI, that doesn't offload the work to an external service. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15937> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15460: Literals overflow
by GHC 04 Dec '18

04 Dec '18

#15460: Literals overflow -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following example: {{{#!hs {-# LANGUAGE MagicHash #-} import GHC.Int main :: IO () main = do let x = I# (0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff#) print x }}} It gets desugared into: {{{#!hs main = print @ Int GHC.Show.$fShowInt (GHC.Types.I# 7237005577332262213973186563042994240829374041602535252466099000494570602495#) }}} Problem: the literal value isn't rounded and there is no overflow warning. It breaks the invariant that literal values in Core have to be in range. Bad things can happen when we break this invariant: {{{#!hs {-# LANGUAGE MagicHash #-} import GHC.Int import Control.Monad main :: IO () main = do let x = I# (0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff#) when (x > maxBound) $ do print "Oups" > ghc TestLitOverflow.hs -Wall -O2 > ./TestLitOverflow "Oups" }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15460> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #15529: runtime bug when profiling retainers
by GHC 04 Dec '18

04 Dec '18

#15529: runtime bug when profiling retainers -------------------------------------+------------------------------------- Reporter: flip101 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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 have this project https://github.com/flip111/ghc-runtime-bug1 When i execute the following commands: {{{ stack clean stack build stack build --ghc-options '-j4 -O0 -rtsopts=all -fprof-auto -fprof-auto- calls -fprof-cafs' --executable-profiling stack exec vfix -- +RTS -hr -sstderr }}} After the compilation messages i get the following error: {{{ vfix: internal error: Invalid object *c in pop() (GHC version 8.4.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Command terminated by signal 6 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15529> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #10739: Resuscitate the humble ticky-ticky profiler
by GHC 04 Dec '18

04 Dec '18

#10739: Resuscitate the humble ticky-ticky profiler -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | 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 Revisions: | -------------------------------------+------------------------------------- The [https://ghc.haskell.org/trac/ghc/wiki/Debugging/TickyTicky ticky- ticky profiler] is known to be quite bit-rotted. Indeed there currently isn't even a definitive list of the counters, much less what they counter and whether they are still accurate. That being said, it can be quite useful and is worth putting effort into bringing back up to grade. There are a few things that need to be done here, 1. Collect a list of the existing counters 2. Work out what they are supposed to be measuring 3. Decide which still have a chance of being useful and accurate 4. ??? 5. Profile! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10739> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #15814: Orphan Instance Overlap Error Message
by GHC 04 Dec '18

04 Dec '18

#15814: Orphan Instance Overlap Error Message -------------------------------------+------------------------------------- Reporter: parsonsmatt | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 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 working on moving some code around which unfortunately relies on orphan instances. This is the error I get: {{{ /home/matt/Projects/cardano-sl/wallet- new/src/Cardano/Wallet/API/V1/Types.hs:1794:27: error: • Overlapping instances for Arbitrary (NonEmpty PaymentDistribution) arising from a use of ‘arbitrary’ Matching instances: instance Arbitrary a => Arbitrary (NonEmpty a) -- Defined in ‘Pos.Util.Example’ instance [safe] Arbitrary a => Arbitrary (NonEmpty a) -- Defined in ‘quickcheck- instances-0.3.18:Test.QuickCheck.Instances.Semigroup’ • In the second argument of ‘(<*>)’, namely ‘arbitrary’ In the first argument of ‘(<*>)’, namely ‘Payment <$> arbitrary <*> arbitrary’ In the first argument of ‘(<*>)’, namely ‘Payment <$> arbitrary <*> arbitrary <*> arbitrary’ | 1794 | <*> arbitrary | ^^^^^^^^^ }}} The first instance is the one that I have defined. The second is defined in library code upstream -- great! I want to use that one instead. However, I don't have a clue which module import is providing that instance. It would be *fantastic* if there was an additional line that says which module imported the instance, or brought it into scope. Multiple modules might do this; in this case, reporting any of them would be fine. Eg: {{{ /home/matt/Projects/cardano-sl/wallet- new/src/Cardano/Wallet/API/V1/Types.hs:1794:27: error: • Overlapping instances for Arbitrary (NonEmpty PaymentDistribution) arising from a use of ‘arbitrary’ Matching instances: instance Arbitrary a => Arbitrary (NonEmpty a) -- Defined in ‘Pos.Util.Example’ -- and imported via | 186 | import Cardano.Wallet.API.V1.Swagger.Example | instance [safe] Arbitrary a => Arbitrary (NonEmpty a) -- Defined in ‘quickcheck- instances-0.3.18:Test.QuickCheck.Instances.Semigroup’ -- and imported via | ??? | this information would literally make my day | • In the second argument of ‘(<*>)’, namely ‘arbitrary’ In the first argument of ‘(<*>)’, namely ‘Payment <$> arbitrary <*> arbitrary’ In the first argument of ‘(<*>)’, namely ‘Payment <$> arbitrary <*> arbitrary <*> arbitrary’ | 1794 | <*> arbitrary | ^^^^^^^^^ }}} I'll have to binary search the import list to try and figure out which module is bringing the instance into scope otherwise. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15814> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #15959: If a type signature is too long to read left-to-right then let it read top-to-bottom.
by GHC 04 Dec '18

04 Dec '18

#15959: If a type signature is too long to read left-to-right then let it read top- to-bottom. -------------------------------------+------------------------------------- Reporter: philderbeast | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- When pretty printing a type signature that is too long to show in one line, can we please break the lines on the top-level punctuation of the type signature, on {{{::}}}, {{{=>}}} and {{{->}}} as shown in the second listing below? {{{ FlareTiming/Task/Score.hs:186:1: warning: [-Wmissing-signatures] Top-level binding with no type signature: showMax :: (Reflex t, Functor f) => (a -> b) -> (f b -> b -> c) -> Dynamic t (f a) -> Dynamic t a -> Dynamic t c | 186 | showMax getField f pt points = | ^^^^^^^ }}} {{{ FlareTiming/Task/Score.hs:186:1: warning: [-Wmissing-signatures] Top-level binding with no type signature: showMax :: (Reflex t, Functor f) => (a -> b) -> (f b -> b -> c) -> Dynamic t (f a) -> Dynamic t a -> Dynamic t c | 186 | showMax getField f pt points = | ^^^^^^^ }}} If a type signature is too long to display in one line and read left-to- right then please let it read top-to-bottom. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15959> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15935: TYPE is not generated by genprimops
by GHC 04 Dec '18

04 Dec '18

#15935: TYPE is not generated by genprimops -------------------------------------+------------------------------------- Reporter: davide | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 8.6.2 Libraries | Keywords: GHC.Magic | Operating System: Unknown/Multiple TYPE haddock GHC.Prim genprimops | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- During validation, GHC.Magic must build without warning, and must also type check with Haddock without warnings. This causes some awkwardness in GHC.Magic (see the comment above the imports regarding genprimops) because TYPE is exported from GHC.Prim and reexported by GHC.Types. We are forced to explicitly import it via GHC.Types (and not from GHC.Prim to avoid an unused import warnings). Importing via GHC.Prim would not type check with Haddock as genprimops doesn't generate TYPE for GHC.Prim. This issue surfaced in patch D5312. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15935> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4