- ghc-tickets - Haskell.org

[GHC] #14362: Allow: Coercing (a:~:b) to (b:~:a)
by GHC 19 Oct '17

19 Oct '17

#14362: Allow: Coercing (a:~:b) to (b:~:a) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: roles | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Is there *any* sensible way to enable coercing [https://hackage.haskell.org/package/base-4.10.0.0/docs/Data-Type- Equality.html#t::-126-: (:~:)] swapping its arguments {{{#!hs coerce :: a:~:b -> b:~:a }}} Same for [https://hackage.haskell.org/package/base-4.10.0.0/docs/Data- Type-Coercion.html#t:Coercion Coercion] {{{#!hs coerce :: Coercion a b -> Coercion b a }}} Thanks! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14362> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #14371: ghc: panic! when reloading file with code
by GHC 19 Oct '17

19 Oct '17

#14371: ghc: panic! when reloading file with code -------------------------------------+------------------------------------- Reporter: xvrbka1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Hello, I have no idea what causes it (maybe my mistake) so I probably will give you more code then necessaty. Sorry for that. \\ **I had working code:** {{{ f :: [[Bool]] -> ([Bool], [[Bool]]) f [] = ([True], g []) f (x:xs) = (g x, g xs) g :: [a] -> [a] g [] = [] g x = x listITE :: [Bool] -> [a] -> [a] -> [a] listITE [] _ _ = [] listITE _ _ [] = [] listITE _ [] _ = [] listITE (b:bs) (x:xs) (y:ys) = [(if b then x else y)] ++ listITE bs xs ys --zipWith (\x,y -> if ) ; firstMatch :: (a -> a -> Bool) -> [a] -> a -> a firstMatch _ [] y = y firstMatch p (x:s) y = if index >= (length (x:s)) then y else (x:s) !! index where index = indexOf True (zipWith p (x:s) s) indexOf :: (Eq a) => a -> [a] -> Int indexOf _ [] = 10 indexOf c (x:s) = if c==x then 0 else 1 + indexOf c s }}} that I could load, run and reload. \\ ** After I wrote this and tried to reload:** {{{ countInversions :: (Ord a) => [a] -> Int countInversions [] = 0 countInversions (x:s) = (countSame (True==) (map (x>) s)) + countInversions s countSame :: (Ord a) => (a -> Bool) [a] -> Int countSame _ [] = 0; countSame p (x:s) = (if p x then 1 else 0) + indexOf c s }}} \\ **I get error:** ''ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-unknown-linux): repSplitAppTys a_a6Xb[sk:1] Bool [] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:808:9 in ghc:Type'' \\ I hope I found u a bug :) \\ Have a nice day -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14371> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #11343: Unable to infer type when using DuplicateRecordFields
by GHC 18 Oct '17

18 Oct '17

#11343: Unable to infer type when using DuplicateRecordFields -------------------------------------+------------------------------------- Reporter: mpickering | 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: -------------------------------------+------------------------------------- It seems to me that GHC should be able to easily infer the types for the record updates in this simple example. Is there a reason that it is unable to infer the type currently? {{{ {-# LANGUAGE OverloadedLabels, DuplicateRecordFields #-} module C where main = do print aThing print bThing print (aThing { a = 5 } ) print (bThing { a = 5 } ) data B = B { a :: Int} deriving Show bThing = B 10 data A = A { a :: Int } deriving Show aThing = A 10 {- [1 of 1] Compiling C ( C.hs, C.o ) C.hs:7:10: error: • Record update is ambiguous, and requires a type signature • In the first argument of ‘print’, namely ‘(aThing {a = 5})’ In a stmt of a 'do' block: print (aThing {a = 5}) In the expression: do { print aThing; print bThing; print (aThing {a = 5}); print (bThing {a = 5}) } -} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11343> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #14323: Occurs check regressions in GHC 8.2.1 (and HEAD)
by GHC 18 Oct '17

18 Oct '17

