November 2014 - ghc-tickets

[GHC] #9044: createDirectoryIfMissing does not fail on unwritable parent dir
by GHC 02 Mar '15

02 Mar '15

#9044: createDirectoryIfMissing does not fail on unwritable parent dir -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.8.2 libraries/directory | Operating System: MacOS X Keywords: | Type of failure: Incorrect result Architecture: Unknown/Multiple | at runtime Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- On OSX, using `createDirectoryIfMissing` to create a new directory inside a directory for which we do not have write permissions does not throw any exception. Of course it should throw an exception, as it does under Linux. {{{ $ mkdir unwritable $ chmod ugo-w unwritable $ ghci > System.Directory.createDirectoryIfMissing True "unwritable/tst" > }}} On OSX (10.9.2) this does not fail. Under Linux (albeit with 7.6.3) this does throw an exception as expected: {{{ *** Exception: unwritable/tst: createDirectory: permission denied (Permission denied) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9044> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9697: ./configure fails due to obselete usage of 'find -perm' in aclocal.m4
by GHC 02 Mar '15

02 Mar '15

#9697: ./configure fails due to obselete usage of 'find -perm' in aclocal.m4 -------------------------------------+------------------------------------- Reporter: nich | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.3 Keywords: aclocal.m4 find | Operating System: perm | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Building Difficulty: Easy (less than 1 | GHC failed hour) | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- ./configure produces error message when building on current Fedora (20). According to find ver 4.5.11 the usage '-perm +XXX' has been deprecated since 2005 (use '-perm \XXX' instead). The message '/usr/bin/find: invalid mode '+111' ' is seen several times as a result. Whether this has any material impact I am not qualified to judge. I am actually trying to build HaLVM (from Galois) and first noticed the issue in their fork of GHC. However, this behaviour is also present in git HEAD (commit d7867810d5ffd08c77c30e928bb3dca21beae0b9). Making the obvious one line change in aclocal.m4 resolves the issue, and produces a clean build, for me at least. Patch attached -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9697> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9328: MINIMAL pragma should supprt negation
by GHC 02 Mar '15

02 Mar '15

#9328: MINIMAL pragma should supprt negation -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Differential Revisions: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------+------------------------------------- Consider this class declaration {{{ class Conv a where to :: Integer -> a from :: a -> Integer default to :: (Generic a) => Integer -> a to i = ... default from :: (Generic a) => a -> Integer from a = ... }}} The class provides default methods for the two methods using generics. An instance declaration for this type is likely to want to use the default for both methods or for none. So I'd like a MINIMAL pragma that can express this. E.g. {{{ {-# MINIMAL (to, from) | (!to, !from) #-} }}} I've used ! for negation (following the lead set by the MINIMAL pragma using a non-Haskell OR operator), so this says: either implement 'to' and 'from' or don't implement neither 'to' nor 'from'. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9328> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8896: ghci fails on Arm - "Illegal instruction"
by GHC 01 Mar '15

01 Mar '15

#8896: ghci fails on Arm - "Illegal instruction" ----------------------------+------------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Keywords: arm ghci | Operating System: Linux Architecture: arm | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+------------------------------- With the help of qemu compiled ghc 7.8.1-rc2 for raspberry pi. Ghc is successful, and ghci compiles, but ghci gets an 'Illegal instruction' error. A sample session: ccrma@satellite:~$ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.0.20140228 ccrma@satellite:~$ ghci --version The Glorious Glasgow Haskell Compilation System, version 7.8.0.20140228 ccrma@satellite:~$ ghci GHCi, version 7.8.0.20140228: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... Illegal instruction ccrma@satellite:~$ -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8896> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #9795: Debug.Trace.trace is too strict
by GHC 01 Mar '15

01 Mar '15

