December 2017 - ghc-tickets

[GHC] #14336: ghci leaks memory
by GHC 23 Aug '18

23 Aug '18

#14336: ghci leaks memory -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following script spawns ghci, and that spawned ghci then goes on to leak memory: {{{#!hs import Control.Concurrent import Control.Monad import System.IO import System.Process main = do (Just hin, Nothing, Nothing, pid) <- createProcess (proc "ghci" ["+RTS","-S"]){std_in=CreatePipe} forever $ do threadDelay 100000 -- 0.1s hPutStrLn hin "\"this is a test of outputting stuff\"" hFlush hin }}} This script just writes a string to GHCi, which then echos it back. The {{{+RTS -S}}} is useful to watch the live memory tick up in realtime, but it leaks without it, and the leak can be seen in process explorer (87Mb to 700Mb over about 30 minutes). While repeatedly writing commands may not be a standard usage of ghci, it is when driven by tools such as ghcid (https://hackage.haskell.org/package/ghcid) and other IDE-like uses. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14336> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 27

[GHC] #14111: strange error when using data families with levity polymorphism and unboxed sums and data families
by GHC 22 Aug '18

22 Aug '18

#14111: strange error when using data families with levity polymorphism and unboxed sums and data families -------------------------------------+------------------------------------- Reporter: carter | 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: -------------------------------------+------------------------------------- I've the following small example {{{ {-# LANGUAGE MagicHash, UnboxedSums, NoImplicitPrelude #-} {-# LANGUAGE TypeFamilies #-} -- {-# LANGUAGE PolyKinds #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE GADTs ,ExplicitNamespaces#-} {-# LANGUAGE UnboxedTuples #-} module Data.Unboxed.Maybe where import GHC.Exts import GHC.Types import Prelude (undefined) import Data.Void data family Maybe(x :: TYPE (r :: RuntimeRep)) data instance Maybe (a :: * ) where MaybeSum :: (# a | (# #) #) -> Maybe a data instance Maybe (x :: TYPE 'UnliftedRep) where MaybeSumU :: (# x | (# #) #) -> Maybe x }}} and then i get the error (made much saner to read by use of printing explicit kinds) {{{ Prelude> :r [1 of 1] Compiling Data.Unboxed.Maybe ( src/Data/Unboxed/Maybe.hs, interpreted ) src/Data/Unboxed/Maybe.hs:22:3: error: • Data constructor ‘MaybeSumU’ returns type ‘Maybe 'LiftedRep x’ instead of an instance of its parent type ‘Maybe 'UnliftedRep x’ • In the definition of data constructor ‘MaybeSumU’ In the data instance declaration for ‘Maybe’ | 22 | MaybeSumU :: (# x | (# #) #) -> Maybe x }}} this is a) a case where printing runtime reps makes things easier to debug :) b) a very confusing type error since the data instance clearly says "x :: TYPE 'UnliftedRep " is there something i'm overlooking, or is this a bug? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14111> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 27

[GHC] #12674: GHC doesn't handle ./ prefixed paths correctly
by GHC 22 Aug '18

22 Aug '18

#12674: GHC doesn't handle ./ prefixed paths correctly -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC doesn't correctly handle paths preceded by `./` on the command line, if their first character (after any number of `./`s) is a `-`. For instance, `ghc ./-a.hs` fails, even if `a.hs` exists. Somewhere, `./-a.hs` is being converted to `-a.hs`. I have not been able to figure out where this happens. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12674> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[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] #13363: Wildcarn patterns and COMPLETE sets can lead to misleading redundant pattern-match warnings
by GHC 21 Aug '18

21 Aug '18

#13363: Wildcarn patterns and COMPLETE sets can lead to misleading redundant pattern-match warnings -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider this program: {{{#!hs {-# LANGUAGE PatternSynonyms #-} {-# LANGUAGE ViewPatterns #-} {-# OPTIONS_GHC -Wincomplete-patterns #-} module Bug where data Boolean = F | T deriving Eq pattern TooGoodToBeTrue :: Boolean pattern TooGoodToBeTrue <- ((== T) -> True) where TooGoodToBeTrue = T {-# COMPLETE F, TooGoodToBeTrue #-} catchAll :: Boolean -> Int catchAll F = 0 catchAll TooGoodToBeTrue = 1 }}} This compiles with no warnings with `-Wall`. But if you tweak `catchAll` to add a catch-all case at the end: {{{#!hs {-# LANGUAGE PatternSynonyms #-} {-# LANGUAGE ViewPatterns #-} {-# OPTIONS_GHC -Wincomplete-patterns #-} module Bug where data Boolean = F | T deriving Eq pattern TooGoodToBeTrue :: Boolean pattern TooGoodToBeTrue <- ((== T) -> True) where TooGoodToBeTrue = T {-# COMPLETE F, TooGoodToBeTrue #-} catchAll :: Boolean -> Int catchAll F = 0 catchAll TooGoodToBeTrue = 1 catchAll _ = error "impossible" }}} Then if you compile it with `-Wall`, you'll get a very misleading warning: {{{ $ ~/Software/ghc2/inplace/bin/ghc-stage2 --interactive Bug.hs -Wall GHCi, version 8.1.20170228: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:17:1: warning: [-Woverlapping-patterns] Pattern match is redundant In an equation for ‘catchAll’: catchAll TooGoodToBeTrue = ... | 17 | catchAll TooGoodToBeTrue = 1 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} I would have expected the warning to be on the `catchAll _ = error "impossible"` case! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13363> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[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] #12467: distclean does not clean 'compact' library
by GHC 21 Aug '18

21 Aug '18

#12467: distclean does not clean 'compact' library -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.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: -------------------------------------+------------------------------------- {{{ > ghc_2 git:(master) make distclean 2>&1 | grep compact > ghc_2 git:(master) }}} I think we should see something like {{{ "rm" -rf libraries/compact/dist-install }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12467> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #12482: Infinite compilation time when using wrongly ordered constraints
by GHC 20 Aug '18

20 Aug '18

#12482: Infinite compilation time when using wrongly ordered constraints -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- Hello guys! I've seen today a very strange bug in GHC 8. Namely I've got an instance: {{{ instance {-# OVERLAPPABLE #-} (PrimMonad m, g ~ HMGraph s rels, (g ^. t) ~ Hetero2 (MAutoVector s), s ~ PrimState m, HasProperty2' t g) => DynamicM t (HMGraph s rels) m a where addM el = nested (prop2' @t . wrapped') $ (swap ∘ fmap Ptr) <∘> ixed Cont.addM (unsafeCoerce el) }}} and I'm using it indirectly in Main.hs. It compiles fast and works fine. The problem is that when I change the above constraint to: {{{ (PrimMonad m, HasProperty2' t g, g ~ HMGraph s rels, (g ^. t) ~ Hetero2 (MAutoVector s), s ~ PrimState m) }}} Which is basically the same but with different order, the file with this constraint compiles fast and fine, but Main.hs compiles infinite amount of time (I've killed it after 10 minutes). The problem is reproducible, but it is hard right now to make minimal example out of it (we are going to a conference with a product release and we cannot track it right now). I post it here because maybe the bug is known, if not, after the release I'll try to provide more info. If you've got any questions I'd love to assist. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12482> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[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