November 2015 - ghc-tickets

[GHC] #11105: Put the generic-default type in the Class
by GHC 25 Nov '15

25 Nov '15

#11105: Put the generic-default type in the Class -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | 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 Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is an internal GHC refactoring ticket. Consider {{{ {-# LANGUAGE DefaultSignatures #-} class C a where op :: a -> a -> Bool default op :: Ord a => a -> a -> Bool op x y = x < y }}} The `Class` object for `C` has a `ClassOpItem` that specifies * the name `op` * the type of the method `a -> a -> Bool` * that `op` has a generic-default signature BUT it does not contain the actual signature `Ord a => a -> a -> Bool`. That's really wrong; it is certainly part of the definition of the class, and we should print it out when we say `:info C` in ghci. Instead this type is kept solely in the top-level generic-default Id binding. But that means that default-method Ids and generic-default method Ids are treated differently; see `gen_dm_ids` in `tcTyClDecl1` in `TcTyClsDecls`, and `mkDefaultMethodIds` in `TcTyDecls`. We should treat them uniformly. I know how but have too much in flight to do it immediately. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11105> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11014: re-order GHC type errors for clarity
by GHC 25 Nov '15

25 Nov '15

#11014: re-order GHC type errors for clarity -------------------------------------+------------------------------------- Reporter: elaforge | Owner: elaforge 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: -------------------------------------+------------------------------------- Here's a typical simple type error from GHC: {{{#!hs Derive/Call/India/Pakhawaj.hs:142:62: Couldn't match type ‘Text’ with ‘(a1, Syllable)’ Expected type: [([(a1, Syllable)], [Sequence Bol])] Actual type: [([Syllable], [Sequence Bol])] Relevant bindings include syllables :: [(a1, Syllable)] (bound at Derive/Call/India/Pakhawaj.hs:141:16) best_match :: [(a1, Syllable)] -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence Bol)])) (bound at Derive/Call/India/Pakhawaj.hs:141:5) In the second argument of ‘mapMaybe’, namely ‘all_bols’ In the second argument of ‘($)’, namely ‘mapMaybe (match_bols syllables) all_bols’ }}} The order of sections is "couldn't match", "expected actual", "relevant bindings", "context" (in the second argument etc.). I think it would be easier to read as "couldn't match", "expected actual", "context", "bindings", and with a * to mark each section: {{{#!hs Derive/Call/India/Pakhawaj.hs:142:62: * Couldn't match type ‘Text’ with ‘(a1, Syllable)’ Expected type: [([(a1, Syllable)], [Sequence Bol])] Actual type: [([Syllable], [Sequence Bol])] * In the second argument of ‘mapMaybe’, namely ‘all_bols’ In the second argument of ‘($)’, namely ‘mapMaybe (match_bols syllables) all_bols’ * Relevant bindings include syllables :: [(a1, Syllable)] (bound at Derive/Call/India/Pakhawaj.hs:141:16) best_match :: [(a1, Syllable)] -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence Bol)])) (bound at Derive/Call/India/Pakhawaj.hs:141:5) }}} I'm sure there are plenty of other sections that don't show up in this simple example, in any case they should go from most to least critical and be marked off with a *. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11014> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #11069: :cd in GHCi unloads modules
by GHC 25 Nov '15

25 Nov '15

#11069: :cd in GHCi unloads modules -------------------------------------+------------------------------------- Reporter: mgsloan | Owner: Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If I run `stack ghci` in the [https://github.com/commercialhaskell/stack stack] repo, and then use `:cd`, I get the following: > Warning: changing directory causes all loaded modules to be unloaded, > because the search path has changed. And, indeed, all modules are unloaded. What's particularly strange about this is that in my case all of the paths provided on the commandline are absolute. Here's the output of ":show paths": > current working directory: > > /home/mgsloan/fpco/stack > > module import search paths: > > /home/mgsloan/fpco/stack/src > > /home/mgsloan/fpco/stack/.stack- work/dist/x86_64-linux/Cabal-1.22.4.0/build/autogen > > /home/mgsloan/fpco/stack/.stack- work/dist/x86_64-linux/Cabal-1.22.4.0/build > > /home/mgsloan/fpco/stack/src/main How about removing any dependency in GHC on the current working directory, and instead store it when the session is initialized? This is also necessary if we want to support per-package working directories, [https://ghc.haskell.org/trac/ghc/timeline?from=2015-11-08T06%3A17%3A58Z&pre… details here]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11069> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10483: Refactor HsForAllTy
by GHC 24 Nov '15

