October 2017 - ghc-tickets

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

21 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

Re: [GHC] #7258: Compiling DynFlags is jolly slow
by GHC 21 Nov '17

21 Nov '17

#7258: Compiling DynFlags is jolly slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving-perf Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by tdammers): * Attachment "ghc-large-record-types.png" removed. Profile samples for W2.hs-style record types, comparing GHC performance for just the raw record type, derived Read, derived Show, and a hand- written getLine-based applicative record construction function. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7258> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 101

[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 19 Nov '17

19 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 18 Nov '17

18 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] #14353: PowerPC: HEAD validate fails due to warnings in libffi
by GHC 16 Nov '17

16 Nov '17

#14353: PowerPC: HEAD validate fails due to warnings in libffi --------------------------------+---------------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Keywords: | Operating System: Unknown/Multiple Architecture: powerpc | Type of failure: Building GHC failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+---------------------------------------- Validate produces the following error message: {{{ In file included from rts/dist/build/ffi.h:58:0: error: 0, from rts/Adjustor.c:46: rts/dist/build/ffitarget.h:157:7: error: error: "FFI_TYPE_LAST" is not defined [-Werror=undef] #if !(FFI_TYPE_LAST == FFI_PPC_TYPE_LAST \ }}} and a few more like this. Perhaps, we could turn off the warning for files that include `ffi.h` on PowerPC. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14353> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

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

14 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] #14311: PowerPC: Symbol already defined
by GHC 12 Nov '17

12 Nov '17

#14311: PowerPC: Symbol already defined --------------------------------+---------------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Keywords: | Operating System: Unknown/Multiple Architecture: powerpc | Type of failure: Building GHC failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+---------------------------------------- Building HEAD I get the following error from the stage 1 compiler: {{{ /tmp/ghc9106_0/ghc_4.s:796:0: error: Error: symbol `.Lc2l' is already defined | 796 | .Lc2l: | ^ `gcc' failed in phase `Assembler'. (Exit code: 1) rts/ghc.mk:269: recipe for target 'rts/dist/build/Exception.o' failed }}} The relevant assembly code is: {{{ .section ".opd","aw" .align 3 .LcV: .quad ..LcV,.TOC.@tocbase,0 .previous .type .LcV, @function ..LcV: .LcV: ld 31, 8(22) }}} Note: The label has changed during recompile. This affects powerpc64 (ELF 1.9) and powerpc64le (ELF 2.0) on Linux and I suspect also AIX. This could be a fallout from: changeset:8b007abbeb3045900a11529d907a835080129176 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14311> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

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

12 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