September 2016 - ghc-tickets

[GHC] #12490: ApplicativeDo and RebindableSyntax do not desugar as expected
by GHC 02 Apr '17

02 Apr '17

#12490: ApplicativeDo and RebindableSyntax do not desugar as expected -------------------------------------+------------------------------------- Reporter: AaronFriel | 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 a module with -XApplicativeDo, -XRebindableSyntax, and local definitions for everything in the Functor-Applicative-Monad hierarchy, do- notation always desugars to "join (... (return ...))" (or /s/return/pure/). This forces the result to have at least the constraints of join, which in my case is "IxMonad m". {{{#!hs {-# LANGUAGE RebindableSyntax, ApplicativeDo #-} module My where -- straightforward definitions of fmap, pure, (<*>), join, return, (>>=), (>>) and fail in terms of IxFunctor, IxPointed, IxApplicative, IxMonad fPure m = do a <- m b <- m pure (a, b) fReturn m = do a <- m b <- m return (a, b) }}} According to -ddump-ds, these desugar to: {{{#!hs fPure :: IxMonad m => m k1 k1 a -> m k1 k1 (a, a) fPure m = My.join ( My.(<*>) (My.fmap (\a b -> My.pure (a, b)) m) m ) fReturn :: IxMonad m => m k1 k1 a -> m k1 k1 (a, a) fReturn m = My.join ( My.(<*>) (My.fmap (\a b -> My.return (a, b)) m) m ) }}} But I would expect: {{{#!hs fPure m = My.(<*>) (My.fmap (\a b -> (a, b)) m) m fReturn m = -- same }}} It appears that when "return" is not from base, ApplicativeDo only partially desugars to the specification. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12490> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #11612: Bug in ApplicativeDo
by GHC 02 Apr '17

02 Apr '17

#11612: Bug in ApplicativeDo -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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 discovered a bug in `ApplicativeDo`. Fix coming shortly. The problem is illustrated by this test case, which I will add to `ado001.hs` in the testsuite: {{{ test11 :: M () test11 = do x1 <- a let x2 = x1 x3 <- b let x4 = c x5 = x4 return (const () (x1,x2,x3,x4)) }}} Which should give `(a | b)`, but gives `(a ; b)` in 8.0.1 RC. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11612> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8501: Improve error message when using rec/mdo keyword without RecursiveDo extention.
by GHC 29 Mar '17

29 Mar '17

#8501: Improve error message when using rec/mdo keyword without RecursiveDo extention. -------------------------------------+------------------------------------- Reporter: shelarcy | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3968 | -------------------------------------+------------------------------------- GHC shows unhelpful error message when using rec keyword and/or mdo keyword without RecursiveDo extention. {{{ module NoRecursiveDo where foo = do rec str <- return "foo" putStrLn str }}} {{{ $ ghc -c NoRecursiveDo.hs NoRecursiveDo1.hs:4:5: Parse error in pattern: rec }}} {{{ module NoRecursiveDo2 where bar = mdo str <- return "bar" putStrLn str }}} {{{ $ ghc -c NoRecursiveDo2.hs NoRecursiveDo2.hs:4:9: parse error on input `<-' }}} {{{ module NoRecursiveDo3 where baz = mdo putStrLn "baz" }}} {{{ $ ghc -c NoRecursiveDo3.hs NoRecursiveDo3.hs:3:7: Not in scope: `mdo' Perhaps you meant `mod' (imported from Prelude) }}} I think that GHC should suggest to use RecursiveDo extention when using mdo/rec keyword. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8501> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12181: Multi-threaded code on ARM64 GHC runtime doesn't use all available cores
by GHC 27 Mar '17

27 Mar '17

