November 2017 - ghc-tickets

[GHC] #14462: deriving on associated data types fails to find constraints
by GHC 14 Nov '17

14 Nov '17

#14462: deriving on associated data types fails to find constraints -------------------------------------+------------------------------------- Reporter: mf825 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Type checker) | Keywords: TypeFamilies, | Operating System: Unknown/Multiple associated types, deriving | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE TypeFamilies, UndecidableInstances #-} class D a where data DT a class C a where data CT a instance (D a, Eq (DT a)) => C (Maybe a) where data CT (Maybe a) = CTMaybe (DT a) deriving (Eq) {- $ stack --resolver=nightly-2017-10-20 exec -- ghc --version The Glorious Glasgow Haskell Compilation System, version 8.2.1 $ stack --resolver=nightly-2017-10-20 exec -- ghci Main.hs GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help (0.00 secs, 0 bytes) (0.00 secs, 0 bytes) (0.00 secs, 0 bytes) (0.00 secs, 0 bytes) (0.00 secs, 0 bytes) (0.00 secs, 0 bytes) (0.00 secs, 0 bytes) (0.00 secs, 0 bytes) Loaded GHCi configuration from /home/mf/.ghci [1 of 1] Compiling Main ( Main.hs, interpreted ) Main.hs:7:48: error: • No instance for (Eq (DT a)) arising from the first field of ‘CTMaybe’ (type ‘DT a’) Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself • When deriving the instance for (Eq (CT (Maybe a))) | 7 | data CT (Maybe a) = CTMaybe (DT a) deriving (Eq) | ^^ Failed, 0 modules loaded. (0.03 secs,) Prelude> -- if i remove the offending @deriving@ clause above and add this line, everything is fine. -- use -XFlexibleInstances -XStandaloneDeriving for this. deriving instance Eq (DT a) => Eq (CT (Maybe a)) -} }}} checked on linux with ghc8.0.2 and 8.2.1. thanks! and sorry if i've missed a previous report covering this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14462> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #4815: Instance constraints should be used when deriving on associated data types
by GHC 14 Nov '17

14 Nov '17

#4815: Instance constraints should be used when deriving on associated data types -------------------------------------+------------------------------------- Reporter: batterseapower | Owner: (none) Type: feature request | Status: closed Priority: low | Milestone: Component: Compiler | Version: 6.12.3 Resolution: invalid | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12863, #14462 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => invalid * related: #12863 => #12863, #14462 Comment: I'm going to close this, since: 1. The consensus appears to be that this isn't desirable. 2. We're operating under this consensus in other tickets (see #14462, for example). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4815#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[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] #14458: ghc: panic! -- initTc: unsolved constraints
by GHC 13 Nov '17

13 Nov '17

#14458: ghc: panic! -- initTc: unsolved constraints -------------------------------------+------------------------------------- Reporter: lijero | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- So this is an interesting bug. If I mistype parse' as parse, /and/ do not have main defined, the error occurs, but not with either individual one. I'm sure the code sucks, but I wasn't intending for this to end up anywhere, it just happened to trigger the crash. {{{ lijero@desktop:~/code/ab$ ghc AB.hs [1 of 1] Compiling Main ( AB.hs, AB.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): initTc: unsolved constraints WC {wc_insol = [W] parse_ay8 :: t_ay7[tau:1] (CHoleCan: parse) [W] parse_ayp :: t_ayo[tau:1] (CHoleCan: parse)} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} {{{#!hs module Main where data Token = KUnit | KApp | KLam | KVar String data Ast = AUnit | AApp Ast Ast | ALam Ast Ast | AVar String parse' :: [Token] -> ([Token] -> Ast -> Maybe Ast) -> Maybe Ast parse' (KUnit:xs) fail = fail xs AUnit -- GHC does not crash when parse is correctly written parse' in both of the below instances parse' (KApp:xs) fail = parse' xs (\ xs' f -> AApp f <$> parse xs' fail) parse' (KLam:xs) fail = parse' xs (\ xs' a -> ALam a <$> parse xs' fail) parse' (KVar n:xs) fail = fail xs (AVar n) -- GHC does not crash when main is defined --main :: IO () --main = putStrLn "" }}} With main defined, GHC correctly reports "variable not in scope". With parse corrected to parse', GHC correctly reports that main is not defined. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14458> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #5889: -fno-prof-count-entries leads to linking errors
by GHC 13 Nov '17

13 Nov '17

#5889: -fno-prof-count-entries leads to linking errors -------------------------------------+------------------------------------- Reporter: akio | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: GHC rejects | Test Case: valid program | profiling/should_compile/T5889 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by duog): * testcase: => profiling/should_compile/T5889 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5889#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14457: Data family with non-Type return kind, can't figure out type despite annotating
by GHC 13 Nov '17

13 Nov '17

#14457: Data family with non-Type return kind, can't figure out type despite annotating -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #12369 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# Language KindSignatures, DataKinds, TypeFamilyDependencies, GADTs, TypeInType #-} import Data.Kind type family ToNat (n::Type) = (res :: Type) | res -> n where ToNat Type = Bool ToNat (Type -> Type) = Maybe Bool data family FN :: ToNat ty -> ty data instance FN :: Bool -> Type where F :: FN False T :: FN True data instance FN :: Maybe Bool -> (Type -> Type) where A :: FN (Nothing :: Maybe Bool) a B :: a -> FN (Just False) a C :: a -> a -> FN (Just True) a }}} works on GHC 8.3.20170920, but removing the annotation from `(Nothing :: Maybe Bool)` yields {{{ GHCi, version 8.3.20170920: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/Z.hs, interpreted ) /tmp/Z.hs:19:22: error: • Expected kind ‘ToNat (k0 -> *)’, but ‘Nothing’ has kind ‘Maybe a0’ • In the first argument of ‘FN’, namely ‘Nothing’ In the type ‘FN Nothing a’ In the definition of data constructor ‘A’ | 19 | A :: FN Nothing a | ^^^^^^^ Failed, 0 modules loaded. Prelude> }}} even though `FN` is annotated with the expected kind of `Nothing`: {{{#!hs data FN :: Maybe Bool -> ... where }}} can also be fixed by annotating `A :: FN Nothing (a::Type)`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14457> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[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

[GHC] #14425: approxRational is wrong when (rat - eps) overflows in negative direction
by GHC 12 Nov '17

12 Nov '17

#14425: approxRational is wrong when (rat - eps) overflows in negative direction -------------------------------------+------------------------------------- Reporter: danielk | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.2.1 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This program is wrong. The second output should be 0 % 1. {{{ import Data.Ratio main = do print (approxRational (0 % 1 :: Ratio Int) (1 % 10)) -- 0%1, correct print (approxRational (0 % 1 :: Ratio Word) (1 % 10)) -- 1%1, incorrect }}} The problem is that (rat-eps) overflows in the negative direction (see [http://hackage.haskell.org/package/base-4.10.0.0/docs/src/Data.Ratio.html#a… source]). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14425> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7