September 2017 - ghc-tickets

[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] #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

[GHC] #14295: tagToEnum# leads to some silly closures
by GHC 17 Jun '18

17 Jun '18

#14295: tagToEnum# leads to some silly closures -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Keywords: datacon-tags | 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: -------------------------------------+------------------------------------- I don't know how important this is in practice, but it smells pretty silly. Suppose I write {{{#!hs foo :: (Bool -> a) -> Int# -> a foo f x = f (tagToEnum# x) }}} Since `tagToEnum#` can fail, GHC compiles this to {{{#!hs foo = \ (@ a_a10v) (f_s1by [Occ=Once!] :: GHC.Types.Bool -> a_a10v) (x_s1bz [Occ=Once] :: GHC.Prim.Int#) -> let { sat_s1bA [Occ=Once] :: GHC.Types.Bool [LclId] sat_s1bA = GHC.Prim.tagToEnum# @ GHC.Types.Bool x_s1bz } in f_s1by sat_s1bA }}} That seems pretty silly! We know that `tagToEnum#` is applied to `Bool`, so we can transform this to something like {{{#!hs foo f x = case x <=# 1# of 1# -> f $! tagToEnum# x _ -> f (error "tagToEnum# was used at Bool with tag ...") }}} which avoids an extra closure at the cost of a single `Int#` comparison. The same goes for arbitrary known enumeration types. I suspect the right place to fix this up is in CorePrep. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14295> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #12970: Add default implementation for Bits.bitSize
by GHC 17 Jun '18

17 Jun '18

#12970: Add default implementation for Bits.bitSize -------------------------------------+------------------------------------- Reporter: txnull | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: libraries/base | 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: -------------------------------------+------------------------------------- I think it would be a good idea to provide a default implementation for bitSize, example: {{{#!hs bitSize b = fromMaybe (error "bitSize is undefined") (bitSizeMaybe b) }}} The advantage is that from now on new instances of Bits no longer need to define bitSize. And once bitSize has been removed there will be no errors about it not being a method of class Bits. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12970> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23

[GHC] #13576: Runtime crashes on arm64 (iOS)
by GHC 16 Jun '18

16 Jun '18

#13576: Runtime crashes on arm64 (iOS) ----------------------------------------+---------------------------------- Reporter: jp.rider63 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+---------------------------------- I compiled GHC from source (ff84d052850b637b0) with a few modifications to create a cross-compiler for arm64. This was the configuration: {{{ CC=aarch64-apple-darwin14-clang ./configure --prefix=/usr/local/ghc-ios --target=aarch64-apple-darwin14 --disable-large-address-space --enable- bootstrap-with-devel-snapshot }}} Here's my "mk/build.mk": {{{ HADDOCK_DOCS=NO WITH_TERMINFO=NO DYNAMIC_BY_DEFAULT=NO DYNAMIC_GHC_PROGRAMS=NO DYNAMIC_TOO=NO }}} I used the stage1 compiler to export an arm64 library. The application (which links the library) crashes when run on my device (iOS 10.2.1). The application runs without issue on x86 and arm32. When I initialize with -DS, I get the following error: {{{ internal error: ASSERTION FAILED: file rts/sm/Sanity.c, line 88 (GHC version 8.3.20170408 for aarch64_apple_ios) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug // SIGABRT at line 182 in RtsMessages.c }}} To narrow down the offending code, I replaced all my functions with print statements and slowly added the functionality back until I could reproduce the crash. It looks like the crash happens around a call to this function: {{{ foreign export ccall hs_AAPublicKeyAlgorithm :: StablePtr AA.PublicKey -> IO CString hs_AAPublicKeyAlgorithm :: StablePtr AA.PublicKey -> IO CString hs_AAPublicKeyAlgorithm = hs_toAlgorithmIdentifier hs_toAlgorithmIdentifier :: (ToAlgorithm t a, AlgorithmId a) => StablePtr t -> IO CString hs_toAlgorithmIdentifier ptr = do algId <- fmap (toAlgorithmId . toAlgorithm) $ deRefStablePtr ptr newCString algId }}} Oddly, when I add print statements around this call, I get a EXC_BREAKPOINT instead of a SIGABRT. Here's the output for this case: {{{ ****************TEST************ ****************TEST************ ****************TEST************ ****************TEST************ v1K_FZuskg6Bkm-whFvkQ8IzHxnXDSGibCwbqZpM0fk= here ****************TEST************ here1 here2 }}} I've disabled dead code stripping. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13576> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12951: Remove __USE_MINGW_ANSI_STDIO define from PosixSource.h
by GHC 16 Jun '18

16 Jun '18

#12951: Remove __USE_MINGW_ANSI_STDIO define from PosixSource.h -------------------------------------+------------------------------------- Reporter: bgamari | Owner: 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: -------------------------------------+------------------------------------- This was a stop-gap measure to allow users to build GHC 8.2 with 7.10.1 and 7.10.2. It can be removed for 8.4. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12951> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14261: ghc stopped recognizing some arm triplets that used to work: Failed to lookup the datalayout for armv7a-hardfloat-linux-gnueabi; available targets:
by GHC 16 Jun '18

16 Jun '18

#14261: ghc stopped recognizing some arm triplets that used to work: Failed to lookup the datalayout for armv7a-hardfloat-linux-gnueabi; available targets: -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 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: -------------------------------------+------------------------------------- Build failure on current ghc-HEAD as: Build failure for armv7a-hardfloat-linux-gnueabi: {{{ Failed to lookup the datalayout for armv7a-hardfloat-linux-gnueabi; available targets: ["i386-unknown-windows","i686-unknown-windows","x86_64 -unknown-windows","arm-unknown-linux-gnueabihf","armv6-unknown-linux- gnueabihf","armv7-unknown-linux-gnueabihf","aarch64-unknown-linux- gnu","aarch64-unknown-linux","i386-unknown-linux-gnu","i386-unknown- linux","x86_64-unknown-linux-gnu","x86_64-unknown-linux","armv7-unknown- linux-androideabi","aarch64-unknown-linux-android","arm-unknown-nto-qnx- eabi","i386-apple-darwin","x86_64-apple-darwin","armv7-apple-ios","aarch64 -apple-ios","i386-apple-ios","x86_64-apple-ios"] }}} Build failure for armv7a-unknown-linux-gnueabi {{{ Failed to lookup the datalayout for armv7a-unknown-linux-gnueabi; available targets: ["i386-unknown-windows","i686-unknown-windows","x86_64 -unknown-windows","arm-unknown-linux-gnueabihf","armv6-unknown-linux- gnueabihf","armv7-unknown-linux-gnueabihf","aarch64-unknown-linux- gnu","aarch64-unknown-linux","i386-unknown-linux-gnu","i386-unknown- linux","x86_64-unknown-linux-gnu","x86_64-unknown-linux","armv7-unknown- linux-androideabi","aarch64-unknown-linux-android","arm-unknown-nto-qnx- eabi","i386-apple-darwin","x86_64-apple-darwin","armv7-apple-ios","aarch64 -apple-ios","i386-apple-ios","x86_64-apple-ios"] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14261> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12