January 2016 - ghc-tickets

[GHC] #11268: Extend ghc environment file features
by GHC 09 Jan '16

09 Jan '16

#11268: Extend ghc environment file features -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature | Status: new request | Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D1668 | Wiki Page: -------------------------------------+------------------------------------- This is essential to make it into GHC 8.0.1 as it provides the infrastructure for cabal's new features See Phab:D1668 for more detail -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11268> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11304: GHC master segfaults when run with +RTS -h
by GHC 09 Jan '16

09 Jan '16

#11304: GHC master segfaults when run with +RTS -h -------------------------------------+------------------------------------- Reporter: bgamari | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.11.20151218 $ ghc +RTS -h ghc: no input files Usage: For basic information, try the `--help' option. Segmentation fault }}} This appears to be due to ce1f1607ed7f8fedd2f63c8610cafefd59baaf32, {{{ commit ce1f1607ed7f8fedd2f63c8610cafefd59baaf32 Author: Simon Marlow <marlowsd(a)gmail.com> Date: Sat Nov 7 09:39:05 2015 +0000 Make GHCi & TH work when the compiler is built with -prof }}} Which removes an `initProfiling2` call from `hs_init_ghc`, which means that `initHeapProfiling` is never called, which means that `censuses` is never initialized, which causes a crash during cleanup on RTS shutdown. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11304> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11341: Reifying a GADT doesn't tell you the correct return type
by GHC 09 Jan '16

09 Jan '16

#11341: Reifying a GADT doesn't tell you the correct return type -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.1 Haskell | 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: -------------------------------------+------------------------------------- Running this example: {{{#!hs {-# LANGUAGE GADTs, TemplateHaskell #-} module Main (main) where import Language.Haskell.TH type S = T data T a where MkT :: S Int $(return []) main :: IO () main = putStrLn $(reify ''T >>= stringE . pprint) }}} gives the following result: {{{ data Main.T (a_0 :: *) where Main.MkT :: Main.T GHC.Types.Int }}} Shouldn't the return type be `Main.S GHC.Types.Int` instead? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11341> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #11358: GHC generics has differing conFixity behavior between 7.10.3 and 8.1
by GHC 09 Jan '16

09 Jan '16

#11358: GHC generics has differing conFixity behavior between 7.10.3 and 8.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.1 (CodeGen) | Keywords: Generics | 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: -------------------------------------+------------------------------------- Compile the following program with GHC 7.10.3 and 8.1: {{{#!hs {-# LANGUAGE DefaultSignatures #-} {-# LANGUAGE DeriveGeneric #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FlexibleInstances #-} module Main (main) where import GHC.Generics infixr 1 `T` data T a = T a a deriving Generic instance HasFixity (T a) data I a = a `I` a deriving Generic instance HasFixity (I a) class HasFixity a where fixity :: a -> Fixity default fixity :: (Generic a, GHasFixity (Rep a)) => a -> Fixity fixity = gfixity . from class GHasFixity f where gfixity :: f a -> Fixity instance GHasFixity f => GHasFixity (D1 d f) where gfixity (M1 x) = gfixity x instance Constructor c => GHasFixity (C1 c f) where gfixity c = conFixity c main :: IO () main = do putStrLn $ show (fixity (T "a" "b")) ++ ", " ++ show (fixity ("a" `I` "b")) }}} On GHC 7.10.3, it yields `Prefix, Infix LeftAssociative 9`, but on GHC 8.1, it yields `Infix RightAssociative 1, Prefix`. Why? The implementation of `deriving Generic(1)` changed slightly in GHC 8.1. Before, it would only assign a fixity of `Infix` if a constructor was ''declared'' infix. But GHC 8.1 no longer checks for this—it first checks if there is a user- supplied fixity declaration, and if so, uses that as the `Fixity`. Otherwise, it defaults to `Prefix`, even if the datatype was declared infix! The design of `Fixity` perhaps leaves something to be desired, but at the very least, we should ensure nothing `Fixity`-related breaks for now. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11358> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10337: One-shot module loops have hard to understand messages
by GHC 09 Jan '16

09 Jan '16

