January 2015 - ghc-tickets

[GHC] #9070: "Simplifier ticks exhausted"
by GHC 31 Jul '15

31 Jul '15

#9070: "Simplifier ticks exhausted" ----------------------------------+------------------------------------- Reporter: dermesser | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+------------------------------------- I know nothing more than what GHC said (I'm on debian, installed from the repositories). {{{ (GHC version 7.6.3 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone base:GHC.Base.$fMonadIO_$c>>={v rJ2} [gid] To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 31764 }}} The code triggering the error is the code commented out in lines 52-54: {{{ 42 redis_family_raw <- getEnv redisFamilyVar 43 redis_addr <- getEnv redisAddressVar 44 redis_port <- getEnv redisPortVar 45 46 (family,redis_family) <- case (parseFamily family_raw,parseFamily redis_family_raw) of 47 (Just fam, Just rfam) -> return (fam,rfam) 48 x -> fail $ "Unknown address family: " ++ show x 49 50 sockaddr <- getSockAddr family broker_address broker_port_raw 51 52 --redis_conn <- case redis_family of 53 -- WAFamilyInet -> R.connect $ defaultConnectInfo { connectHost = redis_addr, connectPort = Service redis_port } 54 -- WAFamilyUnix -> R.connect $ defaultConnectInfo { connectPort = UnixSocket redis_addr } }}} However, this bug occurs only when compiling with cabal. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9070> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9227: Coverage Condition cannot be turned off
by GHC 31 Jul '15

31 Jul '15

#9227: Coverage Condition cannot be turned off ------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | 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: | ------------------------------------+------------------------------------- Compile this program {{{ {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies #-} module Bug1 where class C a b | a -> b data A a = A data B a = B instance C (A a) (B b) }}} and observe the error message {{{ Bug1.hs:9:10: Illegal instance declaration for `C (A a) (B b)' The coverage condition fails in class `C' for functional dependency: `a -> b' Reason: lhs type `A a' does not determine rhs type `B b' In the instance declaration for `C (A a) (B b)' }}} Then read manual, sec 7.6.3.3: {{{ Both the Paterson Conditions and the Coverage Condition are lifted if you give the -XUndecidableInstances flag }}} Compile again with -XUndecidableInstances. Observe the exact same error message. Either the compiler or the documentation is wrong. I certainly hope it is the compiler, because it worked in 7.6 and was quite useful. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9227> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8253: example "Core syntax" is ancient
by GHC 31 Jul '15

31 Jul '15

#8253: example "Core syntax" is ancient -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Documentation Difficulty: Easy (less than 1 | bug hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- [http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/options- debugging.html#idp39365504 User's guide section 4.19.5] has some funky "Core syntax" that (according to git blame) dates back to at least 2000, and probably longer ago than that. It could use an update. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8253> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8151: ghc-7.4.2 on OpenIndiana (Solaris) createSubprocess fails
by GHC 31 Jul '15

31 Jul '15

#8151: ghc-7.4.2 on OpenIndiana (Solaris) createSubprocess fails ----------------------------+-------------------------------------------- Reporter: troydm | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.2 Keywords: | Operating System: Solaris Architecture: x86 | Type of failure: Runtime performance bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+-------------------------------------------- when i'm compiling this test.hs with ghc -thread ./test.hs and then execute it i get Starting Subprocess Exit code: ExitFailure 127 This error code indicates that command isn't found (i have ghc in /usr/local/bin) and it's specified in PATH variable, however it acts as if it's not even there however if i remove -threaded flag and recompile code again, it works Starting Subprocess ghc: no input files Usage: For basic information, try the `--help' option. Exit code: ExitFailure 1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8151> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9114: Invalid UTF8 not round-tripped correctly
by GHC 31 Jul '15

31 Jul '15

#9114: Invalid UTF8 not round-tripped correctly ------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- As reported by Robert Bihlmeyer at http://bugs.debian.org/748125, the promised round-tripping of invalid UTF8 sequences in filenames through String does not work: ``` $ mkdir foo $ touch foo/$(echo -e '\xC0\xB7.txt') $ ghc -e 'System.Directory.getDirectoryContents "foo" >>= print . last' "7.txt" ``` The sequence 0xC8B7 is an (invalid) encoding of 37, i.e. `'7'`, so if it is mapped to `'7'`, no round-tripping is possible. (Other invalid byte sequences are round-tripped.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9114> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9385: Additions to Control.Monad
by GHC 31 Jul '15

