June 2013 - ghc-tickets

[GHC] #7842: Incorrect checking of let-bindings in recursive do
by GHC 21 Jun '13

21 Jun '13

#7842: Incorrect checking of let-bindings in recursive do --------------------------------------+------------------------------------- Reporter: diatchki | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC rejects valid program | Blockedby: Blocking: | Related: --------------------------------------+------------------------------------- I have run into a problem with the type-checking of recursive do blocks, which reduces to the following example: {{{ {-# LANGUAGE RecursiveDo #-} module Bug where bug :: (Int -> IO Int) -> IO (Bool, Char) bug m = mdo i <- m i1 -- RECURSION let i1 :: Int i1 = i -- RECURSION -- This appears to be monomorphic, despite the type signature. f :: b -> b f x = x return (f True, f 'a') }}} This program is rejected with the errors shown below. The problem appears to be that somehow `f` has become monomorphic, despite its type-signature. This seems to happen only when `f` is part of a `let` block that is also involved in the recursion. Here is the error reported by GHC 7.7.20130215: {{{ Bug.hs:15:23: Couldn't match expected type `Char' with actual type `Bool' In the return type of a call of `f' In the expression: f 'a' In the first argument of `return', namely `(f True, f 'a')' Bug.hs:15:25: Couldn't match expected type `Bool' with actual type `Char' In the first argument of `f', namely 'a' In the expression: f 'a' In the first argument of `return', namely `(f True, f 'a')' }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7842> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 2

[GHC] #8004: Applicative/Monad proposal related warnings (AMP phase 1)
by GHC 21 Jun '13

21 Jun '13

#8004: Applicative/Monad proposal related warnings (AMP phase 1) -----------------------------+---------------------------------------------- Reporter: quchen | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- Add ad-hoc warnings to GHC telling the user about the following:[[BR]] - Instance of `Monad` without instances of `Functor`/`Applicative`[[BR]] - Instance of `MonadPlus` without instance of `Alternative`[[BR]] - Module defines functions named `(<*>)`, `pure` or `join` Refactoring code to remove these warnings makes sure the AMP will not break the module in the future. Since they are basically meta- deprecations, I would suggest treating them similar to ordinary deprecations. This is part of phase 1 of the Applicative/Monad proposal (AMP), as discussed on the mailing lists [1]; a more detailed description of the AMP is available on the Wiki [2]. [1]: [http://article.gmane.org/gmane.comp.lang.haskell.libraries/19482] [2]: [http://www.haskell.org/haskellwiki/Functor-Applicative- Monad_Proposal] -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/8004> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #7713: Panic! make_exp (App _ (Coercion _)) when compiled with -fext-core
by GHC 21 Jun '13

21 Jun '13

#7713: Panic! make_exp (App _ (Coercion _)) when compiled with -fext-core -------------------------------+-------------------------------------------- Reporter: EduardSergeev | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: -fext-core panic Os: Linux | Architecture: x86_64 (amd64) Failure: Compile-time crash | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- An attempt to compile the attached file with 7.6.2 (and 7.4.2) with "-O2 -fext-core" leads to: ghc: panic! (the 'impossible' happened) (GHC version 7.6.2 for x86_64-unknown-linux): make_exp (App _ (Coercion _)) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7713> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 6

[GHC] #8001: Coercion causes "impossible" error
by GHC 21 Jun '13

21 Jun '13

#8001: Coercion causes "impossible" error -------------------------------+-------------------------------------------- Reporter: gridaphobe | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.3 | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: Compile-time crash | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- The following, heavily-redacted version of a function in `text` is causing GHC to die after reporting that the impossible happened. {{{ module Encoding where import Data.ByteString as B import Data.ByteString.Internal as B import Data.Text.Internal (Text(..), safe, textP) import Data.Word (Word8) import Foreign.C.Types (CSize) import Foreign.ForeignPtr (withForeignPtr, ForeignPtr) import Foreign.Ptr (Ptr, minusPtr, plusPtr) -- | Encode text using UTF-8 encoding. encodeUtf8 :: Text -> ByteString encodeUtf8 (Text arr off len) = inlinePerformIO $ do let size0 = max len 4 mallocByteString size0 >>= start size0 off 0 where -- start :: Int -> Int -> Int -> ForeignPtr Word8 -> IO ByteString start size n0 m0 fp = withForeignPtr fp $ go n0 m0 where offLen = off + len go n m ptr | n == offLen = return (PS fp 0 m) | otherwise = do let ensure k act | size-m >= k = act | otherwise = do let newSize = size fp' <- mallocByteString newSize start newSize n m fp' {-# INLINE ensure #-} ensure 4 $ return $ PS fp 0 m }}} {{{ $ ghc -fext-core Encoding.hs [1 of 1] Compiling Encoding ( Encoding.hs, Encoding.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-unknown-linux): make_exp (App _ (Coercion _)) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Note that it only happens when I try to make GHC output the Core, it will happily compile otherwise. The crash can also be prevented by uncommenting the type-annotation or removing the inline-annotation. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/8001> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #5630: External Core needs love
by GHC 21 Jun '13

