October 2013 - ghc-tickets

[GHC] #8428: Incorrect type formatting in error messages
by GHC 10 Oct '13

10 Oct '13

#8428: Incorrect type formatting in error messages ------------------------------------+------------------------------------- Reporter: klao | 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: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I've been trying to write a type signature to something completely analogous to `runST . runIdentityT`, and failing miserably for a long time. At some point I had the following: {{{#!haskell {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ImpredicativeTypes #-} module Test where import Control.Monad.ST import Control.Monad.Trans.Identity runIdST :: IdentityT (forall s. ST s) a -> a runIdST = runST . runIdentityT }}} You can see that I was very confused about `forall` here (probably still am), but what makes it much worse is the error message with which this fails: {{{ src/Test.hs:10:19: Couldn't match type `forall s. ST s a' with `forall s. ST s a' Expected type: IdentityT (forall s. ST s) a -> forall s. ST s a Actual type: IdentityT (forall s. ST s) a -> forall s. ST s a In the second argument of `(.)', namely `runIdentityT' In the expression: runST . runIdentityT In an equation for `runIdST': runIdST = runST . runIdentityT }}} It says it couldn't match `forall s. ST s a` with `forall s. ST s a`. What's up with that?! This has lead me to a long diversion. Finally, we found the right type for this function (and discovered that the problem is also in the `(.)`, which doesn't have the same special treatment as `($)`), and afterwards we realized, that types in the above error message ''are'' actually different. One is `(forall s. (ST s)) a`, and the other is `forall s. ((ST s) a)`. But they are presented in exactly the same way! The issue is in the `instance Outputable Type`, which has too simplistic precedence rules, I guess. Thanks to `@errge` for help with debugging this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8428> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #7867: Allow template-haskell to communicate with itself between compilation units through the interface file
by GHC 09 Oct '13

09 Oct '13

#7867: Allow template-haskell to communicate with itself between compilation units through the interface file --------------------------+------------------------------------------------ Reporter: errge | Owner: Type: | Status: patch feature request | Milestone: 7.8.1 Priority: | Version: 7.6.3 normal | Keywords: Component: | Architecture: Unknown/Multiple Template Haskell | Difficulty: Easy (less than 1 hour) Resolution: | Blocked By: 3725, 8337, 8340, 8397, 8398 Operating System: | Related Tickets: Unknown/Multiple | Type of failure: | None/Unknown | Test Case: | Blocking: | --------------------------+------------------------------------------------ Comment (by errge): The wiki page is ready. http://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/Annotations All comments are welcome. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7867#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4385: Type-level natural numbers
by GHC 09 Oct '13

09 Oct '13

#4385: Type-level natural numbers --------------------------------------------+------------------------------ Reporter: diatchki | Owner: diatchki Type: feature request | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler (Type checker) | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by ghorn): * cc: gregmainland@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4385#comment:65> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8418: [patch] comments outdated
by GHC 09 Oct '13

09 Oct '13

#8418: [patch] comments outdated -------------------------------------------+------------------------------- Reporter: errge | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- During working on GHC, I found these outdated comments and function names. The ForPlugins renaming is DynamicLoading.hs is motivated by the fact that chnage 57d6798 crippled the function in a way that now it can only be used while handling Plugins. Therefore the name should warn the programmer to this fact. The hptInstances comment has also been outdated, when someone needed to add the `ModuleName -> Bool` predicate to use this same function for handling ghc and ghci with shared code. The attached patch is trivial renames/comments. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8418> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8223: System.Posix.User fails to build on systems without get{gr, pw}nam_r
by GHC 09 Oct '13

09 Oct '13

#8223: System.Posix.User fails to build on systems without get{gr,pw}nam_r ----------------------------------+---------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/unix | Version: 7.7 Keywords: | Operating System: Other Architecture: arm | Type of failure: Building GHC failed Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------------------- I'm trying to build GHC for Android (using https://github.com/neurocyte /ghc-android) and according to `include/HsUnixConfig.h` Android doesn't have any of the `_r` functions in the `get{gr,pw}*` family. In `System/Posix/User.hsc` the imports of `Control.Monad` and `System.IO.Error` are conditional on `defined(HAVE_GETGRNAM_R) || defined(HAVE_GETPWNAM_R)`, but the use site of those modules (`doubleAllocWhileERANGE`) was moved outside of any `#if`s by http://git.haskell.org/?p=packages/unix.git;a=commit;h=ef683c6ba703. I would suggest just removing the conditionals around the import of those two modules, since `doubleAllocWhileERANGE` is by now used by four other functions. Otherwise, need to bracket the definition of `doubleAllocWhileERANGE` with the same conditional as the one around those imports, and should update the conditionals to reflect all four cases in which `doubleAllocWhileERANGE` is used. (BTW, does Android count as "Operating System: Linux"? It is based on the Linux kernel, but with a rather peculiar user-space.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8223> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8408: Ambiguity in TH reify based on compilation method
by GHC 09 Oct '13

09 Oct '13

#8408: Ambiguity in TH reify based on compilation method ------------------------------------+------------------------------------- Reporter: errge | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | 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: | ------------------------------------+------------------------------------- The attached tar.gz contains a simple example where compiling with --make results in a different semantics than compiling all the modules with -c and then linking them together. This is shown by build.sh, so just start by running that. The ambiguity comes from the fact that the compiler is not starting the compilation of modules with a clean slate when using --make. This can be seen in compiler/iface/LoadIface.lhs line 276. I'm not sure if/how we should do anything about this urgently. Just wanted to note down this ambiguity, so we know it's there and can care about fixing it if we want to. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8408> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #7685: :script command does not resolve ~
by GHC 09 Oct '13

09 Oct '13

#7685: :script command does not resolve ~ -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: GHCi | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Joachim Breitner <mail@…>): In [changeset:"ddc79b229d58c1bed8ae19b955b491436e015e96/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="ddc79b229d58c1bed8ae19b955b491436e015e96" GHCi: Expand ~ in :script command Fixes: #7685 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7685#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7685: :script command does not resolve ~
by GHC 09 Oct '13

09 Oct '13

#7685: :script command does not resolve ~ -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: GHCi | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by thoughtpolice): Joachim, looks good to me. Please feel free to push it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7685#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8367: putStrLn and related printing functions don't output to MinTTY properly under Windows
by GHC 09 Oct '13

09 Oct '13

#8367: putStrLn and related printing functions don't output to MinTTY properly under Windows ------------------------------------+--------------------------------- Reporter: schyler | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+--------------------------------- One place where this glitch can be seen in `cabal update` by it *delaying* the term output until the update is finished and the program terminates. I've noticed it in several of my personal larger projects too. I think what's going on is that nothing is printed to the terminal until the program terminates. It seems to be intermittent to some degree, and varying the size and contents of the program can trigger it. Because of it's indeterminacy I can't actually provide a small test case, however, I can provide a program which currently does produce the issue. https://github.com/kvanberendonck/burrito/blob/ccd8d1fb2bb09251571cf2626314… -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8367> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #3553: parallel gc suffers badly if one thread is descheduled
by GHC 09 Oct '13

09 Oct '13

#3553: parallel gc suffers badly if one thread is descheduled -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.12.2 Component: Runtime System | Version: 6.10.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by parcs): Replying to [comment:13 simonmar]: > I'm very tempted to change the main thread to be non-bound. If so, would the earlier commits that helped mitigate this particular slowdown be undone? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3553#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0