24 Nov '15

#10483: Refactor HsForAllTy -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | 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: | -------------------------------------+------------------------------------- I got sucked into refactoring `HsForAllTy`, like this: {{{ data HsType name = HsForAllTy (HsForAll name) (LHsType name) | ... data HsForAll name -- The quantifiers of a HsForAllTy = HSF { hsf_flag :: HsExplicitFlag , hsf_extra :: Maybe SrcSpan , hsf_qtvs :: LHsTyVarBndrs name , hsf_ctxt :: LHsContext name } }}} This makes a number of functions neater, as well as naming the fields of a troublesomely-high-arity data constructor. This ticket is here to track progress. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10483> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11000: Implement `-Wcompat`
by GHC 24 Nov '15

24 Nov '15

#11000: Implement `-Wcompat` -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature | Status: new request | Priority: high | Milestone: 8.0.1 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 Rev(s): | Wiki Page: Design/Warnings -------------------------------------+------------------------------------- Currently we have only the following generic warning "levels": {{{ -W enable normal warnings -w disable all warnings -Wall enable almost all warnings (details in ) }}} It would be useful to be able to refer collectively to all currently implemented forward-compatibility warnings (e.g. about upcoming changes in `base`, like `-fwarn-amp`) via a symbolic `-Wcompat` flag. This way, users have more flexibility in opt-in or out of such warnings. So e.g. the following settings are possible in `.cabal` files: `ghc-options: -Wall` :: enable "almost all warnings" as before. Some compat warnings maybe part of `-Wall`, some won't (yet). `ghc-options: -Wall -Wcompat` :: enable "almost all warnings" as well as all implemented warnings. E.g. if GHC 8.0 implements `-fwarn-mfp-compat` but doesn't include it in `-Wall`, this allows users to get notified asap about warnings to opt into that `ghc-options: -Wall -Wno-compat` :: This enables `-Wall` **minus** any future-compat warnings. This is for users who want to be warned at all about any future compat warnings. `ghc-options: -Wcompat` :: Of course, `-W(no-)compat` can be used also w/o `-Wall`, and then is equivalent to turning on/off the respective individual `-fwarn-*-compat` flags. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11000> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11112: Error message for accidentally using -> instead of =>
by GHC 24 Nov '15

24 Nov '15

#11112: Error message for accidentally using -> instead of => -------------------------------------+------------------------------------- Reporter: JulesBean | Owner: Type: bug | 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 Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following typo: {{{#!hs sort :: Ord s -> [s] -> [s] sort xs = Data.List.sort xs }}} GHC's error message in 7.10 is {{{ Expected a type, but ‘Ord s’ has kind ‘GHC.Prim.Constraint’ In the type signature for ‘Main.sort’: Main.sort :: Ord s -> [s] -> [s] }}} I would suggest that mentioning kinds and GHC.Prim.Constraint is a bit unfriendly in a vanilla session (with ConstraintKinds etc switched off). For comparison, the 6.12 error message was {{{ Class `Ord' used as a type In the type signature for `sort': sort :: Ord a -> [a] -> [a] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11112> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #6089: Allow declaration splices inside declaration brackets
by GHC 23 Nov '15

23 Nov '15

#6089: Allow declaration splices inside declaration brackets -------------------------------------+------------------------------------- Reporter: igloo | Owner: simonpj Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11129 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jstolarek): * related: => #11129 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6089#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11129: Nested TH not allowed in declarations
by GHC 23 Nov '15

23 Nov '15