31 Jul '15

#9385: Additions to Control.Monad -------------------------------------+------------------------------------- Reporter: olf | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: libraries/base | 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: -------------------------------------+------------------------------------- I'd like to propose the following additions/changes to Control.Monad: `mfilter` can be generalised: {{{#!hs gen_mfilter :: Monad m => (a -> m ()) -> m a -> m a gen_mfilter f ma = (\a -> liftM (const a) (f a)) =<< ma }}} Now we obtain the old `mfilter` as {{{#!hs gen_mfilter.(guard.) }}} Further, `m ()` is a monoid for every monad, which would cause conflicts for `[()]`, to name one example. (The usual monoid instance of `[()]` is addition of natural numbers, while the monadic monoid instance is multiplication.) More generally, the monoid `m ()` acts on every type `m a` in the following way: {{{#!hs mtimes :: Monad m => m () -> m a -> m a mtimes = gen_mfilter.const = liftM2 (flip const) when = mtimes.guard }}} For example, each element of a list can be duplicated like this: {{{#!hs mtimes [(),()] }}} To see why these functions are useful, consider the `DDist` monad of the ProbabilityMonads package: Since `DDist ()` is essentially the monoid of real numbers with multiplication, `gen_mfilter f` updates a distribution by multiplying the weight of `x` by `f x`. Another example is the state monad `ST s`, where type `(a -> ST s ())` is essentially `a -> s -> s`, so these functions encode changes that, when used with `gen_mfilter` alter state, not the value. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9385> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9260: Unnecessary error using GHC.TypeLits
by GHC 30 Jul '15

30 Jul '15

#9260: Unnecessary error using GHC.TypeLits -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Keywords: type lits, data | Operating System: Linux kinds, error message | Type of failure: Incorrect Architecture: Unknown/Multiple | warning at compile-time Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Compiling: {{{ {-# LANGUAGE DataKinds, TypeOperators, GADTs #-} module Error where import GHC.TypeLits data Fin n where Fzero :: Fin (n + 1) Fsucc :: Fin n -> Fin (n + 1) }}} gives a strange (unnecessary) error message claiming that `Fin 1` doesn't match the expected type `Fin (0 + 1)`: {{{ % ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.2 % ghc -ignore-dot-ghci /tmp/Error.hs [1 of 1] Compiling Error ( /tmp/Error.hs, /tmp/Error.o ) /tmp/Error.hs:12:8: Couldn't match type ‘0’ with ‘1’ Expected type: Fin 1 Actual type: Fin (0 + 1) In the expression: Fsucc Fzero In an equation for ‘test’: test = Fsucc Fzero /tmp/Error.hs:12:14: Couldn't match type ‘1’ with ‘0’ Expected type: Fin 0 Actual type: Fin (0 + 1) In the first argument of ‘Fsucc’, namely ‘Fzero’ In the expression: Fsucc Fzero % }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9260> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9772: Building documentation alone is broken
by GHC 30 Jul '15

30 Jul '15

#9772: Building documentation alone is broken -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Build System | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Building Blocked By: | GHC failed Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- At the moment it seems that the only way to build documentation is to actually build all of GHC, which is nonsense. Methods of building documentation described in Building/Docs are broken: {{{ To build just the Haddock docs for a given library, do this: cd libraries/base make html stage=0 FAST=YES }}} That ends with errors. See `haddock_for_lib.log` attachement. {{{ To build a document on its own, for example the Users Guide, do this: cd docs/users_guide make html stage=0 FAST=YES substitute 'html' for 'pdf' or 'ps' to build other types of documentation. }}} That also ends with errors. See `users_guide.log` attachement. For above experiments I used the following lines in my `mk/build.mk` file: {{{ HADDOCK_DOCS = YES BUILD_DOCBOOK_HTML = YES BUILD_DOCBOOK_PS = NO BUILD_DOCBOOK_PDF = NO }}} Then I run `perl boot && ./configure`. I didn't run `make`, just the above instructions. My configure returns this: {{{ Configure completed successfully. Building GHC version : 7.9.20141105 Build platform : x86_64-unknown-linux Host platform : x86_64-unknown-linux Target platform : x86_64-unknown-linux Bootstrapping using : /home/killy/.ghc-sandbox/bin/ghc which is version : 7.8.3 Using gcc : /usr/bin/gcc which is version : 4.5.1 Building a cross compiler : NO cpp : /usr/bin/gcc cpp-flags : -E -undef -traditional ld : /usr/bin/ld Happy : /home/killy/.cabal/bin/happy (1.19.4) Alex : /home/killy/.cabal/bin/alex (3.1.3) Perl : /usr/bin/perl dblatex : /usr/bin/dblatex xsltproc : /usr/bin/xsltproc Using LLVM tools llc : /usr/bin/llc opt : /usr/bin/opt HsColour : /home/killy/.cabal/bin/HsColour Building DocBook HTML documentation : NO Building DocBook PS documentation : YES Building DocBook PDF documentation : YES }}} I'm setting the milestone to 7.10.1. It's annoying to have this feature of the build system broken and it would be great to have this fixed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9772> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #9600: Bad error message: Applicative is not a derivable class
by GHC 30 Jul '15