#14323: Occurs check regressions in GHC 8.2.1 (and HEAD) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Type checker) | 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: -------------------------------------+------------------------------------- Inspired by adamse's comment at https://ghc.haskell.org/trac/ghc/ticket/14317#comment:3, I've discovered some programs which behave differently on GHC 8.0.2, 8.2.1, and HEAD. ----- First, there's this program: {{{#!hs {-# LANGUAGE GADTs #-} hm1 :: b ~ f b => b -> f b hm1 x = x }}} On GHC 8.0.2, this compiles (with a warning): {{{ GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:4:1: warning: [-Woverlapping-patterns] Pattern match is redundant In an equation for ‘hm1’: hm1 x = ... }}} But on GHC 8.2.1, it errors: {{{ GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:4:9: error: • Could not deduce: b ~ f b from the context: b ~ f b bound by the type signature for: hm1 :: forall b (f :: * -> *). b ~ f b => b -> f b at Bug.hs:3:1-26 ‘b’ is a rigid type variable bound by the type signature for: hm1 :: forall b (f :: * -> *). b ~ f b => b -> f b at Bug.hs:3:1-26 • In the expression: x In an equation for ‘hm1’: hm1 x = x • Relevant bindings include x :: b (bound at Bug.hs:4:5) hm1 :: b -> f b (bound at Bug.hs:4:1) | 4 | hm1 x = x | ^ }}} And on GHC HEAD, it fails with a different error! {{{ GHCi, version 8.3.20171004: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:4:9: error: • Occurs check: cannot construct the infinite type: b ~ f b • In the expression: x In an equation for ‘hm1’: hm1 x = x • Relevant bindings include x :: b (bound at Bug.hs:4:5) hm1 :: b -> f b (bound at Bug.hs:4:1) | 4 | hm1 x = x | ^ }}} The same errors occur if you give `hm1` the type `hm1 :: b ~ f b => f b -> b`. ----- What happens if you try `Coercible` instead of `(~)`? Consider this variant of the program above: {{{#!hs {-# LANGUAGE GADTs #-} import Data.Coerce hm2 :: Coercible b (f b) => b -> f b hm2 = coerce }}} On GHC 8.0.2, 8.2.1, and HEAD, this compiles (without warnings). Good. But if you change the type to use the symmetric version of that constraint: {{{#!hs {-# LANGUAGE GADTs #-} import Data.Coerce hm3 :: Coercible (f b) b => b -> f b hm3 = coerce }}} Then on GHC 8.0.2, it compiles without warnings, but on 8.2.1 and HEAD it fails! Here is the error with 8.2.1: {{{ Bug3.hs:6:7: error: • Could not deduce: Coercible b (f b) arising from a use of ‘coerce’ from the context: Coercible (f b) b bound by the type signature for: hm3 :: forall (f :: * -> *) b. Coercible (f b) b => b -> f b at Bug3.hs:5:1-36 ‘b’ is a rigid type variable bound by the type signature for: hm3 :: forall (f :: * -> *) b. Coercible (f b) b => b -> f b at Bug3.hs:5:1-36 • In the expression: coerce In an equation for ‘hm3’: hm3 = coerce • Relevant bindings include hm3 :: b -> f b (bound at Bug3.hs:6:1) | 6 | hm3 = coerce | ^^^^^^ }}} And on HEAD: {{{ Bug3.hs:6:7: error: • Occurs check: cannot construct the infinite type: b ~ f b arising from a use of ‘coerce’ • In the expression: coerce In an equation for ‘hm3’: hm3 = coerce • Relevant bindings include hm3 :: b -> f b (bound at Bug3.hs:6:1) | 6 | hm3 = coerce | ^^^^^^ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14323> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #13175: Documenting what can be derived 'out of the box' by GHC's "deriving"
by GHC 18 Oct '17

18 Oct '17

#13175: Documenting what can be derived 'out of the box' by GHC's "deriving" -------------------------------------+------------------------------------- Reporter: carette | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Nowhere in the documentation is it clearly stated which classes can be derived (assuming extensions as necessary) by GHC's "deriving" mechanism. As determined by reading the sources, this appears to be - Bounded, Enum, Eq, Ix, Ord, Read, Show, Functor, Foldable, Traversable, Generic, Generic1, Data, Lift. This was discussed on haskell-cafe -- see https://mail.haskell.org/pipermail/haskell-cafe/2016-October/125379.html. PS: I would be willing to fix this myself, if only I knew *where* to insert that information so that it is easily ''findable''! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13175> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #14357: Document deriving strategies fully
by GHC 18 Oct '17

18 Oct '17

