September 2017 - ghc-tickets

[GHC] #12159: Record-like GADTs with repeated fields (of same type) rejected
by GHC 22 Nov '17

22 Nov '17

#12159: Record-like GADTs with repeated fields (of same type) rejected -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I came across a curious bug with record-like GADTs and repeated fields. Consider following code: {{{#!hs {-# LANGUAGE GADTs #-} data Foo p where Bar :: { quux' :: Bool } -> Foo Char Baz :: { quux'' :: Bool } -> Foo Int quux :: Foo p -> Bool quux (Bar q) = q quux (Baz q) = q quuxSetter :: Foo p -> Bool -> Foo p quuxSetter old@Bar{} q = old{quux' = q} quuxSetter old@Baz{} q = old{quux'' = q} }}} This compiles and all is fine. *But* GHC is supposed to create the nice `quux` and `quuxSetter` accessors for me, right? So, let's try: {{{#!hs data Foo p where Bar :: { quux :: Bool } -> Foo Char Baz :: { quux :: Bool } -> Foo Int }}} It does not compile! Instead I get: {{{ T12159.hs:3:1: error: Constructors Bar and Baz have a common field quux , but have different result types In the data type declaration for Foo Failed, modules loaded: none. }}} This is not very polite :-) It should simply create the accessors like I did above. It obviously can be done! Testcase is attached. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12159> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #14257: Heap profiling with ghc and hp2ps and strict function application ($!) gives samples out of sequence (regression)
by GHC 22 Nov '17

22 Nov '17

#14257: Heap profiling with ghc and hp2ps and strict function application ($!) gives samples out of sequence (regression) -------------------------------------+------------------------------------- Reporter: carlostome | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.2.1 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #14006 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following program generates an invalid .hp file when compiled with ghc 8.2.1 but it does not when using ghc 8.0.2. {{{#!hs {-# LANGUAGE ScopedTypeVariables #-} module Main where eval :: forall a b. (a -> b -> b) -> b -> [a] -> b eval f b xs = load xs [] where load :: [a] -> [a] -> b load [] stk = unload b stk load (x:xs) stk = load xs (x : stk) unload :: b -> [a] -> b unload v [] = v unload v (x : stk) = unload ((f $! x) $! v) stk main :: IO () main = print (eval (||) False (True : replicate 10000000 False)) }}} If strict application ($!) is substituted for normal application ($) or removed then the .hp generated file is correct. For reproducing the error: {{{ ghc -O2 --make -prof -fprof-auto Example.hs -fforce-recomp ./Example +RTS -hc hp2ps -e8in -c Example.hp }}} It outputs: {{{ hp2ps: Example.hp, line 43, samples out of sequence }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14257> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #11721: GADT-syntax data constructors don't work well with TypeApplications
by GHC 20 Nov '17

20 Nov '17

#11721: GADT-syntax data constructors don't work well with TypeApplications -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple TypeApplications | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider {{{ data X a where MkX :: b -> Proxy a -> X a }}} According to the rules around specified vs. generalized variables around `TypeApplications`, the type of `MkX` should be {{{ MkX :: forall {k} (b :: *) (a :: k). b -> Proxy a -> X a }}} A few things to note: * The `k` isn't available for `TypeApplications` (that's why it's in braces), because it is not user-written. * The `b` is quantified before the `a`, because `b` comes before `a` in the user-written type signature for `MkX`. Both of these bullets are currently violated. GHCi reports `MkX`'s type as {{{ MkX :: forall k (a :: k) b. b -> Proxy a -> X a }}} It turns out that this is a hard to fix. The problem is that GHC expects data constructors to have their universal variables followed by their existential variables, always. And yet that's violated in the desired type for `MkX`. Furthermore, given the way that GHC deals with GADT return types ("rejigging", in technical parlance), it's inconvenient to get the specified/generalized distinction correct. Given time constraints, I'm afraid fixing this all won't make it for 8.0. Happily, there is are easy-to-articulate rules governing GHC's current (wrong) behavior. In a GADT-syntax data constructor: * All kind and type variables are considered specified and available for visible type application. * Universal variables always come first, in precisely the order they appear in the tycon. Note that universals that are constrained by a GADT return type are missing from the datacon. * Existential variables come next. Their order is determined by a user- written `forall`; or, if there is none, by taking the left-to-right order in the datacon's type and doing a stable topological sort. (This stable topological sort step is the same as for other user-written type signatures.) Despite the existence of these rules, it would still be better not to have special rules for GADT-syntax data constructors. This ticket is intended to capture that eventual goal. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11721> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #9118: Can't eta-reduce representational coercions
by GHC 19 Nov '17