30 Jul '15

#9600: Bad error message: Applicative is not a derivable class -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- You have `GeneralizedNewtypeDeriving` on and use `deriving Applicative` with something that you cannot derive Applicative on, GHC correctly says `cannot eta-reduce the representation type enough`. If you don't have `GeneralizedNewtypeDeriving` on yet and deriving Applicative will work, GHC says something like "perhaps you want to enable GeneralizedNewtypeDeriving"? However, if you don't have `GeneralizedNewtypeDeriving` AND if GHC figures out that if you enable it, the next message will be `cannot eta-reduce the representation type enough`, then GHC will state the most unhelpful `Applicative is not a derivable class`, which suggests to me that '''in general''', Applicative is not derivable (which is wrong). rwbarton's suggestion: Suggest enabling `GeneralizedNewtypeDeriving` in any case and then let the user see why it cannot be derived. Some relevant #ghc chat: {{{ rwbarton, that's GND again rwbarton: I a ~ K a where K = ErrorT ImmError (ReaderT CliOptions (ReaderT Config IO)) is an instance of Applicative rwbarton: so it can coerce the instance for K to an instance for I nh2: so is it the error message that is the confusing part here? It suggests that "In general, Applicative is not derivable" nh2: I mean it as: Shouldn't it give an error message like "can't derive an Applicative instance in this case because ..."? rwbarton: well maybe it could add something like "Did you mean to use GeneralizedNewtypeDeriving?" rwbarton: oh I see what you mean, even if you turn that extension on it gives the same error message nh2: yes, because we already have such a message in some cases nh2: no, in this case I had really forgotten the extension. If I add it, I get the "cannot eta-reduce the representation type enough" error, but I haven't figured out why I get it in this case yet rwbarton: I wrote the condition above basically, "I a ~ K a where K = ... is an instance of Applicative" where ~ is the coercion/isomorphism introduced by the newtype rwbarton: if you can't write down K then you can't use GND because where would it get the instance? rwbarton: writing down K is eta reduction nh2: I'm wondering whether it doesn't suggest adding the extension because it already figured out I will not be able to eta-reduce? rwbarton: oh yeah, it seems so rwbarton: that seems a bit silly nh2: in this case, I think we should pimp the error message a bit nh2: (this is the thing I want to derive bwt: https://github.com /ganeti-github-testing/ganeti- test-1/blob/master/src/Ganeti/BasicTypes.hs#L147) nh2: what do you think would be the best error message to show in such a case? nh2: just suggest the GNTD suggestion regardless and let the user see afterwards that it cannot work? rwbarton: I would just have it always suggest GND ... yeah nh2: ok I file a ticket for that rwbarton: seems like more suggestions > fewer suggestions rwbarton: even if this is a weird second-order case where there are two errors }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9600> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8767: Add rules involving `coerce` to the libraries
by GHC 28 Jul '15

28 Jul '15

#8767: Add rules involving `coerce` to the libraries ------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: 8718 | Blocking: Related Tickets: #2110 | ------------------------------------+------------------------------------- With #2110 fixed, we can now add rules like {{{ {-# RULES "map/coerce" [0] map coerce = coerce #-} }}} to the standard libraries. But probably this should happen together or after #8718. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8767> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 27