December 2018 - ghc-tickets

[GHC] #12364: Demand analysis for sum types
by GHC 25 Jan '19

25 Jan '19

#12364: Demand analysis for sum types -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | 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: -------------------------------------+------------------------------------- While working on #10613 it crossed my mind that it might be worthwhile to expand the demand type also onto sum types. So instead of {{{ | UProd [ArgUse] -- Product }}} we would have {{{ | UData [[ArgUse]] -- Data type }}} and a function like {{{ fromMaybe :: a -> Maybe a -> b }}} would have a signature of {{{ <1*U><1*U(;1*U)> }}} which indicates that the second argument of `fromMaybe` is evaluated at most once; the first constructor of the result has no arguments, the second (separated by `;`) has one argument which is also used at most once. I could imagine that this gives a lot of useful information with parsers and other code that repeatedly retuns stuff wrapped in a `Maybe` or similar type. Now, sum types are often recursive (`[]`…), and we probably want to be smarter about recursion here. But note that this is not a new problem. If you write {{{ data Stream = Stream Int Stream Stream Stream foo (Stream 0 x y z) = 0 foo (Stream 1 x y z) = foo x foo (Stream 2 x y z) = foo y foo (Stream _ x y z) = foo z }}} you already get huge demand signatures. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12364> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #12599: Add Hadrian build artifacts to gitignore
by GHC 25 Jan '19

25 Jan '19

#12599: Add Hadrian build artifacts to gitignore -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | 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: -------------------------------------+------------------------------------- Andrey wrote requesting the following, > For top-level `.gitignore`: > {{{ > # ------------------------------------------------------------------------------------- > # Hadrian's stuff. Note, **/stageN/ folders will be relocated to _build/ after > # resolving https://github.com/snowleopard/hadrian/issues/113 > # ------------------------------------------------------------------------------------- > _build/ > hadrian/ > **/stage?/ > }}} > > For `.gitignore` in affected submodules (array, deepseq, directory, filepath, > hoopl, hpc, process, utils/hsc2hs): > > {{{ > # ------------------------------------------------------------------------------------- > # Hadrian's stuff. Note, stageN/ folders will be relocated to top-level _build/ > # after resolving https://github.com/snowleopard/hadrian/issues/113 > # ------------------------------------------------------------------------------------- > stage?/ > }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12599> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #16103: docs-haddock Hadrian target doesn't work reliably
by GHC 25 Jan '19

25 Jan '19

#16103: docs-haddock Hadrian target doesn't work reliably -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | 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: -------------------------------------+------------------------------------- Starting with a clean build, the following doesn't work: {{{ $ ./hadrian/build.sh -c docs-haddock }}} However, it does work if you've already run `./hadrian/build.sh -c`. Here's a sample `--verbose` log (this was produced with `./hadrian/build.sh -c --build-root=_qkst-integer-simple --flavour=quickest docs-haddock --integer-simple --verbose`, but the problem exhibits even without all the extra options): {{{ Up to date Up to date | ContextData oracle: resolving data for 'haddock' (Stage2, v)... | Configure package 'haddock' Configuring haddock-2.22.0... creating /Users/atheriault/Code/ghc/_qkst-integer-simple/stage2/utils/haddock/build /Users/atheriault/Code/ghc/_qkst-integer-simple/stage1/bin/ghc --numeric- version /Users/atheriault/Code/ghc/_qkst-integer-simple/stage1/bin/ghc is version 8.7.20181227 /Users/atheriault/Code/ghc/_qkst-integer-simple/stage0/bin/ghc-pkg --version /Users/atheriault/Code/ghc/_qkst-integer-simple/stage0/bin/ghc-pkg is version 8.7.20181227 /Users/atheriault/Code/ghc/_qkst-integer-simple/stage1/bin/ghc --supported-languages /Users/atheriault/Code/ghc/_qkst-integer-simple/stage1/bin/ghc --info Reading installed packages... /Users/atheriault/Code/ghc/_qkst-integer-simple/stage0/bin/ghc-pkg dump --global -v0 '--global-package-db=/Users/atheriault/Code/ghc/_qkst- integer-simple/stage1/lib/package.conf.d' /Users/atheriault/Code/ghc/_qkst-integer-simple/stage1/bin/ghc --print- libdir '-ghcversion-file=/Users/atheriault/Code/ghc/_qkst-integer- simple/generated/ghcversion.h' CallStack (from HasCallStack): die', called at ./Distribution/Simple/Configure.hs:969:20 in Cabal-2.5.0.0-inplace:Distribution.Simple.Configure configureFinalizedPackage, called at ./Distribution/Simple/Configure.hs:467:12 in Cabal-2.5.0.0-inplace:Distribution.Simple.Configure configure, called at ./Distribution/Simple.hs:596:20 in Cabal-2.5.0.0-inplace:Distribution.Simple confHook, called at ./Distribution/Simple/UserHooks.hs:67:5 in Cabal-2.5.0.0-inplace:Distribution.Simple.UserHooks configureAction, called at ./Distribution/Simple.hs:178:19 in Cabal-2.5.0.0-inplace:Distribution.Simple defaultMainHelper, called at ./Distribution/Simple.hs:148:3 in Cabal-2.5.0.0-inplace:Distribution.Simple defaultMainWithHooksNoReadArgs, called at src/Hadrian/Haskell/Cabal/Parse.hs:145:14 in main:Hadrian.Haskell.Cabal.Parse hadrian: Encountered missing dependencies: xhtml ==3000.2.* shakeArgsWith 0.000s 0% Function shake 0.010s 0% Database read 0.317s 12% === With database 0.018s 0% Running rules 2.166s 86% ========================= Total 2.511s 99% Error when running Shake build system: at src/Main.hs:58:30-42: * Depends on: docs-haddock at src/Rules/Documentation.hs:79:9-48: * Depends on: _qkst-integer-simple/docs/html/libraries/index.html at src/Rules/Documentation.hs:136:9-24: * Depends on: _qkst-integer-simple/docs/html/libraries/ghc-prim/ghc- prim.haddock at src/Hadrian/Builder.hs:70:5-23: * Depends on: _qkst-integer-simple/stage2/bin/haddock at src/Development/Shake/Internal/Rules/Oracle.hs:157:43-68: * Depends on: OracleQ (ContextDataKey (Context {stage = Stage2, package = Package {pkgType = Program, pkgName = "haddock", pkgPath = "utils/haddock"}, way = v})) at src/Hadrian/Haskell/Cabal/Parse.hs:202:5-36: * Depends on: _qkst-integer-simple/stage2/utils/haddock/setup-config * Raised the exception: ExitFailure 1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16103> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9476: Implement late lambda-lifting
by GHC 25 Jan '19

