March 2018 - ghc-tickets

[GHC] #13709: Drop GCC Driver
by GHC 18 Jun '18

18 Jun '18

#13709: Drop GCC Driver ----------------------------------------+--------------------------------- Reporter: Phyx- | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- The original reason for the Windows GCC driver was to correct hard-coded paths in the GCC build from the `msys` project. The `msys2` builds we now exclusively use no longer have these issues. Which means 90% of the reason for the driver is gone. Given the recent issues with the driver. We can/should simplify things and drop it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13709> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #13280: Consider deriving more Foldable methods
by GHC 18 Jun '18

18 Jun '18

#13280: Consider deriving more Foldable methods -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- We currently derive `foldMap` and `foldr`, but some others may deserve attention as well. * The most critical spots are probably `length` and `null`. Deriving these instead of using the defaults can change the orders of growth! Given `data Tree a = Bin !(Tree a) a !(Tree a) | Tip`, we surely don't want `null` to traverse the whole spine of the tree when it's quite immediately obvious that `Bin` is never null. And if a constructor contains a type with a very efficient `length` or `null` implementation (e.g., one that stores its own size), we certainly want to use that. * `foldl` typically ends up with rather different code than `foldr` (for a recursive type) even after simplification. We need to check whether this has a performance impact, but my bet is that it will in cases where the optimizer can't understand what's going on well enough. * `foldl'` and `foldr'` are a bit tricky. Ideally, if we have something like `data T a = C (G a) a | ...` then we'd like to be able to use `G`'s `foldl'` definition to define `T`'s. Unfortunately, different types in the wild have different `foldl'` semantics (and indeed the semantics for `[]` changed by mistake fairly recently). So we have to decide to what extent the derived semantics should depend on the choices of included types. I think we should probably just depend, because that seems likely what people will expect and want. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13280> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14978: GADTs don't seem to unpack properly
by GHC 18 Jun '18

18 Jun '18

#14978: GADTs don't seem to unpack properly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider this simple code: {{{#!hs type family Foo a b data Goof a b where Goof :: !(Foo a b :~: Int) -> Goof a b }}} `(:~:)` has just one constructor (`Refl`) with no arguments, so I'd expect it to unpack to a void representation: {{{#!hs GoofConstr :: Foo a b ~N# Int => Goof a b WGoof :: Foo a b :~: Int -> Goof a b WGoof eq = case eq of Refl -> GoofConstr }}} But it doesn't seem to unpack at all. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14978> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14904: Compiler panic (piResultTy)
by GHC 18 Jun '18

18 Jun '18

#14904: Compiler panic (piResultTy) -------------------------------------+------------------------------------- Reporter: kcsongor | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: 14873 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Type-checking the following type family {{{#!hs type family F (f :: forall a. g a) :: Type where F (f :: forall a. g a) = Int }}} panics with the message: {{{#!txt ghc: panic! (the 'impossible' happened) (GHC version 8.4.0.20180118 for x86_64-apple-darwin): piResultTy k_aVM[tau:1] a_aVF[sk:1] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:950:35 in ghc:Type }}} The panic happens with HEAD, 8.4 and 8.2. 8.0 rejects the program with an error message, but even it panics on the following version: {{{#!hs type family F f :: Type where F ((f :: forall a. g a) :: forall a. g a) = Int }}} #14873 seemed somewhat related, so I tried with the patch implemented in 3d252037234ce48f9bdada7d5c9b1d8eba470829, but that fails with the same panic too. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14904> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #14845: TypeInType, index by GADT witnessing constraint
by GHC 18 Jun '18

18 Jun '18

#14845: TypeInType, index by GADT witnessing constraint -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.5 Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Just wondering if it would ever make sense to allow or use constraints like this {{{#!hs {-# Language PolyKinds, DataKinds, KindSignatures, GADTs, TypeInType, ConstraintKinds #-} import Data.Kind data Struct :: (k -> Constraint) -> (k -> Type) where S :: cls a => Struct cls a data Foo a where F :: Foo (S::Struct Eq a) }}} {{{ $ ghci -ignore-dot-ghci /tmp/test.hs GHCi, version 8.5.20180105: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/test.hs, interpreted ) /tmp/test.hs:9:13: error: • Illegal constraint in a type: cls0 a0 • In the first argument of ‘Foo’, namely ‘(S :: Struct Eq a)’ In the type ‘Foo (S :: Struct Eq a)’ In the definition of data constructor ‘F’ | 9 | F :: Foo (S::Struct Eq a) | ^ Failed, no modules loaded. Prelude> }}} Please close the ticket if it doesn't -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14845> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #14487: Can't Hide Field When DuplicateRecordFields Is Enabled
by GHC 18 Jun '18

18 Jun '18

#14487: Can't Hide Field When DuplicateRecordFields Is Enabled -------------------------------------+------------------------------------- Reporter: iansullivan88 | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Linux DuplicateRecordFields | Architecture: x86_64 | Type of failure: GHC rejects (amd64) | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- A.hs fails to compile when DuplicateRecordFields is enabled in B.hs. A.hs {{{#!hs module A where import B hiding (duplicateName) test = X duplicateName duplicateName = 5 }}} B.hs {{{#!hs {-# LANGUAGE DuplicateRecordFields #-} module B where data X = X { duplicateName :: Int } }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14487> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14005: Explore moving from pretty to prettyprinter
by GHC 18 Jun '18

18 Jun '18

