- ghc-tickets - Haskell.org

[GHC] #15050: ScopedTypeVariables could allow more programs
by GHC 18 Aug '18

18 Aug '18

#15050: ScopedTypeVariables could allow more programs -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- Consider {{{ data P a = P data T1 a where MkT1 :: forall a. P a -> T1 a MkT2 :: forall a. P a -> T1 (a,a) MkT3 :: forall a b. b ~ Int => P a -> P b -> T1 a MkT4 :: forall a b. P a -> P b -> T1 a MkT5 :: forall a b c. b ~ c => P a -> P b -> P c -> T1 a }}} I can write this function {{{ foo :: T1 (Int, Int) -> () foo (MkT1 (P::P (Int,Int))) = () foo (MkT2 (P::P x)) = (() :: x ~ Int => ()) foo (MkT3 P (P::P Int)) = () foo (MkT4 P (P::P b)) = () foo (MkT5 P (P::P b) (P::P b)) = () }}} but this these two equations fail {{{ foo (MkT1 (P::P (Int,x))) = (() :: x ~ Int => ()) foo (MkT1 (P::P x)) = (() :: x ~ (Int,Int) => ()) }}} I am especially surprised by the second one, given that the very similar equation with `MkT2` works. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15050> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 25

[GHC] #15537: Panic when building Crucible
by GHC 18 Aug '18

18 Aug '18

#15537: Panic when building Crucible -------------------------------------+------------------------------------- Reporter: siddharthist | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I've encountered a panic, which GHC has asked me to report: {{{ [19 of 21] Compiling Lang.Crucible.LLVM.Translation ( src/Lang/Crucible/LLVM/Translation.hs, dist/build/Lang/Crucible/LLVM/Translation.p_o ) <no location info>: error: ghc: panic! (the 'impossible' happened) (GHC version 8.4.3 for x86_64-unknown-linux): isUnliftedType r_a4Zsg :: TYPE rep_a4Zsf Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1939:10 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} This was when compiling [https://github.com/GaloisInc/crucible/tree/master /crucible-llvm crucible-llvm] revision 186mfb7wlz with GHC 8.4.3. I'm building in Nix with a sandbox, so this should be easily reproducible. The Nix files are available here: https://github.com/siddharthist/galois- haskell-nix/tree/ghc-bug. Just run nix-build -A haskellPackages.crucible- llvm. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15537> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15490: Can Template Haskell and RULES be combined?
by GHC 18 Aug '18

18 Aug '18

#15490: Can Template Haskell and RULES be combined? -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- It would be nice if there was something like this: {{{#!hs {-# RULES "(literal*)" forall n. (n*) = $( makeOptimizedMultiplication [|| n ||] ) #-} }}} where `makeOptimizedMultiplication` is a Template Haskell function that, if `n` is an integer literal, produces an optimized multiplication function for that literal. However, that code above gives a `VarE` corresponding to the `n` in the quoter rather than the AST of the `n` that's actually being matched by the rewrite rule, so I can't get a `LitE` that way. This sort of thing would come in very handy for a large fixed-width integer type, because I don't think GHC and LLVM will know that standard fixed-width integer optimizations apply to it. For example, with a `Word65536` type, multiplying blindly at runtime by the literal `1099511627777` requires a lot of extra work. At the very least, all 65536 bits of that literal have to be read and dealt with pretty blindly. However, at compile time, the compiler can take the time to figure out that `(1099511627777*)` can be replaced with the much, much lighter `(\x -> shiftL x 40 + x)` (and not only that, but if `Word65536`s are stored in a byte array, 1 byte evenly divides the shift amount of 40 bits, which can be exploited to speed things up greatly). With appropriate `RULES` and Template Haskell functions, the compiler gains the ability to apply lots of fixed-width integer optimizations. Since the above sort of code doesn't work, is there some other way to do this that I don't know about? If not, can the feature be added? ---- The only downside I can think of is that the user of the `Word65536` type might not knowingly be expecting Template Haskell to be at work since they didn't use any splices or quoters and might not have even included `{-# LANGUAGE TemplateHaskell #-}` in their code, so perhaps some easy method of consenting to the application of TH-based rewrites might be in order. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15490> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15532: Relaxing Levity-Polymorphic Binder Check for Lifted vs Unlifted pointers
by GHC 17 Aug '18

17 Aug '18

