March 2019 - ghc-tickets

[GHC] #13839: GHC warnings do not respect the default module header
by GHC 09 Mar '19

09 Mar '19

#13839: GHC warnings do not respect the default module header -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: (none) 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: -------------------------------------+------------------------------------- If I compile this program with `-Wall`, I get no warnings: {{{#!hs type T = Int main :: IO () main = return () }}} If I add a module header: {{{#!hs module Main(main) where type T = Int main :: IO () main = return () }}} I now get a warning: {{{ ghcbug2.hs:3:1: warning: [-Wunused-top-binds] Defined but not used: type constructor or class ‘T’ }}} Yet, according to Haskell2010 (section 5.1): > An abbreviated form of module, consisting only of the module body, is permitted. If this is used, the header is assumed to be ‘module Main(main) where’. Therefore, the right behaviour should be to print a warning in the first case as well. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13839> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #14741: High-memory usage during compilation using Template Haskell
by GHC 09 Mar '19

09 Mar '19

#14741: High-memory usage during compilation using Template Haskell -------------------------------------+------------------------------------- Reporter: donatello | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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: -------------------------------------+------------------------------------- When trying to embed some files into an executable using Template Haskell, I find that memory usage during compilation exceeds 4GB and often crashes my laptop. The files I am trying to embed are only about 25MB in size (totally 35MB in size). I made a somewhat minimal example to demonstrate this problem. To embed the files, I am using the [https://hackage.haskell.org/package/file-embed `file-embed`] package (the issue persists when using the alternative [https://hackage.haskell.org/package/wai-app-static `wai-app-static`] package too. The code to demonstrate runs in Linux and is available here - https://github.com/donatello/file-embed-exp. To try it out, just clone the repository and run Make (it uses the Haskell Stack tool and the Linux dd utility). This appear to be an issue in GHC. Is there anyway to mitigate the issue in the current version? Related discussion: https://github.com/snoyberg/file-embed/issues/24 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14741> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #16325: Hadrian should respect the build root setting for the testsuite and its own binaries
by GHC 09 Mar '19

09 Mar '19

#16325: Hadrian should respect the build root setting for the testsuite and its own binaries -------------------------------------+------------------------------------- Reporter: snowleopard | 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: -------------------------------------+------------------------------------- Currently the `--build-root` setting is respected only partially: * The `test` rule appears to be placing all testsuite build artefacts right in the GHC tree `./testsuite`. * Hadrian puts its own binaries also in the GHC tree, into the `./hadrian/X` directory, where `X` depends on whether we build with Cabal or Stack. We should improve on this and provide more guarantees about where all build artefacts go. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16325> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #10069: CPR related performance issue
by GHC 09 Mar '19

09 Mar '19

#10069: CPR related performance issue -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- By default CRP analysis can be too aggressive in trying to pass as much as possible in unboxed tuples, in general it's not a problem but when one big datatype is passed to several consumers it might end up pushed to stack several times instead of once - to heap, things are getting worse when there are sufficient fields to cause stack overflow which otherwise is possible to avoid - in our codebase adding one field with ExistentialQuantification (unused, but that prevents ghc from doing CRP transformation) reduces number of stack overflow by a factor of 1000 and increases overall performance by 10%. In provided example performance for both A and B should be identical and yet B is consistently faster by 3-5% It's possible to increase this performance gap by adding more and more fields. I was able to replicate this issue in ghc 7.8.3 and 7.10,1rc2 {{{#!hs {-# LANGUAGE ExistentialQuantification #-} module Blah where import Criterion import Criterion.Main import Data.Typeable data A = A () !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int data B = forall rep. (Typeable rep) => B rep !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int !Int a :: A a = A () 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 b :: B b = B () 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 {-# NOINLINE a1 #-} a1 :: A -> Int a1 (A _ f1 f2 f3 f4 f5 f6 f7 f8 g1 g2 g3 g4 g5 g6 g7 g8 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _) = f1 {-# NOINLINE a2 #-} a2 :: A -> Int a2 (A _ f1 f2 f3 f4 f5 f6 f7 f8 g1 g2 g3 g4 g5 g6 g7 g8 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _) = f2 {-# NOINLINE a3 #-} a3 :: A -> Int a3 (A _ f1 f2 f3 f4 f5 f6 f7 f8 g1 g2 g3 g4 g5 g6 g7 g8 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _) = f3 {-# NOINLINE a4 #-} a4 :: A -> Int a4 (A _ f1 f2 f3 f4 f5 f6 f7 f8 g1 g2 g3 g4 g5 g6 g7 g8 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _) = f4 {-# NOINLINE b1 #-} b1 :: B -> Int b1 (B _ f1 f2 f3 f4 f5 f6 f7 f8 g1 g2 g3 g4 g5 g6 g7 g8 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _) = f1 {-# NOINLINE b2 #-} b2 :: B -> Int b2 (B _ f1 f2 f3 f4 f5 f6 f7 f8 g1 g2 g3 g4 g5 g6 g7 g8 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _) = f2 {-# NOINLINE b3 #-} b3 :: B -> Int b3 (B _ f1 f2 f3 f4 f5 f6 f7 f8 g1 g2 g3 g4 g5 g6 g7 g8 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _) = f3 {-# NOINLINE b4 #-} b4 :: B -> Int b4 (B _ f1 f2 f3 f4 f5 f6 f7 f8 g1 g2 g3 g4 g5 g6 g7 g8 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _) = f4 {-# NOINLINE fa #-} fa :: A -> Int fa a = a1 a + a2 a + a3 a + a4 a {-# NOINLINE fb #-} fb :: B -> Int fb b = b1 b + b2 b + b3 b + b4 b main :: IO () main = defaultMain [ bgroup "single call" [ bench "A" $ whnf fa a , bench "B" $ whnf fb b ] ] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10069> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 39