#14005: Explore moving from pretty to prettyprinter -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 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: | wiki:PrettyErrors -------------------------------------+------------------------------------- GHC has for a long time used the `pretty` library for pretty-printing. However, for a number of reasons (explained in wiki:PrettyErrors) it leaves some things to be desired. The `prettyprinter` library is a performant, well-supported alternative that looks quite promising. Explore moving to `prettyprinter` -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14005> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #9106: GHC Panic related to functional dependencies - kindFunResult
by GHC 18 Jun '18

18 Jun '18

#9106: GHC Panic related to functional dependencies - kindFunResult ----------------------------+--------------------------------------- Reporter: yuriy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+--------------------------------------- Minimal example: {{{ {-# LANGUAGE MultiParamTypeClasses, DataKinds, FunctionalDependencies, TypeOperators, KindSignatures, PolyKinds, FlexibleInstances, FlexibleContexts, UndecidableInstances #-} import GHC.TypeLits data Proxy (a :: k) = Proxy class FunctorN n f a fa | n f a -> fa where fmapn :: Proxy n -> Proxy f -> (a -> a) -> fa -> fa instance FunctorN 0 f a a where fmapn _ _ a = a instance (Functor f, FunctorN (n - 1) f a fa) => FunctorN n f a (f fa) where fmapn _ pf f = fmap (fmapn (Proxy :: Proxy (n-1)) pf f) }}} Crashes with ghc and ghci: {{{ >ghc test [1 of 1] Compiling Main ( test.hs, test.o ) ghc.exe: panic! (the 'impossible' happened) (GHC version 7.8.20140130 for x86_64-unknown-mingw32): kindFunResult k{tv azb} [sk] >ghci test GHCi, version 7.8.20140130: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Main ( test.hs, interpreted ) ghc.exe: panic! (the 'impossible' happened) (GHC version 7.8.20140130 for x86_64-unknown-mingw32): kindFunResult k{tv aPm} [sk] }}} Removing the functional dependency makes the code compile. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9106> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #13895: "Illegal constraint in a type" error - is it fixable?
by GHC 17 Jun '18

17 Jun '18

#13895: "Illegal constraint in a type" error - is it fixable? -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: TypeInType | 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 recently sketched out a solution to #13327. Here is the type signature that I wanted to write: {{{#!hs dataCast1 :: forall (c :: Type -> Type) (t :: forall (k :: Type). k -> Type). Typeable t => (forall d. Data d => c (t d)) -> Maybe (c a) }}} But this doesn't typecheck: {{{ • Could not deduce (Typeable (t k0)) from the context: (Data a, Typeable (t k)) bound by the type signature for: dataCast1 :: forall a. Data a => forall k (c :: * -> *) (t :: forall k1. k1 -> *). Typeable (t k) => (forall d. Data d => c (t * d)) -> Maybe (c a) at NewData.hs:(170,3)-(173,26) The type variable ‘k0’ is ambiguous • In the ambiguity check for ‘dataCast1’ To defer the ambiguity check to use sites, enable AllowAmbiguousTypes When checking the class method: dataCast1 :: forall a. Data a => forall k (c :: * -> *) (t :: forall k1. k1 -> *). Typeable (t k) => (forall d. Data d => c (t * d)) -> Maybe (c a) In the class declaration for ‘Data’ | 170 | dataCast1 :: forall (c :: Type -> Type) (t :: forall (k :: Type). k -> Type). | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^... }}} This makes sense, since GHC has no way to conclude that the `k` in `t`'s kind is also `Typeable`. I tried to convince GHC of that fact: {{{#!hs dataCast1 :: forall (c :: Type -> Type) (t :: forall (k :: Type). Typeable k => k -> Type). Typeable t => (forall d. Data d => c (t d)) -> Maybe (c a) }}} But this also doesn't work: {{{ NewData.hs:171:25: error: • Illegal constraint in a type: Typeable k0 • In the first argument of ‘Typeable’, namely ‘t’ In the type signature: dataCast1 :: forall (c :: Type -> Type) (t :: forall (k :: Type). Typeable k => k -> Type). Typeable t => (forall d. Data d => c (t d)) -> Maybe (c a) In the class declaration for ‘Data’ | 171 | Typeable t | ^ NewData.hs:172:40: error: • Illegal constraint in a type: Typeable k0 • In the first argument of ‘c’, namely ‘(t d)’ In the type signature: dataCast1 :: forall (c :: Type -> Type) (t :: forall (k :: Type). Typeable k => k -> Type). Typeable t => (forall d. Data d => c (t d)) -> Maybe (c a) In the class declaration for ‘Data’ | 172 | => (forall d. Data d => c (t d)) | ^^^ }}} At this point, I'm stuck, since I have no idea how to work around this `Illegal constraint in a type` error. This error message appears to have originated as a part of the `TypeInType` patch, since there's even a [http://git.haskell.org/ghc.git/blob/58c781da4861faab11e4c5804e07e6892908ef7… test case] checking for this behavior. But is this a fundamental limitation of kind equalities? Or would it be possible to lift this restriction? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13895> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #8619: Support anonymous string literals in C-- (OR) give better ASSERT failure messages in C--
by GHC 17 Jun '18

17 Jun '18

#8619: Support anonymous string literals in C-- (OR) give better ASSERT failure messages in C-- ------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- So if I say "foobar" in C--, it turns into: {{{ section "rodata" { fresh_name : bits8[] "foobar\0"; } }}} This would let us fix the ASSERT macro in Cmm.h to also get the filename. Requires parser changes. Alternatively, we can redefine the ASSERT macro per C-- file to have a hardcoded filename with some preprocessor trickery. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8619> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9