February 2016 - ghc-tickets

[GHC] #9688: Improve the interaction between CSE and the join point transformation
by GHC 23 Aug '18

23 Aug '18

#9688: Improve the interaction between CSE and the join point transformation -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: CSE | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Runtime Blocked By: | performance bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- It appears that the join point transformation sometimes interferes with CSE when CSE would be much better. Two examples: === digitToIntMaybe === Suppose we define {{{#!hs isHexDigit :: Char -> Bool isHexDigit c = (fromIntegral (ord c - ord '0')::Word) <= 9 || (fromIntegral (ord c - ord 'a')::Word) <= 5 || (fromIntegral (ord c - ord 'A')::Word) <= 5 digitToInt c | (fromIntegral dec::Word) <= 9 = dec | (fromIntegral hexl::Word) <= 5 = hexl + 10 | (fromIntegral hexu::Word) <= 5 = hexu + 10 | otherwise = error ("Char.digitToInt: not a digit " ++ show c) -- sigh where dec = ord c - ord '0' hexl = ord c - ord 'a' hexu = ord c - ord 'A' -- We could also expand this out in cases manually, but it makes no -- difference as far as I can tell. }}} Suppose we then write a naive `digitToIntMaybe` function: {{{#!hs digitToIntMaybe c | isHexDigit c = Just (digitToInt c) | otherwise = Nothing }}} What I would want this to do is "zip" the nested cases and give Core like this: {{{ $wdigitToIntMaybe $wdigitToIntMaybe = \ ww_s2Ag -> let { x#_a2yy x#_a2yy = -# (ord# ww_s2Ag) 48 } in case tagToEnum# (leWord# (int2Word# x#_a2yy) (__word 9)) of _ { False -> let { x#1_X2z7 x#1_X2z7 = -# (ord# ww_s2Ag) 97 } in case tagToEnum# (leWord# (int2Word# x#1_X2z7) (__word 5)) of _ { False -> let { x#2_X2zh x#2_X2zh = -# (ord# ww_s2Ag) 65 } in case tagToEnum# (leWord# (int2Word# x#2_X2zh) (__word 5)) of _ { False -> Nothing; True -> Just (I# (+# x#2_X2zh 10)) }; True -> Just (I# (+# x#1_X2z7 10)) }; True -> Just (I# x#_a2yy) } digitToIntMaybe digitToIntMaybe = \ w_s2Ad -> case w_s2Ad of _ { C# ww1_s2Ag -> $wdigitToIntMaybe ww1_s2Ag } }}} But instead, the join point transformation triggers, and we get this: {{{ digitToIntMaybe1 digitToIntMaybe1 = \ ww_s2Cp -> error (unpackAppendCString# "Char.digitToInt: not a digit "# ($w$cshowsPrec15 ww_s2Cp ([]))) $wdigitToIntMaybe $wdigitToIntMaybe = \ ww_s2Cp -> let { $j_s2Bc $j_s2Bc = \ _ -> Just (let { a_s2B5 a_s2B5 = int2Word# (-# (ord# ww_s2Cp) 48) } in case tagToEnum# (leWord# a_s2B5 (__word 9)) of _ { False -> let { a1_s2B7 a1_s2B7 = int2Word# (-# (ord# ww_s2Cp) 97) } in case tagToEnum# (leWord# a1_s2B7 (__word 5)) of _ { False -> let { a2_s2B9 a2_s2B9 = int2Word# (-# (ord# ww_s2Cp) 65) } in case tagToEnum# (leWord# a2_s2B9 (__word 5)) of _ { False -> digitToIntMaybe1 ww_s2Cp; True -> I# (+# (word2Int# a2_s2B9) 10) }; True -> I# (+# (word2Int# a1_s2B7) 10) }; True -> I# (word2Int# a_s2B5) }) } in case tagToEnum# (leWord# (int2Word# (-# (ord# ww_s2Cp) 48)) (__word 9)) of _ { False -> case tagToEnum# (leWord# (int2Word# (-# (ord# ww_s2Cp) 97)) (__word 5)) of _ { False -> case tagToEnum# (leWord# (int2Word# (-# (ord# ww_s2Cp) 65)) (__word 5)) of _ { False -> Nothing; True -> $j_s2Bc void# }; True -> $j_s2Bc void# }; True -> $j_s2Bc void# } digitToIntMaybe digitToIntMaybe = \ w_s2Cm -> case w_s2Cm of _ { C# ww1_s2Cp -> $wdigitToIntMaybe ww1_s2Cp } }}} We perform the same three tests twice each, and test for an error condition that obviously can't happen. === `quotRem` and `divMod` === If we define {{{#!hs x `quot` y = fst (x `quotRem` y) x `rem` y = snd (x `quotRem` y) }}} and then write something like {{{#!hs f x y | x `rem` y == 0 = x `quot` y | otherwise = 17 }}} then CSE works some magic and we only calculate `quotRem x y` once. Unfortunately, if we do this: {{{#!hs whatever x y = if x `myRem` y == 0 then (x `myQuot` y) + 14 else x `myQuot` y }}} then the join point transformation fires, collecting the `myQuot x y` expressions in the case branches and preventing CSE from recognizing the much better opportunity to eliminate those calculations altogether. The situation with `divMod` is much worse. The join point transformation applied to the cases defining `divMod` prevents CSE from working magic on it in even simple situations, unless one of the arguments is known, making this definition unusable (the resulting Core is too horrifyingly long to paste here). It would probably be possible to improve the `divMod` situation to something close to the `quotRem` one by making `divMod` `NOINLINE` and adding special `divModLit` rules, but I'd much rather see a general solution. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9688> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10100: Bogus "redundant constraint" warning with functional dependencies
by GHC 23 Aug '18