[GHC] #16376: GHCi HEAD silently accepts ill-kinded visible type applications with :type
by GHC 09 Mar '19

09 Mar '19

#16376: GHCi HEAD silently accepts ill-kinded visible type applications with :type -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: GHCi | Version: 8.9 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If you try something nonsensical like `id @Maybe` in GHCi 8.6.3, it will be properly rejected: {{{ $ ghci -XTypeApplications GHCi, version 8.6.3: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> :t id @Maybe <interactive>:1:5: error: • Expecting one more argument to ‘Maybe’ Expected a type, but ‘Maybe’ has kind ‘* -> *’ • In the type ‘Maybe’ In the expression: id @Maybe }}} On GHC HEAD, however, this is seemingly accepted! {{{ $ ~/Software/ghc/inplace/bin/ghc-stage2 --interactive -XTypeApplications GHCi, version 8.9.20190224: https://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> :t id @Maybe λ> }}} No error message, just... a newline. Quite bizarre. Even more bizarrely, this phenomenon doesn't appear to happen with `:kind`: {{{ λ> :set -XDataKinds -XPolyKinds λ> type Id (a :: k) = a λ> :k Id @Maybe <interactive>:1:5: error: • Expecting one more argument to ‘Maybe’ Expected a type, but ‘Maybe’ has kind ‘* -> *’ • In the first argument of ‘Id’, namely ‘Maybe’ In the type ‘Id @Maybe’ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16376> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #16164: Provide bitreverse primop
by GHC 09 Mar '19

09 Mar '19

#16164: Provide bitreverse primop -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- We already have nice primops like {{{byteSwap#}}}, it'd be nice to also have {{{bitreverse}}}. Clang provides {{{__builtin_bitreverse}}} (http://clang.llvm.org/docs/LanguageExtensions.html#builtin-bitreverse) functions which could be the default. GCC currently doesn't have a built- in (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50481) One prominent place where this primop could be used is Data.IntSet.Internal where it's implemented as a {{{revNat}}}. Many other libraries also define own versions. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16164> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #16412: Type family signatures in indefinite modules
by GHC 09 Mar '19

09 Mar '19

#16412: Type family signatures in indefinite modules -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.6.4 Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Backpack does not allow type family signatures in indefinite modules. As an example, although GHC does accept: {{{ -- indefinite module data Foo :: Bool -- implementing module type Foo = 'True }}} It does not accept: {{{ -- indefinite module type family Foo (b :: Bool) :: Bool -- implementing module type family Foo (b :: Bool) :: Bool where Foo 'True = 'False Foo 'False = 'True }}} I'm not sure if there is a fundamental reason for this (e.g. a requirement that everything is matchable). It would be helpful for the thing I'm experimenting with if this restriction could be lifted. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16412> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #16410: Order of declarations matters
by GHC 08 Mar '19

08 Mar '19