19 Nov '17

#9118: Can't eta-reduce representational coercions ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | 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: | ------------------------------------+------------------------------------- When I say {{{ import Data.Type.Coercion import Data.Coerce import Data.Proxy eta2 :: Coercible (f a) (g a) => Proxy a -> Coercion f g eta2 _ = Coercion }}} I get {{{ Could not coerce from ‘f’ to ‘g’ because ‘f’ and ‘g’ are different types. arising from a use of ‘Coercion’ from the context (Coercible (f a) (g a)) bound by the type signature for eta2 :: Coercible (f a) (g a) => Proxy a -> Coercion f g at /Users/rae/temp/Roles.hs:5:9-56 In the expression: Coercion In an equation for ‘eta2’: eta2 _ = Coercion }}} Unlike the case for #9116, this one is ''not'' expressible in Core. (At least, I don't see a way to do it.) So, to do this, we would have to update Core and then update the constraint solver. I ''do'' think this would be type safe. But, I also think it's reasonable to wait for someone with a real use case to shout before doing this. The only use case I have is to be able to do this: {{{ -- says that a's parameter is representational class Rep (a :: k1 -> k2) where co :: Coercible x y => Coercible (a x) (a x) instance Rep f => Rep (Compose f) where ... }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9118> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #11392: Decide and document how semicolons are supposed to work in GHCi
by GHC 18 Nov '17

18 Nov '17

#11392: Decide and document how semicolons are supposed to work in GHCi -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: GHCi | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #10663 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently there is a fair bit of confusion surrounding the intended function of semicolons in GHCi (see #10663 and Phab:D1726), * the users guide doesn't discuss the matter at all * sometimes the content after semicolons work as expected {{{ λ> let x=2; y=5 λ> x+y 7 }}} * other times it is silently ignored (see #10663), {{{ λ> import Data.List; 684 λ> }}} * other times it works but the parser state is subtly wrong, resulting in (arguably) incorrect line numbers later in the session, {{{ λ> data Infix a b = a :@: b; infixl 4 :@: λ> a <interactive>:3:1: error: Variable not in scope: a }}} * some times the only way to accomplish a given task is with a semicolon, {{{ Prelude> data Infix a b = a :@: b; infixl 4 :@: -- this is OK, but: Prelude> data Infix a b = a :@: b Prelude> infixl 4 :@: <interactive>:12:10: error: The fixity signature for `:@:' lacks an accompanying binding (The fixity signature must be given where `:@:' is declared) }}} This inconsistency is surprising and at times frustrating. Let's decide how we want semicolons to work and stick with it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11392> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14255: Type-indexed type fingerprints
by GHC 17 Nov '17

17 Nov '17

#14255: Type-indexed type fingerprints -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Core | Version: 8.2.1 Libraries | Keywords: Typeable | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have the feeling that it might well be possible to reduce the size of the trusted codebase somewhat by introducing type-indexed fingerprints. Imagine {{{#!hs data TypeRep (a :: k) where TrTyCon :: {-# UNPACK #-} !FingerprintIx a -> !TyCon -> [SomeTypeRep] -> TypeRep (a :: k) TrApp :: forall k1 k2 (a :: k1 -> k2) (b :: k1). {-# UNPACK #-} !FingerprintIx (a b) -> TypeRep (a :: k1 -> k2) -> TypeRep (b :: k1) -> TypeRep (a b) TrFun :: forall (r1 :: RuntimeRep) (r2 :: RuntimeRep) (a :: TYPE r1) (b :: TYPE r2). {-# UNPACK #-} !FingerprintIx (a -> b) -> TypeRep a -> TypeRep b -> TypeRep (a -> b) }}} We could have some primitive operations like {{{#!hs mkFunFP :: FingerPrintIx a -> FingerPrintIx b -> FingerPrintIx (a -> b) mkAppFP :: FingerPrintIx (a -> b) -> FingerPrintIx a -> FingerPrintIx b eq :: FingerPrintIx a -> FingerPrintIx b -> Maybe (a :~~: b) eqE :: FingerPrintIx a -> FingerPrintIx b -> Either (a :~~: b -> c) (a :~~: b) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14255> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14168: Installing math-functions with GHC-8.2.1 on windows crashed
by GHC 13 Nov '17