#15532: Relaxing Levity-Polymorphic Binder Check for Lifted vs Unlifted pointers -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple LevityPolymorphism | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: 14917 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm going to define two terms that I will use with these meanings for the remainder of this post. 1. Runtime-Rep Polymorphism: full polymorphism in the runtime representation 2. Levity Polymorphism: polymorphism dealing with lifted vs unlifted types that are definitely represented by pointers. GHC's levity polymorphism has the restriction that runtime-rep-polymorphic binders are not allowed. A comment David made recently on https://github.com/haskell/primitive/issues/198 got me thinking about the possibility of relaxing this restriction when it comes to dealing with a function with levity-polymorphic (not runtime-rep-polymorphic) binders. GHC's runtime already appears to allow doing this. AndrasKovacs writes on https://www.reddit.com/r/haskell/comments/6v9rmg/an_unified_array_interface… that he is able to store both lifted and unlifted values inside of the same `Array#` (pointing out as well that their primop implementations are identical) without crashing the GC. As further evidence that we can, roughly speaking, use lifted and unlifted values in the same places, I threw together a little experiment: {{{ {-# LANGUAGE MagicHash #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeInType #-} import Data.Primitive import Data.Primitive.UnliftedArray import GHC.Types import GHC.Exts main :: IO () main = do a@(Array myArr) <- newArray 1 ("foo" :: String) >>= unsafeFreezeArray UnliftedArray myArrArr <- newUnliftedArray 1 a >>= unsafeFreezeUnliftedArray putStrLn (myFunc show (2 :: Integer)) putStrLn (myFunc2 (\x -> show (Array x)) myArr) putStrLn (myBigFunc (+1) show show (2 :: Integer)) putStrLn (myBigFunc2 (\x -> array# (indexUnliftedArray (UnliftedArray x) 0 :: Array String)) (\x -> show (Array x)) (\x -> show (UnliftedArray x :: UnliftedArray (Array String))) myArrArr) {-# NOINLINE myFunc #-} myFunc :: (a -> String) -> a -> String myFunc f a = let x = f a in x ++ x myFunc2 :: forall (a :: TYPE 'UnliftedRep). (a -> String) -> a -> String myFunc2 = unsafeCoerce# myFunc {-# NOINLINE myBigFunc #-} myBigFunc :: (a -> b) -> (b -> String) -> (a -> String) -> a -> String myBigFunc f g h a = let y = f a x = g y in x ++ x ++ h a myBigFunc2 :: forall (a :: TYPE 'UnliftedRep) (b :: TYPE 'UnliftedRep). (a -> b) -> (b -> String) -> (a -> String) -> a -> String myBigFunc2 = unsafeCoerce# myBigFunc }}} The compiles (surprisingly without a core lint error) and runs fine. So, here's the idea. We start with David's suggested change to `RuntimeRep`: {{{ data RuntimeRep = PtrRep Levity | ... data Levity = Lifted | Unlifted }}} And then we change the check that disallows runtime-rep polymorphism in binding positions to accept levity polymorphism in binding positions (but continuing to reject runtime-rep polymorphism). For example, the two examples in the above code snippet would be rewritten as: {{{ myFunc :: forall (v :: Levity) (a :: TYPE ('PtrRep v)). (a -> String) -> a -> String myFunc = ... -- same implementation myBigFunc :: forall (v :: Levity) (w :: Levity) (a :: TYPE ('PtrRep v)) (b :: TYPE ('PtrRep w)). (a -> b) -> (b -> String) -> (a -> String) -> a -> String myBigFunc = ... -- same implementation }}} Again, GHC's runtime seems to already allow this. It's just the type system that's missing support for it. The only weird thing I can think of that comes up is that you cannot use bang patterns on a levity-polymorphic argument since unlifted values cannot be entered. I think it is possible to go a little further still. Fields of data types could be levity polymorphic: {{{ data List (a :: TYPE ('PtrRep v)) = Cons a (List a) | Nil map :: forall (v :: Levity) (w :: Levity) (a :: TYPE ('PtrRep v)) (b :: TYPE ('PtrRep w)). (a -> b) -> List a -> List b }}} Again, bang patterns would need to be forbidden on such fields. This doesn't get us everything sought out in https://ghc.haskell.org/trac/ghc/wiki/UnliftedDataTypes, but it's kind of a half-way point that requires no changes to GHC's runtime and no changes to code generation. I think the whole thing can be handled in the type checker. Other potential application: `Array#` and `ArrayArray#` (and nearly all functions that operate on them) could be consolidated into a single type, reducing the number of duplicated primop implementations in GHC. Of course this would all need to be a GHC proposal, but I wanted to first solicit some feedback here on initial draft of the idea. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15532> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #15524: Performance regression when using the GHC API to evaluate code compared to 8.4
by GHC 17 Aug '18