#9795: Debug.Trace.trace is too strict -------------------------------------+------------------------------------- Reporter: jcpetruzza | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | 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: -------------------------------------+------------------------------------- Consider the following toy example: {{{#!hs import Debug.Trace f n = let res = g n in (trace $ unlines ["in: " ++ show n, "out: " ++ show res]) res where g n = if n <= 1000 then n+1 else g n main = print $ [f 500, f 302, f 2000, f 22] }}} When run it outputs: {{{ in: 500 out: 501 in: 302 out: 303 ^C }}} In a real example, for a program that hangs, where one only ''suspects'' that `f` may be the culprit, and where `f` is being called from various places with different values, this output is not very useful (and in fact, it is misleading). My mental model of the `trace` function is something along these lines: {{{#!hs myTrace :: String -> a -> a myTrace s a = unsafePerformIO $ do putStrLn s return a }}} and in fact, replacing `trace` by `myTrace` in the example above one gets the more useful: {{{ in: 500 out: 501 in: 302 out: 303 in: 2000 ^C }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9795> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #9586: Implement Traversable/Foldable-Burning-Bridges Proposal
by GHC 27 Feb '15

27 Feb '15

#9586: Implement Traversable/Foldable-Burning-Bridges Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Difficult (2-5 | Type of failure: days) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- More details to follow. I've created this ticket to be able to refer to from related preparatory commits. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9586> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 45

[GHC] #8189: Default to infinite stack size?
by GHC 24 Feb '15

24 Feb '15

#8189: Default to infinite stack size? ------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- http://www.haskell.org/pipermail/haskell-cafe/2013-August/108570.html It looks like any code of the form {{{ ... = do x1 <- m1 x2 <- m2 [do something with x1 and m2] }}} will stack overflow when used with a strict monad (like IO) and sufficiently large data to deal with (a 1m element list is enough to exceed the default 8MB stack size limit). Other examples include: {{{ sequence (m:ms) = do x <- m xs <- sequence ms return (x:xs) }}} and {{{ liftM2, liftM3, ... }}} By slightly modifying your program to do the same thing via heap allocation (e.g. using a difference list in sequence), a stack-overflow rejected program turns into a valid program. This means that valid and idiomatic code like {{{ xs <- replicateM n someIOAction xs <- mapM someIOAction [1..n] }}} will eventually crash, which has an impact on practically all Haskell software and libraries out there. For examples, see https://github.com/ndmitchell/shake/blob/e0e0a43/Development/Shake/Database… https://github.com/haskell-suite/haskell-src-exts/issues/27 as well as the mapM usages in cabal, haddock, any database binding that allows querying a lists of results, etc. While some argue that ''"you shouldn't use lists of that size"'', ''"allocating a 150 MB list is wrong"'' or that they ''"carefully avoid any use of sequence/mapM due to the problem"'' pointed out above, I think that collecting a million results of a strict monadic action into a linked list using standard functions like mapM is a common pattern and valid use case. The stack based evaluation that GHC performs is an optimization and should be transparent to the user; it should not re-define some data to live in a fixed-size memory region, and it should work just as well as it does in GHCi. It seems that a default infinite stack size would mitigate this. A drawback might be that the stack space overflows we get so far to quickly spot a "wrong" program would not indicate certain errors any more. I currently doubt the usefulness of this debugging method, since it does not work reliably in the presence of optimization, doing the same thing via heap allocation makes the programs "correct", and it rejects valid programs if the input data is large enough. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8189> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 35

[GHC] #9103: hackage's type-level-0.2.4 fails to compile
by GHC 23 Feb '15

23 Feb '15

