March 2016 - ghc-tickets

[GHC] #11475: Lint should check for inexhaustive alternatives
by GHC 10 Mar '16

10 Mar '16

#11475: Lint should check for inexhaustive alternatives -------------------------------------+------------------------------------- Reporter: simonpj | 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: -------------------------------------+------------------------------------- GHC's simplifier prunes inaccessible alternatives from case expressions. E.g. {{{ case x of A y -> e1 _ -> ....(case x of A y -> r1 B -> r2 C -> r3) ... }}} It'll prune the `A` alternative from the inner case to get {{{ case x of A y -> e1 _ -> ....(case x of B -> r2 C -> r3) ... }}} BUT, there is no independent check from Lint that this pruning does the Right Thing. Trac #11172 turned out to be a bug in the pruning, which led to something like {{{ case x of Left y -> e1 }}} but in fact `x` ended up being bound to `(Right v)` for some value `v`. But because there is only a single alternative left, GHC does not test the tag, but instead goes ahead and accesses it the `Right` value as if it was a `Left` value. And because of pointer-tagging, it'll assume the wrong tag on the pointer, and very soon you are in seg-fault land. So this ticket is to suggest: make Core Lint do it's best to check that all cases are in fact exhaustive. There are two ways in which we prune cases: * Enclosing pattern matches (as above) * GADT pattern matches may be exhaustive even when they don't mention all constructors. For the latter, it's impossible for Lint to reproduce all the reasoning of the type checker, but I bet that in 99.5% of the cases the existing function `dataConCantMatch` will do the job. So if Lit * Maintains an environment saying what each variable can't match (as the simplifier does) * Does a simple-minded `dataConCantMatch` test based on the typ of the scrutinee I think we'd be a long way forward. It's possible that a valid program could trigger a Lint report, but let's see. Any volunteers? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11475> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #5850: Greater customization of GHCi prompt
by GHC 09 Mar '16

09 Mar '16

#5850: Greater customization of GHCi prompt -------------------------------------+------------------------------------- Reporter: JamesFisher | Owner: niksaz Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.4.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9994 | Differential Rev(s): Phab:D623 Wiki Page: | -------------------------------------+------------------------------------- Changes (by niksaz): * owner: => niksaz Comment: Working on this feature. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5850#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2530: deriving Show adds extra parens for constructor with record syntax
by GHC 09 Mar '16

09 Mar '16

#2530: deriving Show adds extra parens for constructor with record syntax -------------------------------------+------------------------------------- Reporter: spl | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 6.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D669 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I don't have particularly strong feelings on this matter, and I'd be okay with reverting this for now, since multiple GHC devs have expressed their displeasure in this change. This change does minimize the number of parentheses outputted in a way that agrees with the Haskell Report, but as Edward Kmett notes in a [https://mail.haskell.org/pipermail/haskell-cafe/2009-November/069497.html Haskell Café thread], we're already not using a minimal amount of parentheses as it is due to `Show` not taking fixity into account when parenthesizing (e.g., you can omit parentheses when chaining several `infixl` constructors). I wouldn't feel terrible about adding extra parentheses in this particular case. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2530#comment:37> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #11518: Test TcCoercibleFail hangs with substitution sanity checks enabled
by GHC 09 Mar '16

09 Mar '16

#11518: Test TcCoercibleFail hangs with substitution sanity checks enabled -------------------------------------+------------------------------------- Reporter: niteria | Owner: niteria Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: 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 goldfire): I just tripped over this, with `TcCoercibleFail` timing out when testing against a `DEBUG` build. Can we somehow tell the testsuite to skip this one in this scenario until we have a better workaround? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11518#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11689: typo (extra s) in error message (out-of-scope typess)
by GHC 08 Mar '16

08 Mar '16

#11689: typo (extra s) in error message (out-of-scope typess) -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 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: -------------------------------------+------------------------------------- {{{ MB.hs:92:49: error: • Ambiguous type variable ... These potential instances exist: ... ...plus 325 instance involving out-of-scope typess }}} There is an extra 's' in 'typess'. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11689> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11661: Missing MonadFail instance for Q monad from TemplateHaskell
by GHC 08 Mar '16

08 Mar '16

#11661: Missing MonadFail instance for Q monad from TemplateHaskell -------------------------------------+------------------------------------- Reporter: PeterTrsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.0.1-rc2 Haskell | 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: -------------------------------------+------------------------------------- Since GHC 8.0.1 introduces MonadFailDesugaring one would expect Q monad to have an instance for MonadFail. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11661> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

