December 2016 - ghc-tickets

[GHC] #9890: RTS -qa option is helpful but under-documented
by GHC 15 Dec '16

15 Dec '16

#9890: RTS -qa option is helpful but under-documented -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | Documentation bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The entire documentation for the RTS `-qa` option is Use the OS's affinity facilities to try to pin OS threads to CPU cores. This is an experimental feature, and may or may not be useful. Please let us know whether it helps for you! It does help for us: enabling it on a multithreaded, moderately GC-heavy web server led to a sizeable improvement (~20%) in throughput benchmarks. However, it would be nice if the GHC documentation was a little more descriptive about what exactly this option does and how experimental it is now considered! (Relatedly, perhaps it would be worth adding a single index of RTS options in the user's guide, much like the flag reference for GHC itself.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9890> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

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

15 Dec '16

#8440: Get rid of the remaining static flags -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: task | Status: patch 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): Phab:D2839 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D2839 Comment: Yay, hsyl20 picked this up! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8440#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12977: Template Haskell: unboxedTupleTypeName doesn't handle unboxed 0- and 1-tuples
by GHC 15 Dec '16

15 Dec '16

#12977: Template Haskell: unboxedTupleTypeName doesn't handle unboxed 0- and 1-tuples -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.0.1 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC has a notion of unboxed 0-tuples and 1-tuples: {{{ λ> :set -XUnboxedTuples λ> :k (##) (##) :: TYPE 'GHC.Types.VoidRep λ> :k (# Int #) (# Int #) :: TYPE 'GHC.Types.UnboxedTupleRep }}} But it is impossible to acquire the `Name`s of these type constructors using `unboxedTupleTypeName` from `template-haskell`: {{{ λ> :set -XTemplateHaskell λ> :m + Language.Haskell.TH Language.Haskell.TH.Syntax λ> :k $(conT (unboxedTupleTypeName 0)) <interactive>:1:1: error: • Exception when trying to run compile-time code: unboxedTupleTypeName 0 CallStack (from HasCallStack): error, called at libraries/template- haskell/Language/Haskell/TH/Syntax.hs:1179:26 in template- haskell:Language.Haskell.TH.Syntax Code: conT (unboxedTupleTypeName 0) • In the untyped splice: $(conT (unboxedTupleTypeName 0)) λ> :k $(conT (unboxedTupleTypeName 1)) <interactive>:1:1: error: • Exception when trying to run compile-time code: unboxedTupleTypeName 1 CallStack (from HasCallStack): error, called at libraries/template- haskell/Language/Haskell/TH/Syntax.hs:1180:26 in template- haskell:Language.Haskell.TH.Syntax Code: conT (unboxedTupleTypeName 1) • In the untyped splice: $(conT (unboxedTupleTypeName 1)) }}} And similarly for `unboxedTupleDataName`. This is because of [http://git.haskell.org/ghc.git/blob/9c9a2229fe741c55a8fb8d0c6380ec066a77722… /template-haskell/Language/Haskell/TH/Syntax.hs#l1184 silly restrictions] put in place on the definitions of `unboxedTupleTypeName` and `unboxedTupleDataName` within `template-haskell`: {{{#!hs -- Unboxed tuple data and type constructors -- | Unboxed tuple data constructor unboxedTupleDataName :: Int -> Name -- | Unboxed tuple type constructor unboxedTupleTypeName :: Int -> Name unboxedTupleDataName 0 = error "unboxedTupleDataName 0" unboxedTupleDataName 1 = error "unboxedTupleDataName 1" unboxedTupleDataName n = mk_unboxed_tup_name (n-1) DataName unboxedTupleTypeName 0 = error "unboxedTupleTypeName 0" unboxedTupleTypeName 1 = error "unboxedTupleTypeName 1" unboxedTupleTypeName n = mk_unboxed_tup_name (n-1) TcClsName }}} It should be possible to lift this restriction. I'll work on this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12977> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #7289: Mingw FPU init not Windows compatible.
by GHC 15 Dec '16

15 Dec '16

#7289: Mingw FPU init not Windows compatible. -------------------------------------+------------------------------------- Reporter: Lennart | Owner: Phyx- Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 7.2.2 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2819 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7289#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10614: Show constraints in ``Found hole...''
by GHC 15 Dec '16

15 Dec '16

#10614: Show constraints in ``Found hole...'' -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Currently it is not clear when types are known equal. Consider writing castWith: {{{#!hs {-# LANGUAGE GADTs , TypeOperators #-} import Data.Type.Equality hiding (castWith) castWith :: a :~: b -> a -> b castWith Refl x = _ }}} which results in {{{ TypeEq.hs:5:19: error: Found hole: _ :: b Where: ‘b’ is a rigid type variable bound by the type signature for: castWith :: a :~: b -> a -> b at TypeEq.hs:4:13 Relevant bindings include x :: a (bound at TypeEq.hs:5:15) castWith :: a :~: b -> a -> b (bound at TypeEq.hs:5:1) In the expression: _ In an equation for ‘castWith’: castWith Refl x = _ }}} Filling the hole with x is correct, but it is not clear from the message that GHC knows this. It would be useful to have a section "Constraints include" e.g. {{{ TypeEq.hs:5:19: error: Found hole: _ :: b Where: ‘b’ is a rigid type variable bound by the type signature for: castWith :: a :~: b -> a -> b at TypeEq.hs:4:13 Relevant bindings include x :: a (bound at TypeEq.hs:5:15) castWith :: a :~: b -> a -> b (bound at TypeEq.hs:5:1) Constraints include <------ NEW LINE a ~ b (from Refl :: a :~: a at TypeEq.hs:5:10) <------ NEW LINE In the expression: _ In an equation for ‘castWith’: castWith Refl x = _ }}} And show class constraints (Show a etc.) similarly -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10614> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

Re: [GHC] #7289: Mingw FPU init not Windows compatible.
by GHC 15 Dec '16

15 Dec '16

#7289: Mingw FPU init not Windows compatible. -------------------------------------+------------------------------------- Reporter: Lennart | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 7.2.2 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2819 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"6f7d8279cea4aa1082fb07adf5da507297e21ee8/ghc" 6f7d827/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6f7d8279cea4aa1082fb07adf5da507297e21ee8" Reset FPU precision back to MSVCRT defaults Mingw-w64 does a stupid thing. They set the FPU precision to extended mode by default. The reasoning is that it's for compatibility with GNU Linux ported libraries. However the problem is this is incompatible with the standard Windows double precision mode. In fact, if we create a new OS thread then Windows will reset the FPU to double precision mode. So we end up with a weird state where the main thread by default has a different precision than any child threads. Test Plan: ./validate new test T7289 Reviewers: simonmar, austin, bgamari, erikd Reviewed By: simonmar Subscribers: thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D2819 GHC Trac Issues: #7289 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7289#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[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