September 2017 - ghc-tickets

[GHC] #14235: Suspiciously missing closure types in isRetainer
by GHC 19 Sep '17

19 Sep '17

#14235: Suspiciously missing closure types in isRetainer -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Runtime | Version: 8.2.1 System | 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: -------------------------------------+------------------------------------- `RetainerProfile:isRetainer` has a switch on closure types which appears to be lacking several defined types. * `BLOCKING_QUEUE`: someone actually came into `#ghc` complaining about a crash due to this one * `WHITEHOLE` * `SMALL_MUT_ARR_PTRS_CLEAN` * `SMALL_MUT_ARR_PTRS_DIRTY` * `SMALL_MUT_ARR_PTRS_FROZEN0` * `SMALL_MUT_ARR_PTRS_FROZEN` * `COMPACT_NFDATA` -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14235> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14249: ApplicativeDo: Pattern matching on a bind forces a Monad constraint
by GHC 19 Sep '17

19 Sep '17

#14249: ApplicativeDo: Pattern matching on a bind forces a Monad constraint --------------------------------------+--------------------------- Reporter: mutantmell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: ApplicativeDo | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------- Pattern matching on a bind in 8.2.1 confuses ApplicativeDo, and causes the type to have a Monad constraint where a Functor constraint would suffice. In GHC 8.0: {{{#!hs > :set -XApplicativeDo > :t \x -> do { (a, _) <- x; pure (a+1) } \x -> do { (a, _) <- x; pure (a+1) } :: (Num b, Functor f) => f (b, t) -> f b }}} In GHC 8.2: {{{#!hs > :set -XApplicativeDo > :t \x -> do { (a, _) <- x; pure (a+1) } \x -> do { (a, _) <- x; pure (a+1) } :: (Num b1, Monad m) => m (b1, b2) -> m b1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14249> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

Re: [GHC] #7277: Recompilation check fails for TH unless functions are inlined
by GHC 19 Sep '17

19 Sep '17

#7277: Recompilation check fails for TH unless functions are inlined -------------------------------------+------------------------------------- Reporter: orenbenkiki | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.4.2 Resolution: | Keywords: | RecompilationCheck Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: 481 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => RecompilationCheck -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7277#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7414: plugins always trigger recompilation
by GHC 19 Sep '17

19 Sep '17

#7414: plugins always trigger recompilation -------------------------------------+------------------------------------- Reporter: jwlato | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: plugin, | RecompilationCheck Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: plugin, recompilation => plugin, RecompilationCheck -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7414#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14250: GHCi by default opens .ghci files in local directories.
by GHC 19 Sep '17

19 Sep '17

#14250: GHCi by default opens .ghci files in local directories. -------------------------------------+------------------------------------- Reporter: merijn | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.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: -------------------------------------+------------------------------------- During a discussion on IRC I learned that `ghci` still opens `.ghci` in local directories by default (I think I raised this issue before). This means that if I'm looking through the source of an untrusted Haskell repo I can get my machine owned by simply running `ghci`. Now for simple shell use I could get solve this by aliasing `ghci` to `ghci -ignore-dot-files -ghci-script ~/.ghci`, but there are a lot of editor/IDE tools that also run `ghci` that wouldn't use this alias. Some sensible solutions that spring to mind are: 1) Only load `~/.ghci` by default and add a flag that enables scanning local files. 2) Adding `ghci` commands to enable/disable loading local `.ghci` files in the ghci prompt and change the load order of `.ghci` files so that `~/.ghci` loads first and can enable/disable loading local files. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14250> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #6084: Add stg_ap_pnnv and related call patterns
by GHC 19 Sep '17

19 Sep '17