#12181: Multi-threaded code on ARM64 GHC runtime doesn't use all available cores -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.10.3 System | Keywords: | Operating System: Unknown/Multiple Architecture: arm | Type of failure: Runtime | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is the machine: [http://www.cnx-software.com/2016/04/30/setup-guide-mini-review-of-bq- aquaris-m10-ubuntu-edition-tablet-from-a-developers-perspective/] Haskell ray-tracer that uses Control.Parallel.Strategies and parBuffer that is working well on x64 machine and using all the cores available use only 2 cores from 4 in total on that ARM machine. This machine usually work on two cores only and when it sees that they are used more - it enables two more to get total of four cores. If I give "+RTS -N4" it works just fine. So I think the problem is that the runtime doesn't check for all available cores, but only for enabled. In the first link you could see that "lscpu" returns 4 cores in total. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12181> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #9418: Warnings about "INLINE binder is (non-rule) loop breaker"
by GHC 27 Mar '17

27 Mar '17

#9418: Warnings about "INLINE binder is (non-rule) loop breaker" -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Gabor rightly complains: I see literally ''thousands'' of these warnings (in yesterday's and) today's bootstraps: {{{ HC [stage 1] libraries/base/dist-install/build/GHC/Base.o *** Core Lint warnings : in result of Desugar (after optimization) *** {-# LINE 261 "libraries/base/GHC/Base.lhs #-}: Warning: [RHS of $c>>_arr :: forall r_agf a_adQ b_adR. (r_agf -> a_adQ) -> (r_agf -> b_adR) -> r_agf -> b_adR] INLINE binder is (non-rule) loop breaker: $c>>_arr {-# LINE 632 "libraries/base/GHC/Base.lhs #-}: Warning: [RHS of $c>>_apH :: forall a_adQ b_adR. GHC.Types.IO a_adQ -> GHC.Types.IO b_adR -> GHC.Types.IO b_adR] INLINE binder is (non-rule) loop breaker: $c>>_apH }}} }}} This is clearly unsatisfactory, because it is unsettling, and perhaps conceals more important warnings. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9418> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12137: Warning about “INLINE binder is (non-rule) loop breaker” with `-dcore-lint`
by GHC 27 Mar '17

27 Mar '17

#12137: Warning about “INLINE binder is (non-rule) loop breaker” with `-dcore-lint` -------------------------------------+------------------------------------- Reporter: Iceland_jack | 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: -------------------------------------+------------------------------------- With this code using `lens` {{{#!hs {-# Language TemplateHaskell #-} import Control.Lens data Config = Config { _companyName :: String } data AppState = AppState { _asConfig :: Config } makeClassy ''Config instance HasConfig AppState where config = undefined }}} gives {{{ $ ghci -ignore-dot-ghci -dcore-lint /tmp/tvQq.hs GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/tvQq.hs, interpreted ) *** Core Lint warnings : in result of Simplifier *** /tmp/tvQq.hs:10:10: warning: [RHS of $ccompanyName_a7EP :: Lens' AppState String] INLINE binder is (non-rule) loop breaker: $ccompanyName_a7EP *** Core Lint warnings : in result of Simplifier *** /tmp/tvQq.hs:10:10: warning: [RHS of $ccompanyName_a7EP :: Lens' AppState String] INLINE binder is (non-rule) loop breaker: $ccompanyName_a7EP Ok, modules loaded: Main. *Main> }}} ---- `makeClass` actually dumps {{{ <interactive>:64:54-72: Splicing declarations makeClassy ''Config ======> class HasConfig c_axo7 where config :: Lens' c_axo7 Config companyName :: Lens' c_axo7 String {-# INLINE companyName #-} companyName = (.) config companyName instance HasConfig Config where {-# INLINE companyName #-} config = id companyName = iso (\ (Config x_axo8) -> x_axo8) Config }}} Using that to create a small example ---- {{{#!hs data Config = Config { name :: String } class HasConfig a where config :: a -> Config companyName :: a -> String {-# INLINE companyName #-} companyName a = name (config a) instance HasConfig Config where {-# INLINE companyName #-} config = id companyName = name . config }}} which works perfectly fine without `-dcore-lint` but fails with {{{ $ ghci -ignore-dot-ghci -dcore-lint /tmp/tvQq.hs GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/tvQq.hs, interpreted ) *** Core Lint warnings : in result of Simplifier *** /tmp/tvQq.hs:11:3: warning: [RHS of $ccompanyName_a18Q :: Config -> String] INLINE binder is (non-rule) loop breaker: $ccompanyName_a18Q *** Core Lint warnings : in result of Simplifier *** /tmp/tvQq.hs:11:3: warning: [RHS of $ccompanyName_a18Q :: Config -> String] INLINE binder is (non-rule) loop breaker: $ccompanyName_a18Q Ok, modules loaded: Main. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12137> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9701: GADTs not specialized properly
by GHC 21 Mar '17