#11129: Nested TH not allowed in declarations -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: Type: bug | 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 Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I tried to do the following with the `singletons` and `derive` libraries: {{{#!hs $(singletons [d| data CrudRoute = AddR | EditR | DeleteR | ViewR deriving (Eq,Ord,Enum,Bounded,Show) data MyRoute = UsersR | ProfileR | RenameR | DogR CrudRoute deriving (Eq,Ord,Show) $( derive makeEnum ''MyRoute ) |]) }}} GHC fails with the following error message: Splices within declaration brackets not (yet) handled by Template Haskell Here is the github issue where this originated: https://github.com/goldfirere/singletons/issues/135#issuecomment-158936027 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11129> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #10656: Ability to get stack traces from Haskell code
by GHC 23 Nov '15

23 Nov '15

#10656: Ability to get stack traces from Haskell code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Tarrasch Type: feature | Status: new request | Milestone: 7.12.1 Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: #3693 Test Case: | Blocking: | Differential Revisions: Phab:D963 | -------------------------------------+------------------------------------- With the merge of Phab:D169 and Phab:D396 (included in GHC 7.10.1) GHC now has the ability to produce DWARF debugging information in compiled binaries. It would be nice if Haskell programs could request stack backtraces from the RTS. Tarrasch has some work in this direction in Phab:D963 however there are a number of questions that remain outstanding, * do we want to rely on an external library for parsing DWARF information? If so, how do we address portability concerns? * What should the Haskell-land interfaces look like? Writing down some concrete use-cases would help here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10656> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11125: Typechecker can't infer StM m Bool ~ Bool from StM m a ~ a
by GHC 23 Nov '15

23 Nov '15

#11125: Typechecker can't infer StM m Bool ~ Bool from StM m a ~ a -------------------------------------+------------------------------------- Reporter: nikomi | Owner: Type: bug | 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 Rev(s): | Wiki Page: -------------------------------------+------------------------------------- We found a problem where TC correctly infers StM m a ~ a but fails to infer StM m Bool ~ Bool in what appears to be the same situation. Here is a small sample showing the problem: {{{#!hs {-# LANGUAGE FlexibleContexts, FlexibleInstances #-} module Problem where import qualified Control.Monad.STM as STM import Control.Monad.STM (STM) import Control.Monad.Trans.Control (MonadBaseControl, liftBaseWith) class MonadSTM m where liftSTM :: STM a -> m a instance MonadSTM STM where liftSTM = id always :: (Monad m, MonadSTM m, MonadBaseControl STM m) => m Bool -> m () always inv = liftBaseWith $ \runInSTM -> STM.always (runInSTM inv) alwaysSucceeds :: (Monad m, MonadSTM m, MonadBaseControl STM m) => m a -> m () alwaysSucceeds inv = liftBaseWith $ \runInSTM -> STM.alwaysSucceeds (runInSTM inv) }}} The compiler error is {{{ Problem.hs:15:54: Couldn't match type ‘Control.Monad.Trans.Control.StM m Bool’ with ‘Bool’ Expected type: STM Bool Actual type: STM (Control.Monad.Trans.Control.StM m Bool) Relevant bindings include runInSTM :: Control.Monad.Trans.Control.RunInBase m STM (bound at Problem.hs:15:30) inv :: m Bool (bound at Problem.hs:15:8) always :: m Bool -> m () (bound at Problem.hs:15:1) In the first argument of ‘STM.always’, namely ‘(runInSTM inv)’ In the expression: STM.always (runInSTM inv) }}} Function {{{always}}} can be made to compile by adding {{{StM m Bool ~ Bool}}}: {{{#!hs always :: (Monad m, MonadSTM m, MonadBaseControl STM m, StM m Bool ~ Bool) => m Bool -> m () }}} but then the problem is just shifted to the caller: {{{ Couldn't match type ‘(Either [Char] Bool, Int)’ with ‘Bool’ Expected type: Bool Actual type: StM (RSET TestData Int String STM) Bool In the second argument of ‘($)’, namely ‘always sanityCheck’ In a stmt of a 'do' block: atomically $ always sanityCheck In the expression: do { atomically $ always sanityCheck; atomically $ updateTX 1 2; atomically stashSum } }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11125> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7