- ghc-tickets - Haskell.org

[GHC] #12976: GHCi displays the kinds of unboxed tuples incorrectly
by GHC 15 Dec '16

15 Dec '16

#12976: GHCi displays the kinds of unboxed tuples incorrectly -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This can be reproduced in GHCi 8.0.2 or HEAD. First, a preamble: {{{ $ inplace/bin/ghc-stage2 --interactive GHCi, version 8.1.20161208: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> :set -fprint-explicit-runtime-reps -fprint-explicit-kinds -fprint- explicit-foralls -XUnboxedTuples -XTemplateHaskell -XMagicHash λ> :m + GHC.Exts Language.Haskell.TH Language.Haskell.TH.Lib Language.Haskell.TH.Syntax }}} The kind of `(#,#)` is reported correctly: {{{ (#,#) :: forall (k0 :: RuntimeRep) (k1 :: RuntimeRep). TYPE k0 -> TYPE k1 -> TYPE 'UnboxedTupleRep }}} But when you give it an argument, it seems to default `TYPE k1` to `*` for some reason! {{{ λ> :k (#,#) Int# (#,#) Int# :: * -> TYPE 'UnboxedTupleRep }}} This is a blatant lie, as this kind-checks: {{{ λ> :k (#,#) Int# Int# (#,#) Int# Int# :: TYPE 'UnboxedTupleRep }}} The effect is even more noticeable when you throw `TemplateHaskell` into the mix: {{{ λ> :k $(unboxedTupleT 2) $(unboxedTupleT 2) :: * -> * -> TYPE 'UnboxedTupleRep λ> :k $(unboxedTupleT 2) Int# $(unboxedTupleT 2) Int# :: * -> TYPE 'UnboxedTupleRep λ> :k $(conT (unboxedTupleTypeName 2)) $(conT (unboxedTupleTypeName 2)) :: * -> * -> TYPE 'UnboxedTupleRep λ> :k $(conT (unboxedTupleTypeName 2)) Int# $(conT (unboxedTupleTypeName 2)) Int# :: * -> TYPE 'UnboxedTupleRep }}} All of these kinds should be reporting the `RuntimeRep`s that GHC is //actually// using under the hood. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12976> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12832: GHC infers too simplified contexts
by GHC 15 Dec '16

15 Dec '16

#12832: GHC infers too simplified contexts -------------------------------------+------------------------------------- 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: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm almost sure it was working well in GHC 7.*. Let's consider this simple example: {{{ module Main where import Prelude class Monad m => Foo m class Monad m => Bar m class Monad m => Baz m data IM a data I impossible = error "impossible" class Test m a where test :: a -> m () instance {-# OVERLAPPABLE #-} (Foo m, Bar m, Baz m) => Test m a where test _ = return () instance {-# OVERLAPPABLE #-} Test IM a where test = impossible class Run m a where run :: a -> m () main :: IO () main = return () }}} it compiles and runs fine. What should happen when we add the following def? {{{ instance Run m Int where run = test }}} We SHOULD get an error that there is `No instance for (Test m Int) arising from a use of ‘test’`. Instead we get very strange one `No instance for (Foo m) arising from a use of ‘test’.` If we add it, we get the next one `No instance for (Bar m) arising from a use of ‘test’.` etc ... If we comment out the first overlappable instance, we get proper error about missing `Test m Int` context. In fact if we add context `Test m Int` it works in every case, only the inferred error is just wrong. This is a serious problem and here is why. Imagine that we create an API for end-user and we give him the `test` function. Moreover, we know that expanding the context would not bring any further info unless `m` is known. If we create such "impossible" instances like in the example, user will get a very simple error message about a missing context. Right now user gets a big error stack about missing expanded contexts instead of simple one. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12832> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12975: Suggested type signature for a pattern synonym causes program to fail to type check
by GHC 15 Dec '16

15 Dec '16

#12975: Suggested type signature for a pattern synonym causes program to fail to type check -------------------------------------+------------------------------------- Reporter: ocharles | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple patternsynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Take the following program: {{{#!hs {-# LANGUAGE ViewPatterns, PatternSynonyms, RankNTypes, GADTs #-} import Data.Typeable data T where MkT :: Typeable a => a -> T pattern Cast a <- MkT (cast -> Just a) }}} When compiled with `-Wall`, GHC rightly prompts about a missing signature on `Cast`: {{{ Top-level binding with no type signature: Cast :: forall b. Typeable b => forall a. Typeable a => b -> T }}} However, using this suggested type signature causes the program to fail to type check: {{{#!hs • Could not deduce (Typeable a0) arising from the "provided" constraints claimed by the signature of ‘Cast’ from the context: Typeable a bound by a pattern with constructor: MkT :: forall a. Typeable a => a -> T, in a pattern synonym declaration at ../foo.hs:9:19-38 In other words, a successful match on the pattern MkT (cast -> Just a) does not provide the constraint (Typeable a0) The type variable ‘a0’ is ambiguous • In the declaration for pattern synonym ‘Cast’ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12975> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12042: Infinite loop with type synonyms and hs-boot
by GHC 15 Dec '16

15 Dec '16