#6084: Add stg_ap_pnnv and related call patterns -------------------------------------+------------------------------------- Reporter: SimonMeier | Owner: simonmar Type: feature request | Status: closed Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 8313 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by angerman): The problem I'm running into is, that I try to match up caller and callee signatures in my llvm code gen, as LLVM expect them to be properly typed. And as we are passing registers are argument in LLVM. I end up with signatures that do not match. Our current llvm backend, simply assumes it can safely call a function with more parameters than the function signature permitted. I'm not sure we could potentially create a function {{{ f :: BaseReg -> Sp -> Hp -> R1 -> R2 -> R3 -> R4 -> R5 -> R6 -> SpLim -> F1 -> D1 -> F2 -> D2 }}} and then elminate `F1` and `D1`. Thus actually having {{{ f :: BaseReg -> Sp -> Hp -> R1 -> R2 -> R3 -> R4 -> R5 -> R6 -> SpLim -> F2 -> D2 }}} and finally ending up calling it with {{{ f baseReg sp hp r1 r2 r3 r4 r5 r6 spLim f1 d1 f2 d2 }}} where we now pass `f1` where `f` expects `F2`? It might also just be the case, that generating the function signature from the `live` is suboptimal. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6084#comment:40> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14227: Add -fdefer-ffi-errors flag
by GHC 18 Sep '17

18 Sep '17

#14227: Add -fdefer-ffi-errors flag -------------------------------------+------------------------------------- Reporter: tysonzero | Owner: (none) Type: feature | Status: new request | 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: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently when I do: {{{#!hs foreign import javascript unsafe "foo()" foo :: IO () }}} I understandably get: {{{ • The `javascript' calling convention is unsupported on this platform • When checking declaration: foreign import javascript unsafe "static foo()" foo :: IO () }}} However when I am developing with GHCJS I still want to use all my typical GHC tooling, a lot of which is not supported on GHCJS. So I need GHC to be able to compile my code even though I don't actually run it, currently I often have to do: {{{#!hs #ifdef __GHCJS__ foreign import javascript unsafe "foo()" foo :: IO () #else foo :: IO () foo = error "GHCJS required to use foo" #endif }}} Which is really noisy and annoying code to write, and it also does not help me with compiling external library code that does not do the above. It also pins me specifically to GHCJS and any future compiler that supports JS to any degree will need the code changed. The easiest solution to the problem seems to me to be a `-fdefer-ffi- errors` flag which replaces any unsupported ffi declaration with a runtime `error` call that gives a similar error message to the one currently given at compile time. I would also like a `-fdefer-ffi-errors-no-warn` flag to avoid my tooling complaining / emitting a bunch of warnings that don't actually help me much. This is not a very exciting request, but it would be a huge quality of life improvement for front end Haskell web development, and it does not seem overly difficult or dangerous to implement. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14227> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14248: GHC misses optimization opportunity
by GHC 18 Sep '17

18 Sep '17