23 Aug '18

#10100: Bogus "redundant constraint" warning with functional dependencies -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Compiling this code with GHC HEAD: {{{#!hs {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE UndecidableInstances #-} module T10100 where data Zero data Succ a class Add a b ab | a b -> ab, a ab -> b instance Add Zero b b instance (Add a b ab) => Add (Succ a) b (Succ ab) }}} Gives a bogus warning about redundant constraint: {{{ Redundant constraint: Add a b ab In the instance declaration for ‘Add (Succ a) b (Succ ab)’ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10100> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11409: Cannot instantiate literals using TypeApplications
by GHC 22 Aug '18

22 Aug '18

#11409: Cannot instantiate literals using TypeApplications -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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: -------------------------------------+------------------------------------- {{{ GHCi, version 8.0.1.20160110: http://www.haskell.org/ghc/ :? for help Prelude> :set -XTypeApplications -fprint-explicit-foralls Prelude> :t 42 42 :: forall {a}. Num a => a Prelude> 42 @Int <interactive>:3:1: error: • Cannot not apply expression of type ‘a0’ to a visible type argument ‘Int’ • In the expression: 42 @Int In an equation for ‘it’: it = 42 @Int }}} (Also, "cannot not" looks like a typo.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11409> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 29

[GHC] #10869: Option to dump preprocessed source
by GHC 21 Aug '18

21 Aug '18

#10869: Option to dump preprocessed source -------------------------------------+------------------------------------- Reporter: phischu | Owner: Type: feature | Status: new request | Priority: low | Milestone: Component: Driver | 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 Revisions: | -------------------------------------+------------------------------------- It would be awesome if GHC had an option `-ddump-preprocessed` that dumps the source code for each module after preprocessing. I am not sure what the current definition of "preprocessing" is but I mean the output of at least the following tools: happy, alex, c2hs, hsc2hs and cpp. Additionally even if a module was not subject to any preprocessing it should be dumped anyway. Use case: I want to parse module files from packages from hackage with `haskell-src-exts` but find it prohibitively difficult to get the preprocessing right. The idea is that after `cabal install` with ghc options `-ddump-preprocessed -ddump-to-file -dumpdir real_modules` you get a complete working set of haskell modules that can be parsed directly without any preprocessing in folder `real_modules`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10869> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #9854: Literal overflow check is too aggressive
by GHC 21 Aug '18

21 Aug '18

#9854: Literal overflow check is too aggressive -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The literal overflow check is too aggressive. Sometimes you want to give a literal as a hexadecimal value that does fit inside e.g. an `Int`, like so: {{{ Prelude> 0xdc36d1615b7400a4 :: Int <interactive>:2:1: Warning: Literal 15868100553162883236 is out of the Int range -9223372036854775808..9223372036854775807 -2578643520546668380 }}} However the compiler complains because of the wrap-around. I feel this is common enough and practice (and perfectly well-defined) that the compiler shouldn't warn. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9854> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11394: Base should use native Win32 IO on Windows
by GHC 20 Aug '18

20 Aug '18

#11394: Base should use native Win32 IO on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Core | Version: 7.10.3 Libraries | 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: -------------------------------------+------------------------------------- There are a variety of issues caused by the impedance mismatch between GHC's use of Posix I/O interfaces on Windows (particularly with respect to console I/O), * #10542: Incorrect Unicode input on Windows Console * #7593: Unable to print exceptions of unicode identifiers * #4471: Incorrect Unicode output on Windows Console * #2189: hSetBuffering stdin NoBuffering doesn't work on Windows As pointed on in ticket:2189#comment:12 the ultimate solution to this would be to move all of GHC's IO to use the respective Win32 interfaces. = Also relevant = * #7353: Windows lacks support in the I/O manager * #806: hGetBufNonBlocking doesn't work on Windows * #3081: Double output after Ctrl+C on Windows -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11394> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #10542: Incorrect Unicode input on Windows Console
by GHC 20 Aug '18