13 Nov '17

#14168: Installing math-functions with GHC-8.2.1 on windows crashed -------------------------------------+------------------------------------- Reporter: Qinka | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I use the ghc-8.2.1 in Windows. When install math-functions, ghc crash. The following is the output. {{{ λ stack install math-functions math-functions-0.2.1.0: configure math-functions-0.2.1.0: build -- While building package math-functions-0.2.1.0 using: C:\sr\setup-exe-cache\x86_64-windows\Cabal- simple_Z6RU0evB_2.0.0.2_ghc-8.2.1.exe --builddir=.stack-work\dist\e53504d9 build --ghc-options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 255 Logs have been written to: A:\Glob\.stack-work\logs\math- functions-0.2.1.0.log Configuring math-functions-0.2.1.0... Preprocessing library for math-functions-0.2.1.0.. Building library for math-functions-0.2.1.0.. [ 1 of 10] Compiling Numeric.MathFunctions.Comparison ( Numeric\MathFunctions\Comparison.hs, .stack- work\dist\e53504d9\build\Numeric\MathFunctions\Comparison.o ) [ 2 of 10] Compiling Numeric.MathFunctions.Constants ( Numeric\MathFunctions\Constants.hs, .stack- work\dist\e53504d9\build\Numeric\MathFunctions\Constants.o ) [ 3 of 10] Compiling Numeric.Polynomial ( Numeric\Polynomial.hs, .stack-work\dist\e53504d9\build\Numeric\Polynomial.o ) [ 4 of 10] Compiling Numeric.Polynomial.Chebyshev ( Numeric\Polynomial\Chebyshev.hs, .stack- work\dist\e53504d9\build\Numeric\Polynomial\Chebyshev.o ) [ 5 of 10] Compiling Numeric.RootFinding ( Numeric\RootFinding.hs, .stack-work\dist\e53504d9\build\Numeric\RootFinding.o ) [ 6 of 10] Compiling Numeric.Series ( Numeric\Series.hs, .stack- work\dist\e53504d9\build\Numeric\Series.o ) [ 7 of 10] Compiling Numeric.SpecFunctions.Internal ( Numeric\SpecFunctions\Internal.hs, .stack- work\dist\e53504d9\build\Numeric\SpecFunctions\Internal.o ) C:\Users\qinka\AppData\Local\Temp\stack12716\math- functions-0.2.1.0\Numeric\SpecFunctions\Internal.hs:24:1: warning: [-Wunused-imports] The import of 鈥榚xpm1鈥?from module 鈥楪HC.Float鈥?is redundant | 24 | import GHC.Float (log1p,expm1) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [ 8 of 10] Compiling Numeric.SpecFunctions.Extra ( Numeric\SpecFunctions\Extra.hs, .stack- work\dist\e53504d9\build\Numeric\SpecFunctions\Extra.o ) [ 9 of 10] Compiling Numeric.SpecFunctions ( Numeric\SpecFunctions.hs, .stack-work\dist\e53504d9\build\Numeric\SpecFunctions.o ) [10 of 10] Compiling Numeric.Sum ( Numeric\Sum.hs, .stack- work\dist\e53504d9\build\Numeric\Sum.o ) ghc.EXE: internal error: mkPath failed converting char* to wchar_t* (GHC version 8.2.1 for x86_64_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14168> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9052: Support a "stable heap" which doesn't get garbage collected
by GHC 13 Nov '17

13 Nov '17

