March 2016 - ghc-tickets

[GHC] #11776: RTS segfaults when printing profiling information which refers to unloaded objects
by GHC 17 Apr '16

17 Apr '16

#11776: RTS segfaults when printing profiling information which refers to unloaded objects -------------------------------------+------------------------------------- Reporter: afarmer | Owner: afarmer Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.10.3 System (Linker) | 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: -------------------------------------+------------------------------------- Running a profiled binary which loads/unloads objects via the RTS's linker results in a CCS tree with pointers to the shared objects. These references are not checked by checkUnload before unloading the object. Then, when the profiling report is printed at the end of the program, a segfault occurs. Plan: 1. Add a test case for this. 2. Modify checkUnload to prevent objects from being unloaded if the CCS tree points to them. 3. Modify generateCCSReport to prune the CCS tree after a report is printed. 4. Expose some way to generate a report on demand, so long-running programs don't keep every object loaded forever. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11776> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10914: Bad symbol resolution on Darwin when using DYLD_FORCE_FLAT_NAMESPACE=1
by GHC 16 Apr '16

16 Apr '16

#10914: Bad symbol resolution on Darwin when using DYLD_FORCE_FLAT_NAMESPACE=1 -----------------------------------------+------------------------------- Reporter: jacereda | Owner: Type: bug | Status: new Priority: high | Milestone: Component: GHCi | Version: 7.10.2 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------------+------------------------------- Starting ghci as: {{{ env DYLD_FORCE_FLAT_NAMESPACE=1 ghci }}} can cause symbol resolution to fail. I tried with Data.Hashable as follows: {{{ import Data.Hashable main = putStrLn $ show $ hashWithSalt 0 "foo" }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10914> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #11318: Data.Text.length allocates one closure per character
by GHC 15 Apr '16

15 Apr '16

#11318: Data.Text.length allocates one closure per character -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: #11284 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In #11284 I noticed that `map Data.Text.length` applied to a list of `Text` values would result in code which would allocate one closure per character due to lack of lambda lifting. It turns out it's even worse than this. Consider this example (inspired by #11284), {{{#!hs module Hi2 (hello) where import qualified Data.Text as T hello :: Int hello = T.length hi hi :: T.Text hi = T.pack "hello" }}} When compiled with GHC 7.10.3 with `-O`, the following simplified Core is produced, {{{#!hs hello :: Int hello = case unpackCString# "hello"# of _ { Text dt_a33D dt1_a33E dt2_a33F -> let { a_a33C :: Int# a_a33C = +# dt1_a33E dt2_a33F } in letrec { $wloop_length_s3bt :: Int# -> Int# -> Int# $wloop_length_s3bt = \ (ww_s3bk :: Int#) (ww_s3bo :: Int#) -> case tagToEnum# @ Bool (>=# ww_s3bo a_a33C) of _ { False -> case indexWord16Array# dt_a33D ww_s3bo of r#_a35n { __DEFAULT -> case tagToEnum# @ Bool (geWord# r#_a35n (__word 55296)) of _ { False -> $wloop_length_s3bt (+# ww_s3bk 1) (+# ww_s3bo 1); True -> case tagToEnum# @ Bool (leWord# r#_a35n (__word 56319)) of _ { False -> $wloop_length_s3bt (+# ww_s3bk 1) (+# ww_s3bo 1); True -> $wloop_length_s3bt (+# ww_s3bk 1) (+# ww_s3bo 2) } } }; True -> ww_s3bk }; } in case $wloop_length_s3bt 0 dt1_a33E of ww_s3bs { __DEFAULT -> I# ww_s3bs } } }}} Even this simple example produces a `length` function which allocations -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11318> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11762: GHC 8 superclass chain constraint regression
by GHC 15 Apr '16

15 Apr '16

#11762: GHC 8 superclass chain constraint regression -------------------------------------+------------------------------------- Reporter: _deepfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 (Type checker) | 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: -------------------------------------+------------------------------------- It seems that GHC 8 regresses with regard to GHC 7.10, when it tries to satisfy the constraints, implied by instance context. The following does not build on GHC 8.0.1 RC2, but does on 7.10.3: {{{#!hs {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE UndecidableInstances #-} --{-# LANGUAGE UndecidableSuperClasses #-} -- this doesn't matter {-# LANGUAGE UnicodeSyntax #-} module Foo where class Super a class Super a ⇒ Left a class Super a ⇒ Right a instance (Left a) ⇒ Right a }}} the error being: > • Could not deduce (Super a) > arising from the superclasses of an instance declaration > from the context: Left a > bound by the instance declaration > at repro.hs:9:10-27 > Possible fix: > add (Super a) to the context of the instance declaration > • In the instance declaration for ‘Right a’ It also /roughly/ seems that https://phabricator.haskell.org/D1594 could possibly be related. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11762> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10318: Cycles in class declaration (via superclasses) sometimes make sense.
by GHC 13 Apr '16