#10337: One-shot module loops have hard to understand messages -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (Type checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Consider these two modules: {{{ -- A.hs module A where -- B.hs module B where import A }}} `ghc --make B.hs` will compile this fine. Now edit `A.hs` to be circular: {{{ -- A.hs module A where import B }}} and attempt to one-shot compile it with `ghc -c A.hs`. You will now get an uninformative error message: {{{ A.hs:1:1: Circular imports: module `A' depends on itself }}} You can get a more informative message with `--make`: {{{ Module imports form a cycle: module `A' (A.hs) imports `B' (./B.hs) which imports `A' (A.hs) }}} We should either suggest users try again with `--make`, or try harder to give a useful message in one-shot mode. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10337> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #2940: Do CSE after CorePrep
by GHC 09 Jan '16

09 Jan '16

#2940: Do CSE after CorePrep -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: lowest | Milestone: 8.0.1 Component: Compiler | Version: 6.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Simon, may I ask why you're inclined to think that it'd be better to do CSE earlier not later? Is it because of type safety reasons? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2940#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2168: ghci should show haddock comments for identifier
by GHC 09 Jan '16

09 Jan '16

#2168: ghci should show haddock comments for identifier -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * cc: alanz (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2168#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10362: Make tuple constraints into a class
by GHC 09 Jan '16

09 Jan '16

#10362: Make tuple constraints into a class -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- At the moment GHC treats tuple constraints specially. If you grep for `TuplePred` you'll see this. But the special treatment is strange; see the confusion between constraint tuples and ordinary tuples in #9858. But I now realise that we can sweep away all this nonsense. Suppose we declare {{{ module GHC.Classes where class (c1, c2) => (,) c1 c2 instance (c1, c2) => (,) c1 c2 class (c1, c2, c3) => (,) c1 c2 c3 instance (c1, c2, c3) => (,) c1 c2 c3 }}} and so on. (This is analogous the tuple data type declarations in `GHC.Tuple`.) Notice that: * `GHC.Classes,(,)` is a class, of kind `Constraint -> Constraint -> Constraint`. quite distinct from `GHC.Tuple.(,)`, whose kind is `* -> * -> *`. * `GHC.Classes.(,)` is a perfectly ordinary class, with no methods and two superclasses. * So all the usual superclass stuff applies. * If you have a given `Ord a` then you have a given `Eq a` (its superclass). Similarly if you have a given `(,) c1 c2` then you also have given `c1` and `given `c2`. * If you want to construct a dictionary of type `Ord a` (a "wanted"), you must supply a dictionary of type `Eq a`. Similarly, if you want to construct a dictionary of type `(,) c1 c2` then you must supply `c1` and `c2`. * I have written `(,) c1 c2` to stress that there is a class `GHC.Classes.(,)`, but we'll also allow the concrete syntax `(c1,c2)` instead. * Nevertheless the syntactic form `(c1, c2) => blah` is just sugar for `c1 => c2 => blah` (a type with two, curried constraints); it does not stand a type with a single constraint. Otherwise the instance {{{ instance (c1,c2) => (c1,c2) }}} would be the identity function! The key thing is that, aside from special syntax, `(,)` is a perfectly ordinary class, so we can simply delete all the special treatment of `TuplePred`. (Implicit parameters are also treated as a special class, incidentally.) There should be no user-visible effects. But I think it would cure the worst aspects of #10359, as well as cleaning up `TypeRep` confusion. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10362> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11281: Way to run --make and -M simultaneously
by GHC 08 Jan '16

08 Jan '16

#11281: Way to run --make and -M simultaneously -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.11 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 some cases, users would like to build their projects `--make` and also print out dependency information `-M` (so that they can sanity check file lists, etc.) It shouldn't be too difficult to arrange for `--make` and `-M file` to mean, put the Makefile information in `file`. Cabal's request: https://github.com/haskell/cabal/issues/2982 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11281> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #7414: plugins always trigger recompilation
by GHC 08 Jan '16

08 Jan '16

#7414: plugins always trigger recompilation -------------------------------------+------------------------------------- Reporter: jwlato | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: plugin, | recompilation 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: | -------------------------------------+------------------------------------- Comment (by ezyang): Related #7277, which has the opposite problem where rely only on the interface hash (and not an "implementation" hash.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7414#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0