#12042: Infinite loop with type synonyms and hs-boot -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: hs-boot | Operating System: Unknown/Multiple backpack | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is a "known" bug, but the source code comment which mentioned this could happen didn't give a test case so I thought I'd supply one. {{{ -- A.hs-boot module A where data S type R = S -- B.hs module B (module A, module B) where import {-# SOURCE #-} A type U = S -- A.hs module A where import qualified B type S = B.R type R = B.U }}} When I try to build `A.hs` in one-shot I infinite loop: {{{ ezyang@sabre:~$ ghc-8.0 --make A.hs -fforce-recomp [1 of 3] Compiling A[boot] ( A.hs-boot, A.o-boot ) [2 of 3] Compiling B ( B.hs, B.o ) [3 of 3] Compiling A ( A.hs, A.o ) A.hs-boot:2:1: error: Type constructor ‘S’ has conflicting definitions in the module and its hs-boot file Main module: type S = R Boot file: abstract S ezyang@sabre:~$ ghc-8.0 -c A.hs -fforce-recomp ^C }}} The problem is that `-c` properly knot ties `data S` in the boot file to the local type synonym (`--make` is unaffected due to #12035), and then we have a type synonym loop which GHC doesn't catch early enough. `TcTyDecls.hs` has a nice comment which suggests that this is a known bug: {{{ Checking for class-decl loops is easy, because we don't allow class decls in interface files. We allow type synonyms in hi-boot files, but we *trust* hi-boot files, so we don't check for loops that involve them. So we only look for synonym loops in the module being compiled. We check for type synonym and class cycles on the *source* code. Main reasons: a) Otherwise we'd need a special function to extract type-synonym tycons from a type, whereas we already have the free vars pinned on the decl b) If we checked for type synonym loops after building the TyCon, we can't do a hoistForAllTys on the type synonym rhs, (else we fall into a black hole) which seems unclean. Apart from anything else, it'd mean that a type-synonym rhs could have for-alls to the right of an arrow, which means adding new cases to the validity checker Indeed, in general, checking for cycles beforehand means we need to be less careful about black holes through synonym cycles. The main disadvantage is that a cycle that goes via a type synonym in an .hi-boot file can lead the compiler into a loop, because it assumes that cycles only occur entirely within the source code of the module being compiled. But hi-boot files are trusted anyway, so this isn't much worse than (say) a kind error. }}} although the circumstances in this example are a little different. I take this bug as evidence that we should NOT attempt to knot-tie in this situation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12042> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #7206: Implement cheap build
by GHC 14 Dec '16

14 Dec '16

#7206: Implement cheap build -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by MikolajKonarski): * cc: MikolajKonarski (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7206#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3427: control what sort of entity a deprecated pragma applies to
by GHC 14 Dec '16

14 Dec '16

#3427: control what sort of entity a deprecated pragma applies to -------------------------------------+------------------------------------- Reporter: igloo | Owner: thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 6.10.4 Resolution: | Keywords: deprecate | warning Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: This won't happen for 8.2 although it would be great if someone could pick this up for 8.4. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3427#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7860: Add more bit fiddling functions to 'integer-gmp'
by GHC 14 Dec '16

14 Dec '16

#7860: Add more bit fiddling functions to 'integer-gmp' -------------------------------------+------------------------------------- Reporter: lebedev | Owner: hvr Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Core Libraries | Version: 7.6.3 Resolution: | Keywords: integer-gmp Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3489, #9835 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): Just for the record, I did start a couple months ago (http://git.haskell.org/ghc.git/shortlog/refs/heads/wip/T7860) before I shifted attention to more urgent tasks -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7860#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8440: Get rid of the remaining static flags
by GHC 14 Dec '16

14 Dec '16

#8440: Get rid of the remaining static flags -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: It is unlikely this will happen for 8.2. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8440#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7860: Add more bit fiddling functions to 'integer-gmp'
by GHC 14 Dec '16

14 Dec '16

#7860: Add more bit fiddling functions to 'integer-gmp' -------------------------------------+------------------------------------- Reporter: lebedev | Owner: hvr Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Core Libraries | Version: 7.6.3 Resolution: | Keywords: integer-gmp Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3489, #9835 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: It doesn't look like this will happen for 8.2. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7860#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9696: readRawBufferPtr and writeRawBufferPtr allocate memory
by GHC 14 Dec '16

14 Dec '16

#9696: readRawBufferPtr and writeRawBufferPtr allocate memory -------------------------------------+------------------------------------- Reporter: mergeconflict | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: x86_64 (amd64) | Unknown/Multiple Difficulty: Unknown | Type of failure: Runtime Blocked By: | performance bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I initially filed this as a [http://stackoverflow.com/questions/26333815 /why-do-hgetbuf-hputbuf-etc-allocate-memory question on StackOverflow], assuming that the behavior I'm seeing was intentional, or that I was misinterpreting the profiler results... but Kazu Yamamoto [https://twitter.com/kazu_yamamoto/status/522583112249663488 suggested] I should file this as an issue here. It's my first GHC ticket, so here goes: {{{#!hs main :: IO () main = do buf <- mallocArray 1 echo buf echo :: Ptr Word8 -> IO () echo buf = forever $ do len <- readRawBufferPtr "read" stdin buf 0 1 writeRawBufferPtr "write" stdout buf 0 (fromIntegral len) }}} I expect the only heap allocation here should be my explicit `mallocArray`, but profiling with `+RTS -P` indicates this isn't the case: both the read and write operations do appear to allocate some short-lived heap objects. In contrast: {{{#!hs echo :: Ptr Word8 -> IO () echo buf = forever $ do threadWaitRead $ Fd 0 len <- c_read 0 buf 1 c_write 1 buf (fromIntegral len) yield }}} does not appear to allocate. I did a bit of digging (copying bits of source code from `base` into my own project, to get cost center annotations) and it seems like the allocation might be happening in `throwErrnoIfRetryMayBlock`. See [https://gist.github.com/anonymous/3ba3cfa118e1d05870d4 this gist] for more detail, including core output from `-ddump-simpl`. In all honesty, I don't know whether this is a bug. I was just surprised by it, when I first encountered it using `hGetBuf` / `hPutBuf`, so I'm trying to understand whether this is expected behavior and why. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9696> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11