25 Jan '19

#9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature request | 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: -------------------------------------+------------------------------------- This ticket exists to coordinate work on Nick Frisby's '''late lambda- lifting''' optimisation. * Wiki page: [wiki:LateLamLift]. All the details are here. * Branch in GHC repo: `wip/llf` * Related tickets * #9279: local closure remains in final program * #9374: static argument transformation -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9476> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 82

[GHC] #15437: Internal error when applying a scoped type variable inside a typed expression quotation
by GHC 24 Jan '19

24 Jan '19

#15437: Internal error when applying a scoped type variable inside a typed expression quotation -------------------------------------+------------------------------------- Reporter: dminuoso | 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: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE TemplateHaskell #-} import TestMod f :: Int f = $$(foo) main :: IO () main = main }}} {{{#!hs {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE TypeApplications #-} module TestMod where import Language.Haskell.TH.Syntax (Q, TExp) get :: forall a. Int get = 1 foo :: forall a. Q (TExp Int) foo = [|| get @a ||] }}} {{{ Test.hs:6:8: error: • The exact Name ‘a’ is not in scope Probable cause: you used a unique Template Haskell name (NameU), perhaps via newName, but did not bind it If that's it, then -ddump-splices might be useful • In the result of the splice: $foo To see what the splice expanded to, use -ddump-splices In the Template Haskell splice $$(foo) In the expression: $$(foo) | 6 | f = $$(foo) | ^^^ Test.hs:6:8: error: • GHC internal error: ‘a’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [r3Kl :-> Identifier[f::Int, TopLevelLet [] True], r3PI :-> Identifier[main::IO (), TopLevelLet [r3PI :-> main] True]] • In the type ‘a’ In the expression: get @a In the result of the splice: $foo To see what the splice expanded to, use -ddump-splices | 6 | f = $$(foo) | }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15437> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #13253: Exponential compilation time with RWST & ReaderT stack with `-02`
by GHC 24 Jan '19

24 Jan '19

#13253: Exponential compilation time with RWST & ReaderT stack with `-02` -------------------------------------+------------------------------------- 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: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- See the attached file. The compilation time grows exponentially with additional fields in `HuteStruct`. Tried with GHC-8.0.1 and quite recent HEAD (8.2) adding a field doubles the compilation time with `-O2`. - 9: 17s - 10: 34s - 11: 83s on my machine. With `-01` around 3sec, independently of the struct size. The original issue: https://github.com/yesodweb/yesod/issues/1348 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13253> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 45

[GHC] #16009: Deprecate `optional` from Text.ParserCombinators.ReadP
by GHC 24 Jan '19

24 Jan '19