Re: [GHC] #6032: HEAD (7.5.20120421) requires RankNTypes for a rank-2 type
by GHC 08 Mar '16

08 Mar '16

#6032: HEAD (7.5.20120421) requires RankNTypes for a rank-2 type -------------------------------------+--------------------------------- Reporter: dreixel | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.5 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+--------------------------------- Comment (by Herbert Valerio Riedel <hvr@…>): In [changeset:"1a9734a69260e69943c00755952edd7185dcc484/ghc" 1a9734a6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1a9734a69260e69943c00755952edd7185dcc484" template-haskell: Drop use of Rank2Types/PolymorphicComponents As per #6032, `Rank2Types` and `PolymorphicComponents` have been deprecated in favour of `RankNTypes`. also update `other-extensions` in template-haskell.cabal flag to reflect reality. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6032#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2530: deriving Show adds extra parens for constructor with record syntax
by GHC 08 Mar '16

08 Mar '16

#2530: deriving Show adds extra parens for constructor with record syntax -------------------------------------+------------------------------------- Reporter: spl | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 6.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D669 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I would be fine with retaining the old behavior, keeping the parens, for now. It's pretty widely believed that the binding of record syntax specified in the report was a mistake. Let's allow the Haskell Prime committee to discuss this matter before we commit to changing `Show`. While it's almost certainly not practical to change the binding of record syntax, the next report could specify a more lax semantics for `Show`. To be clear, I'm merely requesting that the committee add this matter to their list of matters to address; their final decision is of course in their hands. If there is a good chance that the committee will consider such a change, then let's revert the commit in comment:25 for now and reconsider after the committee has made their decision. If it's unlikely that the next report will loosen `Show`, then we should decide now whether we want retain and document the old behavior as an infelicity of GHC's implementation, or whether we want to come into compliance with the Report. I'm slightly leaning towards the former for the sake of stability, although I'm happy to hear arguments in the other direction. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2530#comment:36> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11686: implicit call stacks should provide a way to get the calling function's name
by GHC 08 Mar '16

08 Mar '16

#11686: implicit call stacks should provide a way to get the calling function's name -------------------------------------+------------------------------------- Reporter: elaforge | Owner: Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- With implicit call stacks we can get the calling SrcPos and the called function's name, but not the caller function's name. E.g.: {{{#!hs {-# LANGUAGE ImplicitParams, ConstraintKinds #-} import qualified GHC.Stack as Stack caller :: IO () caller = callee 10 where callee :: (?stack :: Stack.CallStack) => Int -> IO () callee _n = mapM_ print (Stack.getCallStack ?stack) }}} Gives {{{ ("?stack",SrcLoc {srcLocPackage = "main", srcLocModule = "Main", srcLocFile = "T.hs", srcLocStartLine = 9, srcLocStartCol = 36, srcLocEndLine = 9, srcLocEndCol = 42}) ("callee",SrcLoc {srcLocPackage = "main", srcLocModule = "Main", srcLocFile = "T.hs", srcLocStartLine = 6, srcLocStartCol = 23, srcLocEndLine = 6, srcLocEndCol = 29}) }}} It would be nice to get the name "caller" as well. It's too bad getCallStack returns pairs instead of an abstract type like Frame. Perhaps a separate Stack.getFrames could do that while getCallStack continues to return pairs for compatibility. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11686> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11643: Core lint error in simplifier when compiling Rules1 with -O -prof -dcore-lint
by GHC 07 Mar '16

07 Mar '16

#11643: Core lint error in simplifier when compiling Rules1 with -O -prof -dcore- lint -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 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: -------------------------------------+------------------------------------- Running `make TEST=Rules1 WAY=profasm` results in a core lint error (see attachment) with ghc-8.0.1-rc2. This is the code: {{{#!hs {-# LANGUAGE TypeFamilies #-} module Rules1 where class C a where data T a instance (C a, C b) => C (a,b) where data T (a,b) = TPair (T a) (T b) mapT :: (C a, C b) => (a -> b) -> T a -> T b {-# NOINLINE mapT #-} -- Otherwwise we get a warning from the rule mapT = undefined zipT :: (C a, C b) => T a -> T b -> T (a,b) {-# NOINLINE [1] zipT #-} zipT = undefined {-# RULES "zipT/mapT" forall f x y. zipT (mapT f x) y = mapT (\(x,y) -> (f x, y)) (zipT x y) #-} }}} {{{ $ ghc-8.0.1 -O -prof Rules1.hs -dcore-lint }}} This is a regression from 7.10.3, and core lint errors are bad, so setting priority to highest. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11643> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8