20 Aug '18

#10542: Incorrect Unicode input on Windows Console -------------------------------------+------------------------------------- Reporter: ptroev | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.3 Keywords: windows | Operating System: Windows stdin utf-8 cmd chcp 65001 | Type of failure: Incorrect result getLine | at runtime Architecture: | Blocked By: Unknown/Multiple | Related Tickets: 4471 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- To reproduce: - start a windows console - change the console's font to a ttf unicode font, like "Lucida Console". - type "chcp 65001" to set it to the UTF-8 code page. - start ghci (same error appears when running compiled executable) - > import System.IO (or GHC.IO.Handle) - > enc <- mkTextEncoding "UTF8" - > hSetEncoding stdin enc - > getLine - > Фывфыв (or any international unicode sequence) *** Exception: <stdin>: hGetLine: end of file -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10542> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9441: Merge identical top-level expressions following simplification when it is safe to do so
by GHC 18 Aug '18

18 Aug '18

#9441: Merge identical top-level expressions following simplification when it is safe to do so -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- If I redefine {{{#!hs {-# INLINE reverse #-} reverse :: [a] -> [a] reverse xs = build $ \c n -> foldl (\a x -> x `c` a) n xs }}} and then write a couple test cases: {{{#!hs appRev xs ys = xs ++ reverse ys revAppRev xs ys = reverse xs ++ reverse ys }}} I end up getting some rather annoying code duplication (lots of stuff omitted from the following): {{{#!hs Rec { poly_go_r2v3 poly_go_r2v3 = \ @ a_a2nF ds_a2zc eta_Xl -> case ds_a2zc of _ { [] -> eta_Xl; : y_a2zh ys_a2zi -> poly_go_r2v3 ys_a2zi (: y_a2zh eta_Xl) } end Rec } reverse reverse = \ @ a_a2nF eta_B1 -> poly_go_r2v3 eta_B1 ([]) Rec { revAppRev2 revAppRev2 = \ @ a_a2y7 ds_a2zc eta_B1 -> case ds_a2zc of _ { [] -> eta_B1; : y_a2zh ys_a2zi -> revAppRev2 ys_a2zi (: y_a2zh eta_B1) } end Rec } Rec { revAppRev1 revAppRev1 = \ @ a_a2y7 ds_a2zc eta_B1 -> case ds_a2zc of _ { [] -> eta_B1; : y_a2zh ys_a2zi -> revAppRev1 ys_a2zi (: y_a2zh eta_B1) } end Rec } Rec { appRev1 appRev1 = \ @ a_a2xE ds_a2zc eta_B1 -> case ds_a2zc of _ { [] -> eta_B1; : y_a2zh ys_a2zi -> appRev1 ys_a2zi (: y_a2zh eta_B1) } end Rec } }}} The `reverse` function was inlined three times. In each case, there was no fusion, so `build` was inlined and the resulting copy of the `reverse` worker lifted to the top level. It would seem to me that once simplification is complete, it should be safe to merge all these copies into one. They are all `Rec {\ ... -> ...}` forms, so I don't think this has any potential to introduce undesirable sharing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9441> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #8944: Warn instead of stopping on misplaced Haddock comments
by GHC 17 Aug '18

17 Aug '18

#8944: Warn instead of stopping on misplaced Haddock comments -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Given a simple module like {{{ module H where data F = F () -- ^ Comment for first type argument () }}} and trying to run Haddock on it, we'll get back {{{ /tmp/H.hs:4:12: parse error on input ‘(’ }}} The error message is rather sub-par in this scenario. It'd be great if we could instead print a warning saying that a Haddock comment is unexpected in that position and then continue on parsing. Best case scenario would be a more informative message such as “Documenting each constructor argument is not supported” but that might be quite a bit harder. Filing on GHC Trac as it's the parser that needs changing I believe. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8944> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #9214: UNPACK support for sum types
by GHC 11 Aug '18

11 Aug '18

#9214: UNPACK support for sum types ------------------------------------+------------------------------------- Reporter: mojojojo | 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: | ------------------------------------+------------------------------------- Currently the pragma only supports single-constructor types. So in the following example it will simply be ignored: {{{ data A = A1 Char | A2 {-# UNPACK #-} !B data B = B1 Int | B2 Bool }}} However the problem seems to be easily solvable by denormalizing the type {{{A}}} to something like the following during unpacking: {{{ data A = A1 Char | A2_1 Int | -- from B1 A2_2 Bool -- from B2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9214> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9