17 Aug '18

#15524: Performance regression when using the GHC API to evaluate code compared to 8.4 -------------------------------------+------------------------------------- Reporter: vaibhavsagar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1-beta1 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: -------------------------------------+------------------------------------- I've been in the process of updating IHaskell to support GHC 8.6 and the test suite has become agonisingly slow as compared to GHC 8.4 and below. I've been able to work around this by using `--enable-executable-dynamic` as suggested by `christiaanb` on `#ghc`but I thought this was worth reporting as a bug. I am using `ghc-8.6.1-alpha2` so it's possible that this has been fixed in `beta1`. To reproduce this on a Linux installation with Nix: 1. `git clone https://github.com/gibiansky/IHaskell --branch support- ghc-8-6 repro` 2. `cd repro` 3. Comment out `--enable-executable-dynamic` in `release-8.6.nix` 4. `nix-build release-8.6.nix` -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15524> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #15531: CApiFFI generates bad prototypes for pointers of `Foreign.C` types
by GHC 17 Aug '18

17 Aug '18

#15531: CApiFFI generates bad prototypes for pointers of `Foreign.C` types -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- Consider the example {{{#!hs {-# LANGUAGE CApiFFI #-} module Foo where import Foreign.Ptr import Foreign.C foreign import capi unsafe "foo.h fn1" c_fn1 :: Char -> IO Char foreign import capi unsafe "foo.h fn2" c_fn2 :: Ptr Char -> IO (Ptr Char) foreign import capi unsafe "foo.h fn3" c_fn3 :: Ptr (Ptr Char) -> IO (Ptr (Ptr Char)) foreign import capi unsafe "foo.h fn4" c_fn4 :: CChar -> IO CChar foreign import capi unsafe "foo.h fn5" c_fn5 :: Ptr CChar -> IO (Ptr CChar) foreign import capi unsafe "foo.h fn6" c_fn6 :: Ptr (Ptr CChar) -> IO (Ptr (Ptr CChar)) foreign import capi unsafe "foo.h fn7" c_fn7 :: CUChar -> CSChar -> CShort -> CUShort -> CInt -> CUInt -> CLong -> CULong -> CSize -> IO () foreign import capi unsafe "foo.h fn8" c_fn8 :: Ptr CUChar -> Ptr CSChar -> Ptr CShort -> Ptr CUShort -> Ptr CInt -> Ptr CUInt -> Ptr CLong -> Ptr CULong -> Ptr CSize -> IO () }}} which creates various wrappers; this generates the C wrapper {{{#!c #define IN_STG_CODE 0 #include "Rts.h" #include "Stg.h" #ifdef __cplusplus extern "C" { #endif #include "foo.h" void ghczuwrapperZC0ZCmainZCFooZCfn8(void* a1, void* a2, void* a3, void* a4, void* a5, void* a6, void* a7, void* a8, void* a9) {fn8(a1, a2, a3, a4, a5, a6, a7, a8, a9);} #include "foo.h" void ghczuwrapperZC1ZCmainZCFooZCfn7(HsWord8 a1, HsInt8 a2, HsInt16 a3, HsWord16 a4, HsInt32 a5, HsWord32 a6, HsInt64 a7, HsWord64 a8, HsWord64 a9) {fn7(a1, a2, a3, a4, a5, a6, a7, a8, a9);} #include "foo.h" void** ghczuwrapperZC2ZCmainZCFooZCfn6(void** a1) {return fn6(a1);} #include "foo.h" void* ghczuwrapperZC3ZCmainZCFooZCfn5(void* a1) {return fn5(a1);} #include "foo.h" HsInt8 ghczuwrapperZC4ZCmainZCFooZCfn4(HsInt8 a1) {return fn4(a1);} #include "foo.h" HsChar** ghczuwrapperZC5ZCmainZCFooZCfn3(HsChar** a1) {return fn3(a1);} #include "foo.h" HsChar* ghczuwrapperZC6ZCmainZCFooZCfn2(HsChar* a1) {return fn2(a1);} #include "foo.h" HsChar ghczuwrapperZC7ZCmainZCFooZCfn1(HsChar a1) {return fn1(a1);} #ifdef __cplusplus } #endif }}} Specifically, the wrappers for `c_fn4`, `c_fn5` and `c_fn8` are wrong. This is quite a serious bug as it renders `CApiFFI` unusable for matching with C prototypes, as modern C compilers will refuse to coerce a pointer `void**` into an argument to a function expecting a `char**`. One concrete example is e.g. {{{#!hs -- int getfilecon(const char *path, char **con); foreign import capi safe "selinux/selinux.h getfilecon" c_getfilecon' :: CString -> Ptr CString -> IO CInt }}} which even though properly declared (NB: `type CString = Ptr CChar`), when compiled would fail because of this bug: {{{ tmpdir/ghc31009_0/ghc_2.c: In function ‘ghczuwrapperZC0ZCmainZCBarZCgetfilecon’: tmpdir/ghc31009_0/ghc_2.c:8:92: error: warning: passing argument 2 of ‘getfilecon’ from incompatible pointer type [-Wincompatible-pointer-types] HsInt32 ghczuwrapperZC0ZCmainZCBarZCgetfilecon(void* a1, void** a2) {return getfilecon(a1, a2);} ^ | 8 | HsInt32 ghczuwrapperZC0ZCmainZCBarZCgetfilecon(void* a1, void** a2) {return getfilecon(a1, a2);} | ^ In file included from tmpdir/ghc31009_0/ghc_2.c:7:0: error: /usr/include/selinux/selinux.h:101:12: error: note: expected ‘char **’ but argument is of type ‘void **’ extern int getfilecon(const char *path, char ** con); ^ | 101 | extern int getfilecon(const char *path, char ** con); | ^ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15531> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15493: Elide empty dictionaries
by GHC 17 Aug '18