13 Apr '16

#10318: Cycles in class declaration (via superclasses) sometimes make sense. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple (Type checker) | Type of failure: GHC rejects Keywords: | valid program Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I'd like to be able to say the following, to describe the notion of an integral domain in Haskell: {{{ -- | Product of non-zero elements always non-zero. -- Every integral domain has a field of fractions. -- The field of fractions of any field is itself. class (Frac (Frac a) ~ Frac a, Fractional (Frac a), IntegralDomain (Frac a)) => IntegralDomain a where type Frac a :: * embed :: a -> Frac a instance IntegralDomain Integer where type Frac Integer = Rational embed = fromInteger instance IntegralDomain Rational where type Frac Rational = Rational embed = id }}} But GHC gets scared when it sees the cyclic reference that `IntegralDomain` instances depend on an IntegralDomain superclass, which really is cyclic in the (Frac a) case here, and that is kind of the point. =) Right now the best approximation of the correct answer that I have for this situation is to lie and claim the constraint is weaker: {{{ -- | Product of non-zero elements always non-zero class (Frac (Frac a) ~ Frac a, Fractional (Frac a)) => AlmostIntegralDomain a where type Frac a :: * embed :: a -> Frac a class (AlmostIntegralDomain a, AlmostIntegralDomain (Frac a)) => IntegralDomain a instance (AlmostIntegralDomain a, AlmostIntegralDomain (Frac a)) => IntegralDomain a instance AlmostIntegralDomain Integer where type Frac Integer = Rational embed = fromInteger instance AlmostIntegralDomain Rational where type Frac Rational = Rational embed = id }}} Now the user is stuck defining a different class than the one they consume. Alternately, with `ConstraintKinds`, I can encode: {{{ data Dict p where Dict :: p => Dict p class (Frac (Frac a) ~ Frac a, Fractional (Frac a)) => IntegralDomain a where type Frac a :: * embed :: a -> Frac a proofFracIsIntegral :: p a -> Dict (IntegralDomain (Frac a)) default proofFracIsIntegral :: IntegralDomain (Frac a) => p a -> Dict (IntegralDomain (Frac a)) proofFracIsIntegral _ = Dict }}} but now whenever I need to get from `IntegralDomain a` to `IntegralDomain (Frac a)` I need to explicitly open the `proofFracIsIntegral` with a rats' nest of `ScopedTypeVariables`. It would be really really nice if I could get GHC to deal with this for me as I currently have a few thousand lines of code hacking around this limitation. =/ -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10318> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #11213: Incorrect reported pattern synonym signature
by GHC 12 Apr '16

12 Apr '16

#11213: Incorrect reported pattern synonym signature -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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: -------------------------------------+------------------------------------- {{{ data T where MkT :: (Show b) => b -> T --pattern ExNumPat :: () => Show b => b -> T pattern ExNumPat x = MkT x }}} GHC reports that `ExNumPat` is missing a signature (correctly) but it reports the wrong type. The correct type is the one commented out. {{{ pstest.hs:12:1: warning: Top-level binding with no type signature: ExNumPat :: forall b. Show b => b -> T }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11213> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10001: GHC crash trying to build a project within Nix-shell
by GHC 11 Apr '16

11 Apr '16

#10001: GHC crash trying to build a project within Nix-shell -------------------------------------+------------------------------------- Reporter: wolftune | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: 9825 Differential Revisions: | -------------------------------------+------------------------------------- {{{ <no location info>: ghc: panic! (the 'impossible' happened) (GHC version 7.8.4 for x86_64-unknown-linux): Loading temp shared object failed: /run/user/1000/ghc19915_0/ghc19915_20.so: failed to map segment from shared object Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug [20 of 99] Compiling Settings.StaticFiles ( Settings/StaticFiles.hs, dist/build/Settings/StaticFiles.o ) <no location info>: ghc: panic! (the 'impossible' happened) (GHC version 7.8.4 for x86_64-unknown-linux): Loading temp shared object failed: /run/user/1000/ghc19915_0/ghc19915_21.so: failed to map segment from shared object }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10001> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #11623: Wrong error message for type family definition that is wrong in multiple ways
by GHC 10 Apr '16