21 Jun '13

#5630: External Core needs love ---------------------------------+------------------------------------------ Reporter: quux | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.2.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Compile-time crash Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown Comment: See also #7713, #8001. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5630#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8003: Add missing Applicative/Alternative instances (AMP phase 1)
by GHC 21 Jun '13

21 Jun '13

#8003: Add missing Applicative/Alternative instances (AMP phase 1) -----------------------------+---------------------------------------------- Reporter: quchen | Owner: Type: task | Status: new Priority: normal | Component: Compiler Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- Add Functor/Applicative/Alternative instances to GHC's source where they are missing to fit the new hierarchy, namely `Functor => Applicative => Monad` and `(Alternative, Monad) => MonadPlus`. (#4834 did something similar for a past GHC version, which is maybe helpful here.) This is part of phase 1 of the Applicative/Monad proposal (AMP), as discussed on the mailing lists [1]; a more detailed description of the AMP is available on the Wiki [2]. [1]: [http://article.gmane.org/gmane.comp.lang.haskell.libraries/19482] [2]: [http://www.haskell.org/haskellwiki/Functor-Applicative- Monad_Proposal] -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/8003> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #7167: Make it a warning (not error) to hide an import that isn't exported
by GHC 20 Jun '13

20 Jun '13

#7167: Make it a warning (not error) to hide an import that isn't exported ------------------------------------------+--------------------------------- Reporter: simonpj | Owner: igloo Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.4.2 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: rename/should_compile/T7167 | Blockedby: Blocking: | Related: ------------------------------------------+--------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => fixed Comment: The documentation patch from Paolo - commit 4eb02c1 - is already in HEAD and has been for a while. It might not have made it into the 7.6 branch unfortunately. I have added a blurb to the 7.8.1 release notes in commit 3b0225. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7167#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7167: Make it a warning (not error) to hide an import that isn't exported
by GHC 20 Jun '13

20 Jun '13

#7167: Make it a warning (not error) to hide an import that isn't exported ------------------------------------------+--------------------------------- Reporter: simonpj | Owner: igloo Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: rename/should_compile/T7167 | Blockedby: Blocking: | Related: ------------------------------------------+--------------------------------- Comment(by aseipp@…): commit 3b0225189402b3ecd66c9c9a9fa88aebfe914b8d {{{ Author: Austin Seipp <aseipp(a)pobox.com> Date: Thu Jun 20 18:22:48 2013 -0500 Document -fwarn-dodgy-imports changes in release notes. Trac #7167. Signed-off-by: Austin Seipp <aseipp(a)pobox.com> docs/users_guide/7.8.1-notes.xml | 7 +++++++ 1 files changed, 7 insertions(+), 0 deletions(-) }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7167#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7678: GHC should compile cleanly with clang
by GHC 20 Jun '13

20 Jun '13

#7678: GHC should compile cleanly with clang --------------------------------+------------------------------------------- Reporter: thoughtpolice | Owner: thoughtpolice Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: clang Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Building GHC failed | Blockedby: Blocking: 7602 | Related: --------------------------------+------------------------------------------- I'm running into several difficulties (which I'll catalog shortly) building GHC HEAD with Clang 3.2. These mostly seem to be difficulties relating to the preprocessor and the fact clang does not really respect ```-traditional-cpp``` mode, and that it is stricter than gcc about whitespace and whatnot too. This means code like: {{{ {-# RULES "thing" ... #-} }}} becomes invalid: ```clang``` is strict about the fact that preprocessor definitions must occur on the beginning of a line. There seems to be a bug in the preprocessor directive source code to this effect (that it doesn't handle whitespace before a directive.) It's quite unfortunate, because we do this a lot. This also causes build failures in the parser due to some crazy CPP hackery we do. I'll follow up with that shortly. As a workaround, we may have to force ```CPP``` to just continue being ```cpp``` which will Do The Right Thing, while ```CC``` will use ```clang``` instead. Or we'll have to have some script that seds whitespace out or something. This currently blocks #7602 since I can't test my fix otherwise. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7678> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 8

Re: [GHC] #7558: Terrible error message when given and wanted are both insoluble
by GHC 20 Jun '13

20 Jun '13

#7558: Terrible error message when given and wanted are both insoluble -------------------------------+-------------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: gadt/T7558 | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => gadt/T7558 * resolution: => fixed Comment: Good point. Thanks. Simon -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7558#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0