#16410: Order of declarations matters -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 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: -------------------------------------+------------------------------------- This piece of code works. {{{#!hs {-# Language DataKinds #-} {-# Language GADTs #-} {-# Language InstanceSigs #-} {-# Language PolyKinds #-} {-# Language TypeFamilies #-} import Data.Kind class Category (tag::Type) where type Strip tag :: Type class Category tag => Stripped tag where type Hom tag::Strip tag -> Strip tag -> Type instance Category () where type Strip () = () instance Stripped () where type Hom () = Unit1 data Unit1 :: () -> () -> Type where U1 :: Unit1 '() '() data Tag data Unit2 :: () -> () -> Type where U2 :: Unit2 '() '() instance Category Tag where type Strip Tag = () instance Stripped Tag where type Hom Tag = Unit2 }}} Note that `Unit1` and `Unit2` are declared identically, separated by `data Tag`. The order is important. If we change the last line to `Hom Tag = Unit1` (same as `Hom ()`) we get {{{ $ ghc -ignore-dot-ghci 1152_bug.hs GHCi, version 8.7.20190115: https://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( 1152_bug.hs, interpreted ) 1152_bug.hs:28:18: error: • Expected kind ‘Strip Tag -> Strip Tag -> *’, but ‘Unit1’ has kind ‘() -> () -> *’ • In the type ‘Unit1’ In the type instance declaration for ‘Hom’ In the instance declaration for ‘Stripped Tag’ | 28 | type Hom Tag = Unit1 | ^^^^^ Failed, no modules loaded. Prelude> }}} even though `Strip Tag` is defined to equal `()`. Here comes the weird part. If I move `Unit1` decl beneath `data Tag` {{{#!hs data Tag data Unit1 :: () -> () -> Type where U1 :: Unit1 '() '() data Unit2 :: () -> () -> Type where U2 :: Unit2 '() '() }}} then `type Hom Tag = Unit1` and `type Hom Tag = Unit2` both work well. If I move `Unit2` decl above `data Tag` then both `Hom Tag = Unit1` and `Hom Tag = Unit2` fail! {{{#!hs data Unit1 :: () -> () -> Type where U1 :: Unit1 '() '() data Unit2 :: () -> () -> Type where U2 :: Unit2 '() '() data Tag }}} If I replace all occurrences of `Tag` with `Bool` it succeeds. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16410> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11441: RFC: Inline intermediate languages (Core, STG, Cmm, even StrictCore)
by GHC 08 Mar '19

08 Mar '19

#11441: RFC: Inline intermediate languages (Core, STG, Cmm, even StrictCore) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: -------------------------------------+------------------------------------- Allow intermediate code inline. == Inline ''Core'' == Typeable/WithTypeable: > {{{#!hs > withTypeable :: TTypeRep a -> (Typeable a => r) -> r > }}} > > Currently, `withTypeable` cannot be written in Haskell, but it is straightforward to write in Core. Can we fix this? [http://www.seas.upenn.edu/~sweirich/papers/wadlerfest2016.pdf A reflection on types] (''2016''): > We cannot implement ''withTypeable'' in Haskell source. But we ''can'' implement it in GHC's statically-typed intermediate language, System FC. The definition is simple, roughly like this: > > {{{#!hs > withTypeable tr k = k tr -- Not quite right > }}} > > Its second argument ''k'' expects a ''Typeable'' dictionary as its value argument. But since > a ''Typeable'' dictionary is represented by a ''TypeRep'', we can simply pass ''tr'' to ''k''. > When written in System FC there is a type-safe coercion to move from ''TypeRep a'' to ''Typeable a'', > but that coercion is erased at runtime. Since the definition can be statically type checked, > ''withTypeable'' does not form part of the trusted code base. == Inline ''Cmm'' == Edkward Kmett writes his own `.cmm` [https://github.com/ekmett/concurrent/blob/master/cbits/hashmap.cmm hither], [https://github.com/ekmett/concurrent/blob/master/cbits/array.cmm yon]. == Inline ''Strict Core'' == Should [http://research.microsoft.com/en-us/um/people/simonpj/papers /strict-core/tacc-hs09.pdf Types are calling conventions] (''2009'') be implemented: > === '''4.4 The ''`seq`'' function''' === > > A nice feature of Strict Core,,ANF,, is that it is possible to give a straightforward definition of the primitive ''seq'' function of Haskell: > {{{#!hs > seq : {a:* -> b:* -> {a} -> {b} -> b} > = { \a:*. \b:*. \x:{a}. \y:{b}. let _:a = x <> in y <> } > }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11441> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #11315: GHC doesn't restore split objects
by GHC 08 Mar '19

08 Mar '19

#11315: GHC doesn't restore split objects -------------------------------------+------------------------------------- Reporter: snowleopard | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: -------------------------------------+------------------------------------- While working on the new Shake-based build system I came across an annoying problem related to missing split objects ([#note see note]). I still don't fully understand the reasons behind the problem, but I found that GHC doesn't restore missing split objects, as explained in the example below. I think this is a bug, but maybe this is actually a missing feature. I think it shouldn't be difficult to fix. {{{#!hs module Test (test) where test :: Int test = 0 }}} I compile the above with `ghc -split-objs Test.hs` and get two split object files in `Test_o_split`. Then if I delete any of these files, or even the whole folder, and rerun `ghc -split-objs Test.hs` the compiler doesn't bother to restore split objects, pretending that everything is up- to-date. However, if I delete `Test.o` all object files are restored. Another related issue reported by Neil Mitchell (which may be worth a separate ticket) is that even if we corrupt `Test.o` and rerun `ghc -split-objs Test.hs`, the compiler doesn't restore the object file (nor missing split objects) to the consistent state. ---- [=#note Note:] The problem I have is described here: https://github.com/snowleopard/shaking-up-ghc/issues/30. It's not necessary to follow the link to understand this ticket, however I'd appreciate any insight you might have about the reasons behind the problem and/or a possible solution. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11315> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6