#16009: Deprecate `optional` from Text.ParserCombinators.ReadP -------------------------------------+------------------------------------- Reporter: dbaynard | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.3 Component: | Version: 8.6.2 libraries/base | Keywords: Applicative, | Operating System: Unknown/Multiple Parsers, ReadP | Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It seems there is some disagreement on what the type of `optional` should be, within `base`. `Control.Applicative` defines it as {{{#!haskell optional :: Alternative f => f a -> f (Maybe a) }}} By contrast, `Text.ParserCombinators.ReadP` defines it as {{{#!haskell optional :: ReadP a -> ReadP () }}} Worse, ReadP implements `Alternative`. So it entirely possible to specialise {{{#!haskell optional :: ReadP a -> ReadP (Maybe a). }}} In the broader Haskell ecosystem (and beyond) there is further confusion. The `Applicative` definition is used by `parsers`, `megaparsec` and purescript's `Data.Maybe`. The `ReadP` definition is used by `Parsec` and purescript's `Text.Parsing.StringParser`. `Cabal`, like `base` defines both. I propose to begin to deprecate `ReadP.optional` ASAP, following suggestions in https://www.reddit.com/r/haskell/comments/8cqgds/inconsistent_optional_defi…. Code which used the old form may still compile; otherwise `void` should be applied. There have been some suggestions for new names for the `ReadP` definition, such as `optionally` or `optional_`. It may be worth exporting this function directly from `Control.Applicative`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16009> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12920: Overzealous unused-top-binds
by GHC 23 Jan '19

23 Jan '19

#12920: Overzealous unused-top-binds -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2-rc1 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: -------------------------------------+------------------------------------- The following example produces three warnings: {{{ module Foo () where type A = Int type B = A foo :: IO () foo = print (bar 3 :: B) bar :: a -> a bar = id }}} `ghci Foo -Wall` produces {{{ GHCi, version 8.0.1.20161117: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Foo ( Foo.hs, interpreted ) Foo.hs:5:1: warning: [-Wunused-top-binds] Defined but not used: type constructor or class ‘B’ Foo.hs:8:1: warning: [-Wunused-top-binds] Defined but not used: ‘foo’ Foo.hs:11:1: warning: [-Wunused-top-binds] Defined but not used: ‘bar’ Ok, modules loaded: Foo. }}} The three errors reported are inconsistent because GHC reports that `B` is unused, but somehow feels that `A` *is* used. It seems to me that two possibilities could work: 1. GHC reports 1 error: GHC should only report that `foo` is unused, since `A` is used in `B`, `B` is used in `foo`, and `bar` is used in `foo`. This seems like the best approach to me. 2. GHC reports 4 errors: One might choose to apply the definition of "unused" transitively so that, since `foo` is unused, everything used in `foo` is considered unused (unless "used" elsewhere). In this case, `A` should also be reported as unused, but it currently isn't. This definition would be exceedingly useful for removing dead code, but it also produces very noisy output when there is a lot of dead code. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12920> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15470: Record projections with ambiguous types
by GHC 23 Jan '19

23 Jan '19

#15470: Record projections with ambiguous types -------------------------------------+------------------------------------- Reporter: sweirich | Owner: (none) Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- The following code fails {{{ {-# LANGUAGE DataKinds, KindSignatures, PolyKinds, TypeFamilies, RankNTypes, AllowAmbiguousTypes #-} module TypeLambda where data Fun a b type family App (f :: Fun t k) (x :: t) :: k data MONAD m = MONAD { return :: forall a. a -> App m a , (>>=) :: forall a b. App m a -> (a -> App m b) -> App m b } }}} with the error message {{{ TypeLambda.hs:12:5: error: • Couldn't match type ‘App m b0’ with ‘App m b’ Expected type: App m a -> (a -> App m b) -> App m b Actual type: App m a -> (a -> App m b0) -> App m b0 NB: ‘App’ is a non-injective type family The type variable ‘b0’ is ambiguous • In the expression: (>>=) In an equation for ‘TypeLambda.>>=’: (TypeLambda.>>=) MONAD {>>= = (>>=)} = (>>=) • Relevant bindings include (>>=) :: forall a b. App m a -> (a -> App m b) -> App m b (bound at TypeLambda.hs:12:5) | 12 | , (>>=) :: forall a b. App m a -> (a -> App m b) -> App m b | ^^^^^ Failed, no modules loaded. }}} However, with ScopedTypeVariables and TypeApplications, it is possible to define the projections: {{{ data MONAD2 m = MONAD2 (forall a. a -> App m a) (forall a b. App m a -> (a -> App m b) -> App m b) bind :: forall b a m. MONAD2 m -> App m a -> (a -> App m b) -> App m b bind (MONAD2 _ b) = b @a @b }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15470> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15646: ghci takes super long time to find the type of large fractional number
by GHC 23 Jan '19

23 Jan '19

#15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Keywords: type | 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: -------------------------------------+------------------------------------- {{{ :t 1e123456789 }}} takes more than 3 seconds to get the type info. {{{ :t 1e1234111111111111111111111 }}} shows a warning/error, {{{ GNU MP: Cannot allocate memory (size=93978265) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15646> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 86