17 Aug '18

#15493: Elide empty dictionaries -------------------------------------+------------------------------------- Reporter: mnoonan | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- Suppose you define a type class `C` with no methods, and use it as a constraint on a function `f :: C => Foo`. GHC's generated Core for `f` currently passes an empty dictionary for `C`. With optimizations, it seems to be true that at use sites, calls to `f` will be replaced with calls to an inner function that skips the typeclass dictionary. But can I count on this optimization always working? Would it possible to get a guarantee that the `C =>` constraint will have no run-time overhead, by dropping it entirely from the generated Core? Or is there a subtlety that prevents this from being sound? For context, I would like to implicitly pass compile-time evidence that various properties hold (e.g. such-and-such a list is non-empty), while retaining a guarantee that the evidence will have no run-time cost. Like this: {{{ newtype Named a name = Named a class Fact p -- Ideally, we'd have a guarantee that the following function -- compiles to exactly the same code as `Prelude.head` head :: Fact (IsCons xs) => (a `Named` xs) -> a head xs = Prelude.head (coerce xs) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15493> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15480: Rename SigTv
by GHC 17 Aug '18

17 Aug '18

#15480: Rename SigTv -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 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: -------------------------------------+------------------------------------- After #15050 and [changeset:"4d91cabcd5e3c603997d9876f6d30204a9b029c6/ghc" 4d91cabc/ghc] it seems odd to call `SigTv` for the kind of type variables that used to be used in type signatures in patterns, but are now used in other places (kind signatures, partial type signatures). Also, `SigTv` may be associated with sigma. At some point I assumed that `SigTv` are type variables that may unify with polytypes, while `TauTv` are those that unify with monotypes. As a service to our future self, I’d like to rename `SigTv`. Suggestions? Best one I have is `TvTv` or `TyVarTv` (for a type variable that stands for a type variable). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15480> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8944: Warn instead of stopping on misplaced Haddock comments
by GHC 17 Aug '18

17 Aug '18

#8944: Warn instead of stopping on misplaced Haddock comments -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Given a simple module like {{{ module H where data F = F () -- ^ Comment for first type argument () }}} and trying to run Haddock on it, we'll get back {{{ /tmp/H.hs:4:12: parse error on input ‘(’ }}} The error message is rather sub-par in this scenario. It'd be great if we could instead print a warning saying that a Haddock comment is unexpected in that position and then continue on parsing. Best case scenario would be a more informative message such as “Documenting each constructor argument is not supported” but that might be quite a bit harder. Filing on GHC Trac as it's the parser that needs changing I believe. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8944> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #15521: Provide a strict version of sum
by GHC 16 Aug '18

16 Aug '18

#15521: Provide a strict version of sum -------------------------------------+------------------------------------- Reporter: dnadales | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Prelude | Version: 8.4.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: -------------------------------------+------------------------------------- When adding huge list of numbers, a strict version of `sum` is preferred to avoid an unnecessary use of memory. A strict version of `sum` can be easily written using `foldl'` but it'd be nicer if a function such as: {{{#!hs sum' = foldl' (+) 0 }}} would be provided in the prelude already. Does this makes sense? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15521> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8