#9052: Support a "stable heap" which doesn't get garbage collected ----------------------------------------------+---------------------------- Reporter: ezyang | Owner: Type: feature request | simonmar Priority: normal | Status: new Component: Runtime System | Milestone: Keywords: | Version: 7.9 Architecture: Unknown/Multiple | Operating System: Difficulty: Moderate (less than a day) | Unknown/Multiple Blocked By: | Type of failure: Related Tickets: | None/Unknown | Test Case: | Blocking: ----------------------------------------------+---------------------------- Simon Marlow was explaining the concept on IRC. The problem we're trying to solve is you might have some very long-lived pointer data-structures, and you don't want to waste time traversing this structure on a major GC when you know that it is still going to be alive. Here's the basic idea: 1. We have a new generation on the heap called the 'stable heap' (along- side the nursery, gen0, gen1, etc). By default, no objects are automatically promoted from the old gen to the stable heap. 2. A user can request an object be moved to the stable heap, creating a stable pointer which points to the object. 3. During garbage collection, all blocks in the stable heap are always considered reachable. We don't include the stable pointers in the root set (so we don't trace the stable heap), however, write barriers are processed as usual, and we promote any objects pointed to by the stable heap to the stable heap. 4. Users manually request the stable heap to be garbage-collected, usually after deallocating stable pointers. In short, the stable heap is just another generation, but one which (1) is only collected by user request, and (2) never receives objects from automatic promotion. This project fits in very nicely with the existing GC infrastructure, so if you understand how everything is laid out this should be reasonably easy to implement. Could be a good ticket for someone who wants to get their hands dirty with the GC. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9052> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13990: Core Lint error on empty case
by GHC 11 Nov '17

11 Nov '17

#13990: Core Lint error on empty case -------------------------------------+------------------------------------- Reporter: mbieleck | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc3 Keywords: core-lint | Operating System: Unknown/Multiple case | Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This module: {{{#!hs {-# LANGUAGE EmptyCase #-} module Bug where data Void absurd :: Void -> a absurd v = case v of {} data Foo = Foo !Void absurdFoo :: Foo -> a absurdFoo (Foo x) = absurd x }}} Compiled using `ghc-8.2.0.20170704 -O -dcore-lint Bug.hs` Gives the following error: {{{ [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) *** Core Lint errors : in result of Simplifier *** <no location info>: warning: In a case alternative: (Foo x_ap6 :: Void) No alternatives for a case scrutinee in head-normal form: x_ap6 *** Offending Program *** absurd :: forall a. Void -> a [LclIdX, Arity=1, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=1,unsat_ok=True,boring_ok=True)}] absurd = \ (@ a_apU) (v_ap5 :: Void) -> case v_ap5 of { } absurdFoo :: forall a. Foo -> a [LclIdX, Arity=1, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=1,unsat_ok=True,boring_ok=True)}] absurdFoo = \ (@ a_apY) (ds_dUn :: Foo) -> case ds_dUn of { Foo x_ap6 -> case x_ap6 of { } } -- irrelevant stuff omitted }}} When I manually inline `absurd` or remove the strictness annotation on `Foo`, the error goes away. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13990> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #9420: Impredicative type instantiation without -XImpredicativeTypes
by GHC 11 Nov '17

11 Nov '17

#9420: Impredicative type instantiation without -XImpredicativeTypes -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Consider this module: {{{ {-# LANGUAGE RankNTypes #-} module Bug where rank2 :: ((forall a. a -> a) -> b) -> () rank2 _ = () foo :: () -> () foo x = x quux :: (forall a. a -> a) -> Int quux _ = 5 bar = foo . rank2 $ quux }}} The `(.)` in the definition of `bar` requires an impredicative instantiation -- that is, one of its type variables is instantiated to a forall-type. Yet, the module compiles without `-XImpredicativeTypes`. To confirm this behavior, the following is an excerpt from `-ddump-simpl`: {{{ Bug.bar = break<7>() (break<6>() GHC.Base.. @ () @ () @ ((forall a_a1Tj. a_a1Tj -> a_a1Tj) -> GHC.Types.Int) Bug.foo (Bug.rank2 @ GHC.Types.Int)) Bug.quux }}} Note the third type argument to `(.)`. Fixing this would be a breaking change that could affect users. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9420> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4