21 Mar '17

#9701: GADTs not specialized properly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Runtime Blocked By: | performance bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This has probably been raised before, but I can't find a ticket. If I write {{{#!hs data Silly a where Silly :: Ord a => a -> Silly a isItSilly :: a -> Silly a -> Bool isItSilly a (Silly x) = a < x isItSillyInt :: Int -> Silly Int -> Bool isItSillyInt = isItSilly }}} then I get {{{ isItSilly isItSilly = \ @ a_aBq eta_B2 eta1_B1 -> case eta1_B1 of _ { Silly $dOrd_aBs x_aAy -> < $dOrd_aBs eta_B2 x_aAy } isItSillyInt isItSillyInt = isItSilly }}} Although GHC knows that `eta_B2` is an `Int`, and `x_aAy` therefore must be one as well, it looks up the `<` method in the `eta1_B1` dictionary instead of just using `ltInt`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9701> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #8751: Show parenthesised output of expressions in ghci
by GHC 20 Mar '17

20 Mar '17

#8751: Show parenthesised output of expressions in ghci ------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Iceland_jack Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Operator fixity can be a source of bugs (even for experienced users!),[#point1 (1)] precedence levels may vary between languages and then there are user-defined operators. Attached is a patch for a ghci command allowing users to quickly parenthesise expressions as a sanity check (and as an alternative to using :info and parsing the result yourself). The command itself is activated with `:paren`: {{{ ghci> :paren 2 + 10 * 4 / 3 2 + ((10 * 4) / 3) ghci> :paren \a b → a == b || b && a == (b == a) || b \ a b -> (a == b) || ((b && (a == (b == a))) || b) ghci> :paren 5 + 1 `mod` 2 5 + (1 `mod` 2) ghci> :paren 5 * 1 `mod` 2 (5 * 1) `mod` 2 }}} A friend of mine also pointed out that this could eventually be integrated into `haskell-mode` where the user could temporarily replace an expression with a parenthesised version or have different colours indicate different levels of logical nesting. [=#point1 (1)] [http://www.knosof.co.uk/cbook/accu06.html Developer beliefs about binary operator precedence] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8751> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #12518: Allow customizing immutable package dbs by stacking
by GHC 19 Mar '17

19 Mar '17