#14357: Document deriving strategies fully -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.2.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: -------------------------------------+------------------------------------- The users’ guide currently sais in the section on `DerivingStrategies`: > If an explicit deriving strategy is not given, GHC has an algorithm for determining how it will actually derive an instance. For brevity, the algorithm is omitted here. You can read the full algorithm at Wiki page. I think this is doing our users a disservice: They want to rely on the guide to have authorative, concise and clear information. The wiki page contains too much stuff that is confusing for users (Alternative syntax, rationales etc.) (Also, the link in the manual is wrong). Ryan, do you agree and are you available to put the relevant bits into the manual? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14357> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #9112: data families with representational matching
by GHC 18 Oct '17

18 Oct '17

#9112: data families with representational matching ------------------------------------+------------------------------------- Reporter: jwlato | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Since ghc-7.8, the following is no longer possible: {{{ -- simplified example taken from the vector package class MVectorClass (v :: * -> * -> *) a where basicLength :: v s a -> Int data family MVector s a data instance MVector s Int -- implementation not important newtype Age = Age Int deriving (MVectorClass MVector) -- rejected }}} Following from discussion in #8177, to enable this ghc would need to support data families with representational matching, such that `MVector s Int` and `MVector s Age` are representationally equal. This has broken some code that previously worked, however as there are some workarounds I'm not sure how important it is. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9112> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #14360: traceM documentation not clear (and possibly incorrect)
by GHC 17 Oct '17

17 Oct '17

#14360: traceM documentation not clear (and possibly incorrect) -------------------------------------+------------------------------------- Reporter: saurabhnanda | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 8.0.2 Libraries | Keywords: docs | 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 code-example and the accompanying text at https://www.stackage.org/haddock/lts-9.0/base-4.9.1.0/Debug- Trace.html#v:traceM are out of sync. Also, it's not very clear what the following line means: > Note that the application of traceM is not an action in the Applicative context, as traceIO is in the IO type. I realised something was wrong when, during a refactor, I ended up with the equivalent of the following loop, which caused a thread to completely freeze and become unresponsive: > forever $ traceShowM "something" -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14360> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #13203: Implement Bits Natural clearBit
by GHC 17 Oct '17

17 Oct '17

#13203: Implement Bits Natural clearBit -------------------------------------+------------------------------------- Reporter: dylex | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.0.2 libraries/base | 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 current Bits Natural implementation says: {{{TODO: setBit, clearBit, complementBit (needs more primitives)}}}. The default implementations of setBit and complementBit work fine, but clearBit relies on complement, and so fails. Even if it had to use a conditional complementBit on testBit, it would be better than nothing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13203> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #14359: C-- pipeline/NCG fails to optimize simple repeated addition
by GHC 17 Oct '17

17 Oct '17

#14359: C-- pipeline/NCG fails to optimize simple repeated addition -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.2.1 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: -------------------------------------+------------------------------------- While debugging #14346 I noticed some rather abhorrent code in a disassembly of the `newPinnedByteArray#` primop: {{{ Dump of assembler code for function stg_newPinnedByteArrayzh: 0x00000000004a8518 <+0>: mov 0x378(%r13),%rax 0x00000000004a851f <+7>: cmpq $0x0,0x10(%rax) 0x00000000004a8524 <+12>: je 0x4a8593 <stg_newPinnedByteArrayzh+123> 0x00000000004a8526 <+14>: mov 0x4f5730,%rax 0x00000000004a852e <+22>: mov 0x38(%rax),%rax 0x00000000004a8532 <+26>: cmp 0x4f5718,%rax 0x00000000004a853a <+34>: jae 0x4a8593 <stg_newPinnedByteArrayzh+123> 0x00000000004a853c <+36>: mov %rbx,%rax 0x00000000004a853f <+39>: lea 0x7(%rax),%rcx 0x00000000004a8543 <+43>: shr $0x3,%rcx 0x00000000004a8547 <+47>: add $0x10,%rax <--- starts here 0x00000000004a854b <+51>: add $0xf,%rax 0x00000000004a854f <+55>: add $0x7,%rax 0x00000000004a8553 <+59>: shr $0x3,%rax 0x00000000004a8557 <+63>: mov $0x49d820,%ecx }}} That is three successive `add` instructions; surely those should be collapsed into one by the Cmm-to-Cmm pipeline. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14359> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3