#9103: hackage's type-level-0.2.4 fails to compile -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: Unknown/Multiple | valid program Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Attached trimmed-down dependencyless archive. Steps to reproduce: {{{ $ tar -xzf type-level-0.2.4.tar.gz $ ghci -hide-all-packages -package=base -package=template-haskell Data/TypeLevel.hs }}} The error on 7.8.2 and in -HEAD is: {{{ [6 of 8] Compiling Data.TypeLevel.Num.Ops ( Data/TypeLevel/Num/Ops.hs, interpreted ) Data/TypeLevel/Num/Ops.hs:90:10: Illegal instance declaration for ‘Succ' (x, x) (x, x) D0 D0 True’ The liberal coverage condition fails in class ‘Succ'’ for functional dependency: ‘yh yl yz -> xh xl’ Reason: lhs types ‘D0’, ‘D0’, ‘True’ do not jointly determine rhs types ‘(x, x)’, ‘(x, x)’ In the instance declaration for ‘Succ' (x, x) (x, x) D0 D0 True’ ... }}} Typechecked fine on ghc-7.6.3 {{{ [1 of 8] Compiling Data.TypeLevel.Num.Reps ( Data/TypeLevel/Num/Reps.hs, interpreted ) [2 of 8] Compiling Data.TypeLevel.Num.Sets ( Data/TypeLevel/Num/Sets.hs, interpreted ) [3 of 8] Compiling Data.TypeLevel.Num.Aliases.TH ( Data/TypeLevel/Num/Aliases/TH.hs, interpreted ) [4 of 8] Compiling Data.TypeLevel.Num.Aliases ( Data/TypeLevel/Num/Aliases.hs, interpreted ) Generating and compiling a zillion numerical type aliases, this might take a while [5 of 8] Compiling Data.TypeLevel.Bool ( Data/TypeLevel/Bool.hs, interpreted ) [6 of 8] Compiling Data.TypeLevel.Num.Ops ( Data/TypeLevel/Num/Ops.hs, interpreted ) [7 of 8] Compiling Data.TypeLevel.Num ( Data/TypeLevel/Num.hs, interpreted ) [8 of 8] Compiling Data.TypeLevel ( Data/TypeLevel.hs, interpreted ) Ok, modules loaded: Data.TypeLevel, Data.TypeLevel.Num, Data.TypeLevel.Bool, Data.TypeLevel.Num.Reps, Data.TypeLevel.Num.Aliases, Data.TypeLevel.Num.Sets, Data.TypeLevel.Num.Ops, Data.TypeLevel.Num.Aliases.TH. *Data.TypeLevel> }}} I have failed to decipher an error message, but looks like it tries to instantiate a thing it should not. My apologies if it's not-a-bug. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9103> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #9778: Namespace collision detection for promoted types
by GHC 23 Feb '15

23 Feb '15

#9778: Namespace collision detection for promoted types -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: feature request | 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: -------------------------------------+------------------------------------- In the following example {{{#!hs {-# LANGUAGE DataKinds #-} module Foo where data Nat = Z | S Nat data S foo :: S n -> S n foo = id }}} GHC displays the error {{{ Foo.hs:12:8: ‘S’ is applied to too many type arguments In the type signature for ‘foo’: foo :: S n -> S n Failed, modules loaded: none. }}} Although it's clear in my example where the problem is, this example was distilled from a case where I imported module1 with type `S` defined and module2 with the promoted type `S`, which is what I was trying to use. Can we get namespace collision detection instead? Something like: {{{ Foo.hs:9:15 Ambiguous occurence ‘S’ It could refer to either Foo.S defined at Foo.hs:7:1 or to the promoted constructor S defined at Foo.hs:5:16 Use 'S to refer to the promoted constructor. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9778> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #8539: Data.Complex shouldn't use default implementation of (**)
by GHC 23 Feb '15

23 Feb '15

#8539: Data.Complex shouldn't use default implementation of (**) -------------------------------------+------------------------------------- Reporter: jjaredsimpson | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Prelude | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Incorrect result Difficulty: Easy (less than 1 | at runtime hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- {{{ Prelude Data.Complex> 0**2 0.0 Prelude Data.Complex> 0**2 :: Complex Double NaN :+ NaN Prelude Data.Complex> exp $ 2 * log 0 :: Complex Double NaN :+ NaN Prelude Data.Complex> log 0 :: Complex Double (-Infinity) :+ 0.0 Prelude Data.Complex> 2 * it :: Complex Double (-Infinity) :+ NaN Prelude Data.Complex> exp it :: Complex Double NaN :+ NaN }}} So Complex uses the default implementation of (!**). Then when 2*(-inf :+ 0) is evaluated. We do (2 * -inf - 0*0) :+ (2*0 + -inf*0). Which because of -inf*0 sets the imaginary part to NaN. Then exp (-inf :+ NaN) = exp x cos y :+ exp x sin y which becomes 0 * cos NaN :+ 0 * sin NaN. So we end up with NaN :+ NaN. Ross Paterson suggested: I would say the default implementation of (!**) is wrong: to match the Float/Double instances it should be x !** y = if x == 0 then 0 else exp (log x * y) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8539> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 44