#12518: Allow customizing immutable package dbs by stacking -------------------------------------+------------------------------------- Reporter: harendra | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Package | Version: 8.0.1 system | 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: -------------------------------------+------------------------------------- = Package Selection Across Multiple Package DBs = As explained by ezyang, when there are multiple package dbs, GHC chooses the packages to use in the following manner. I might have misunderstood so please correct me if I am wrong. * If there are multiple packages with different versions the latest non- broken version is chosen. * If the there are multiple packages with the same version the behavior is unspecified. * If there are multiple packages with the same package-id (shadowing) then the one which comes first in `GHC_PACKAGE_PATH` or which comes first on command line (`-package` flag) will be used. = The Problem = The build tool `Stack` implements stacked package databases. It uses a base package database and then stacks another package database on top of it to customise it further without modifying. The behavior is such that the package db on top of the stack completely overrides the ones below. That means you choose a package from top of the stack even if the version is older. Stack implements this by passing explicit package-ids of the packages to GHC. This scheme works well for cabal projects where we know ALL the packages used by the project in advance. But it does not work for scripts run using runghc. In that case we do not know the packages required by the script in advance and therefore cannot pass the package-ids to GHC. That means we cannot make GHC use the packages in the right way. GHC will choose the latest version even though we want it to choose a possibly older version from the top of the db stack. = Proposed Solution = Implement a new CLI option, something like `--stacked-pkg-dbs`. If this option is used GHC will use `GHC_PACKAGE_PATH` or the -package-db options as a stack of dbs. The first db in the path or the first CLI option will be considered the top of the stack. GHC will choose a package from the first db from the top of the stack irrespective of the version of the package. If the package is broken it should report error rather than silently choosing from the next db. This will allow us to modify an immutable package db by stacking another db on top. Implementing this as a separate option will keep the existing behavior so as to remain backward compatible. This has been discussed in a stack issue on github [https://github.com/commercialhaskell/stack/issues/1957 here]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12518> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #11796: Warn about unwanted instances in a modular way
by GHC 19 Mar '17

19 Mar '17

#11796: Warn about unwanted instances in a modular way -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- I like to propose the following way to warn about instances that are unwanted by some programmers. First step is to mark the instances at their definition site like so: {{{#!hs {-# WARN_INSTANCE tuple #-} instance Foldable ((,) a) where ... {-# WARN_INSTANCE tuple #-} instance Functor ((,) a) where ... {-# WARN_INSTANCE tuple #-} instance Foldable ((,,) a b) where ... {-# WARN_INSTANCE tuple #-} instance Functor ((,,) a b) where ... }}} This way, all the above instances are collected in an instance group labelled `tuple`. At the use sites we introduce a GHC warning option like `-fwarn-instance=tuple`. This warns about any place where any of the `tuple` instances is used. We can either place {{{ GHC-Options: -fwarn-instance=tuple }}} in a Cabal package description in order to issue warnings in a whole package or we can put {{{ {-# OPTIONS_GHC -fwarn-instance=tuple #-} }}} at the top of a module in order to enable the warning per module. Another candidate for an instance group might be `numeric` for numeric instances of functions and tuples in the `NumInstances` package. What does it mean to use an instance? I would say, if omitting an `instance X Y` would lead to a "missing instance" type error at place Z in a module, then `instance X Y` is used at place Z. There might be an even more restrictive option like `-fforbid- instance=tuple`. This would not only warn about an instance usage, but it would cause a type error. Essentially it should treat all `tuple` instances as if they were not defined. (Other instances might depend on `tuple` instances and if the `tuple` instances weren't there the compiler would not even reach the current module. I do not know, whether this case needs special treatment. We might require that any instance depending on `tuple` must be added to the `tuple` group as well or it might be added automatically.) The advantage of a type error is that we see all problems from `tuple` instances also in the presence of other type errors. Warnings would only show up after a module is otherwise type correct. This solution requires cooperation of the instance implementor. Would that work in practice? Otherwise we must think about ways to declare instance groups independently from the instance declaration and we get the problem of bringing the instance group names into the scope of the importing module. A separate discussion must be held on whether `-fwarn-instance=tuple` should be part of `-Wall`. I think that people should be warned about `tuple` instances early because they won't expect that there is a trap when using `length` and `maximum` and so on. One might also think about generalizations, e.g. whether {{{ {-# WARN_INSTANCE tuple, functor #-} }}} should be allowed in order to put an instance in several groups or whether there should be a way to compose a group from subgroups. Another topic would be a form of instance group disambiguation. Instance groups might be qualified with module or package names. I think package names are more appropriate, like so `-fwarn-instance=base:tuple`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11796> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8