#14248: GHC misses optimization opportunity -------------------------------------+------------------------------------- Reporter: vagarenko | 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: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider this code: {{{#!hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE TypeApplications #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE AllowAmbiguousTypes #-} module Unzip where import Prelude hiding (unzip) import GHC.TypeLits import Data.Kind -- | Data family of unboxed vectors. class IsVector (n :: Nat) e where data Vector n e :: Type fromList :: [e] -> Vector n e -- | Unrolled unzip. Type param @n@ is the length of the input list. class Unzip (n :: Nat) where unzip :: [(a, b)] -> ([a], [b]) instance {-# OVERLAPPING #-} Unzip 0 where unzip _ = ([], []) {-# INLINE unzip #-} instance {-# OVERLAPPABLE #-} (Unzip (n - 1)) => Unzip n where unzip [] = error "Not enough elements." unzip (x : xs) = (\(a, b) (as, bs) -> (a : as, b : bs)) x (unzip @(n - 1) xs) {-# INLINE unzip #-} -- | Make pair of vectors from list of pairs of vector's elements. unzipVec :: forall (n :: Nat) e. (IsVector n e, Unzip n) => [(e, e)] -> (Vector n e, Vector n e) unzipVec ps = let (es1, es2) = unzip @n ps in (fromList es1, fromList es2) {-# INLINE unzipVec #-} -------------------------------- instance IsVector 2 Float where data Vector 2 Float = Vector2f {-# UNPACK #-} !Float {-# UNPACK #-} !Float fromList [a, b] = Vector2f a b fromList [] = error "Not enough elements." unzipVecSpecialized :: [(Float, Float)] -> (Vector 2 Float, Vector 2 Float) unzipVecSpecialized = unzipVec }}} GHC-8.2.1 generates the following Core for `unzipVecSpecialized` function: {{{#!hs -- RHS size: {terms: 84, types: 113, coercions: 4, joins: 0/1} unzipVecSpecialized :: [(Float, Float)] -> (Vector 2 Float, Vector 2 Float) unzipVecSpecialized = \ (eta :: [(Float, Float)]) -> let { ds :: ([Float], [Float]) ds = case eta of { [] -> lvl20; : x xs -> case x of { (a, b) -> case xs of { [] -> lvl20; : x1 xs1 -> case x1 of { (a1, b1) -> (: @ Float a (: @ Float a1 ([] @ Float)), : @ Float b (: @ Float b1 ([] @ Float))) } } } } } in (case ds of { (es1, es2) -> case es1 of { [] -> $fIsVector2Float1; : a ds1 -> case ds1 of { [] -> $fIsVector2Float1; : b ds2 -> case ds2 of { [] -> case a of { F# dt1 -> case b of { F# dt3 -> (Vector2f dt1 dt3) `cast` <Co:2> } }; : ipv ipv1 -> $fIsVector2Float1 } } } }, case ds of { (es1, es2) -> case es2 of { [] -> $fIsVector2Float1; : a ds1 -> case ds1 of { [] -> $fIsVector2Float1; : b ds2 -> case ds2 of { [] -> case a of { F# dt1 -> case b of { F# dt3 -> (Vector2f dt1 dt3) `cast` <Co:2> } }; : ipv ipv1 -> $fIsVector2Float1 } } } }) }}} Notice how it constructs tuple of lists `ds :: ([Float], [Float])` and then deconstructs it twice. I would expect the compiler to get rid of intermediate tuple and lists, so the Core would look like this: {{{#!hs unzipVecSpecialized :: [(Float, Float)] -> (Vector 2 Float, Vector 2 Float) unzipVecSpecialized = \ (eta :: [(Float, Float)]) -> case eta of { [] -> lvl20; : x xs -> case x of { (a, b) -> case xs of { [] -> lvl20; : x1 xs1 -> case x1 of { (a1, b1) -> (case a of { F# dt1 -> case a1 of { F# dt2 -> (Vector2f dt1 dt2) }}, case b of { F# dt3 -> case b1 of { F# dt4 -> (Vector2f dt3 dt4) }} ) } } } } }}} I've tried putting different phase control options on the INLINE pragmas to no success. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14248> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #13127: Refactor AvailInfo to be more sensible
by GHC 18 Sep '17

18 Sep '17

#13127: Refactor AvailInfo to be more sensible -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering Type: task | Status: closed Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 12662 Related Tickets: #13128 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * status: new => closed * resolution: => duplicate * related: => #13128 Comment: Closing as duplicate of #13128. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13127#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14245: Make ScopedTypedVariables be effective for any type signature
by GHC 18 Sep '17

18 Sep '17

#14245: Make ScopedTypedVariables be effective for any type signature -------------------------------------+------------------------------------- Reporter: jeltsch | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (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: -------------------------------------+------------------------------------- At the moment, `ScopedTypeVariables` does not have an effect for type signatures without an explicit `forall`. Therefore, you are forced to explicitly quantify type variables if you want the type variables of your type signature to be visible outside the type signature. When defining global variables, this means that you have to change part of the interface (the type signature) because of a change in the implementation. Of course, the change is only syntactical, but there is still a change. This is particularly problematic, because Haddock will follow the source code when deciding whether to include a top-level `forall` in the generated documentation or not. Your Haddock-generated documentation will include spurious `forall`s just because of the way your implementation works. You could say that this is just a Haddock issue. However, problems do not stop here. There is also an inconsistency between scoped type variables in variable definitions and scoped type variables in instance declarations. In instance declarations, you do not have to use an explicit `forall`. Type variables in the instance declaration head are visible in the body as soon as `ScopedTypeVariables` is enabled. I propose to change the semantics of `ScopedTypeVariables` such that as soon as it is enabled, the feature is in effect for all rank-1 type variables in any type signature. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14245> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4