10 Apr '16

#11623: Wrong error message for type family definition that is wrong in multiple ways -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ GHCi, version 8.1.20160212: http://www.haskell.org/ghc/ :? for help Prelude> :set -XTypeFamilies Prelude> type family T where { Maybe T = Int } <interactive>:2:23: error: • Too many parameters to T: T is unexpected; expected only no parameters • In the type family declaration for ‘T’ }}} This error message is wrong ("Too many parameters to `T`"). Seems like GHC checks whether the equation `Maybe T = Int` has the right number of arguments before it checks whether it is actually headed by `T`. Then the error message is worded in a way that assumes the instance head actually was `T`. The 7.10 error message was better in this regard: {{{ <interactive>:3:23: Number of parameters must match family declaration; expected 0 In the type family declaration for ‘T’ }}} but it would be even better to generate the error below (that is generated once the number of arguments is correct) for the original program: {{{ Prelude> type family T a where { Maybe (T ()) = Int } <interactive>:5:25: error: • Mismatched type name in type family instance. Expected: T Actual: Maybe • In the type family declaration for ‘T’ }}} We should generate that error before kind-checking the definition too. I don't really understand the difference between these two cases though, so maybe my guess is wrong. {{{ Prelude> type family T where { T () = Int } <interactive>:10:23: error: • Too many parameters to T: () is unexpected; expected only no parameters • In the type family declaration for ‘T’ Prelude> type family T :: * -> * where { T () = Int } <interactive>:11:33: error: • Number of parameters must match family declaration; expected 0 • In the equations for closed type family ‘T’ In the type family declaration for ‘T’ }}} (As an aside, "expected only no parameters" is awkward, if there is some legitimate way to generate this message. It should just be "expected no parameters".) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11623> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11463: Template Haskell applies too many arguments to kind synonym
by GHC 10 Apr '16

10 Apr '16

#11463: Template Haskell applies too many arguments to kind synonym -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.0.1-rc1 Haskell | Keywords: TypeInType, | Operating System: Unknown/Multiple TypeApplications | Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: #11376 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Running the following code: {{{#!hs {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE TypeInType #-} module IdStarK where import Data.Kind import Language.Haskell.TH type Id a = a data Proxy (a :: Id k) = Proxy $(return []) main :: IO () main = do putStrLn $(reify ''Proxy >>= stringE . pprint) putStrLn $(reify ''Proxy >>= stringE . show) }}} Gives a result I wouldn't have expected: {{{ $ /opt/ghc/head/bin/runghc IdStarK.hs data IdStarK.Proxy (a_0 :: IdStarK.Id * k_1) = IdStarK.Proxy TyConI (DataD [] IdStarK.Proxy [KindedTV a_1627394516 (AppT (AppT (ConT IdStarK.Id) StarT) (VarT k_1627394515))] Nothing [NormalC IdStarK.Proxy []] []) }}} From the output, it appears that `Id` is being applied to ''two'' arguments, both `*` and `k`! Perhaps this indirectly (or directly) a consequence of #11376? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11463> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11680: Out-of-scope suggestion given for an out-of-scope variable when using TH
by GHC 10 Apr '16

10 Apr '16

#11680: Out-of-scope suggestion given for an out-of-scope variable when using TH -------------------------------------+------------------------------------- Reporter: jme | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- With GHC 8.x, compiling {{{#!hs {-# LANGUAGE TemplateHaskell #-} module A where import Language.Haskell.TH sep :: Q [Dec] sep = [d| x = () |] }}} and {{{#!hs {-# LANGUAGE TemplateHaskell #-} module B where import A f :: Int f = foo $(sep) foo :: Int foo = 3 }}} produces {{{ $ ghc-HEAD/inplace/bin/ghc-stage2 --version The Glorious Glasgow Haskell Compilation System, version 8.1.20160303 $ ghc-HEAD/inplace/bin/ghc-stage2 B.hs [1 of 2] Compiling A ( A.hs, A.o ) [2 of 2] Compiling B ( B.hs, B.o ) B.hs:8:5: error: • Variable not in scope: foo :: Int • Perhaps you meant ‘foo’ (line 13) }}} The problem is that when the typechecker constructs the suggestion, it uses the currently available `GlobalRdrEnv` rather than the one in existence when the renamer determined that `foo` is unbound. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11680> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10