November 2016 - ghc-tickets

[GHC] #8317: Optimize tagToEnum# at Core level
by GHC 29 Aug '17

29 Aug '17

#8317: Optimize tagToEnum# at Core level ------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #6135 | ------------------------------------+------------------------------------- Old comparison primops that returned Bool were implemented by inserting call to `tagToEnum#` in the code generator. This call to `tagToEnum#` was later optimized away by a special case in the code geenrator (see [[GhcFile(compiler/codeGen/StgCmmExpr.hs)]], Note [case on bool])). Now that we have new comparison primops (see #6135) we no longer insert `tagToEnum#` in the code generator - all uses of `tagToEnum#` come from explicit calls in a source program. But we still have that special case in the code generator to optimize away `tagToEnum#`. We should drop that special case in the code generator and handle scrutinizing of `tagToEnum#` at the Core level by: 1. removing call to `tagToEnum#` in the scrutinee 2. adding calls to `dataToTag#` in case branches 3. constant-folding inserted `dataToTag#` Here is an example. This Haskell code: {{{ if tagToEnum# (a ># b) then E1 else E2 }}} will be translated to this Core: {{{ case tagToEnum# (a ># b) of True -> E1 False -> E2 }}} and optimized like this: {{{ case a ># b of dataToTag# True -> E1 dataToTag# False -> E2 }}} ====> {{{ case a ># b of 1 -> E1 0 -> E2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8317> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #12874: Read/Show Incompatibility in base
by GHC 22 Aug '17

22 Aug '17

#12874: Read/Show Incompatibility in base -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: -------------------------------------+------------------------------------- I just stumbled across a situation where the deriving machinery, in combination with types provided by base, produces Show/Read instances that are incompatible. Here is a minimal example: {{{#!hs import Data.Proxy main :: IO () main = do x <- readLn print (x :: Thing (Proxy Int)) data Thing a = Thing a deriving (Read,Show) }}} If you run this program and type "Thing Proxy" into standard in, you get a parse error. If you type in "Thing (Proxy)", it works fine. Calling `show` on `Thing Proxy` gives the string "Thing Proxy" though. So, `read . show =/= id` in this case. This might just be an issue with `Proxy`'s Read instance, but I'm not really sure. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12874> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11400: * is not an indexed type family
by GHC 21 Aug '17

21 Aug '17

#11400: * is not an indexed type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I can't seem to create an indexed data family using the kind `*` with `-XTypeInType` enabled. I have to work around it by using `Type`: {{{ $ /opt/ghc/head/bin/ghci GHCi, version 8.1.20160108: http://www.haskell.org/ghc/ :? for help λ> :set -XTypeInType -XTypeFamilies λ> import Data.Kind λ> data family IdxProxy k (a :: k) λ> data instance IdxProxy * a <interactive>:5:1: error: • Illegal family instance for ‘*’ (* is not an indexed type family) • In the data instance declaration for ‘*’ λ> data instance IdxProxy Type a λ> :kind! IdxProxy * IdxProxy * :: * -> * = IdxProxy * λ> :kind! IdxProxy Type IdxProxy Type :: Type -> * = IdxProxy Type }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11400> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #12155: Description of flags cut off
by GHC 19 Aug '17

19 Aug '17

#12155: Description of flags cut off -------------------------------------+------------------------------------- Reporter: mikail | Owner: Type: task | Status: new Priority: low | Milestone: Component: Documentation | Version: 8.0.1 Keywords: flags | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The description of the flags from pages 104 to 110 are cut off in the PDF version of the User Guide. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12155> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #12494: Implementation of setenv in base incorrectly claims empty environment variable not supported on Windows
by GHC 18 Aug '17

18 Aug '17

#12494: Implementation of setenv in base incorrectly claims empty environment variable not supported on Windows -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.0.1 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: -------------------------------------+------------------------------------- Relevant code: {{{ -- | @setEnv name value@ sets the specified environment variable to @value@. -- -- On Windows setting an environment variable to the /empty string/ removes -- that environment variable from the environment. For the sake of -- compatibility we adopt that behavior. In particular -- -- @ -- setEnv name \"\" -- @ -- -- has the same effect as -- -- @ -- `unsetEnv` name -- @ }}} This sounds nice and authoritative... and it's also not true. https://msdn.microsoft.com/en- us/library/windows/desktop/ms686206(v=vs.85).aspx states that only if the pointer is NULL (as opposed to an empty string) is the environment variable deleted. https://github.com/golang/go/issues/5610 corroborates So `setEnv` has been given bogus semantics that don't make sense because empty environment variables ARE supported on Windows. My suggestion is to just fix this so that setEnv takes empty environment variables. But this would be a BC breaking change. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12494> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #11975: New GHCi command to print out the type of an expression without instantiating
by GHC 17 Aug '17

17 Aug '17

#11975: New GHCi command to print out the type of an expression without instantiating -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: GHCi | Version: 8.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: -------------------------------------+------------------------------------- #11376 changed the meaning of `:type` to deeply instantiate a type before printing. This means that we can't see which variables were specified and which were inferred. I propose `:type-spec` (please suggest a better name) that does not instantiate first. Phab patch to be posted shortly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11975> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #11587: Place shared objects in LIBDIR
by GHC 17 Aug '17

17 Aug '17

#11587: Place shared objects in LIBDIR -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Package | Version: 7.10.3 system | 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: -------------------------------------+------------------------------------- If one compiles a program with `-dynamic`, the resulting executable includes in its `rpath` the library directory of every Haskell package that the program links against. This causes a significant number of excess system calls at program start-up. For instance, in the case of a dynamically linked `ghc` executable on Debian 8, compiling a trivial "hello world" application produces over 800 `open` calls, the majority of which originate from the dynamic linker. e.g., {{{ $ strace -f -e open ghc-7.10.3 -c -fforce-recomp Test.hs 2>&1 | grep open ... open("/usr/lib/ghc/bin/../haske_GGvi737nHHfG6zm2y7Rimi/tls/x86_64/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/ghc/bin/../haske_GGvi737nHHfG6zm2y7Rimi/tls/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/ghc/bin/../haske_GGvi737nHHfG6zm2y7Rimi/x86_64/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/ghc/bin/../haske_GGvi737nHHfG6zm2y7Rimi/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/ghc/bin/../termi_6iVf4EBnOgfIaaOCLRs8jl/tls/x86_64/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/ghc/bin/../termi_6iVf4EBnOgfIaaOCLRs8jl/tls/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/ghc/bin/../termi_6iVf4EBnOgfIaaOCLRs8jl/x86_64/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/ghc/bin/../termi_6iVf4EBnOgfIaaOCLRs8jl/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/ghc/bin/../ghc_0AG9TOjDEtx4Ji3wSwHOBe/tls/x86_64/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/ghc/bin/../ghc_0AG9TOjDEtx4Ji3wSwHOBe/tls/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/ghc/bin/../ghc_0AG9TOjDEtx4Ji3wSwHOBe/x86_64/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) ... }}} The dynamic linker must look in nearly 25 Haskell library directories to locate every system library! This is madness. Instead of placing each shared library in its own directory, `$LIBDIR/$PKG_KEY/lib$PKG_KEY.so` as we do currently, why not just place them in `$LIBDIR`, e.g. `$LIBDIR/libPKG_KEY.so`. This would mean that we need to include only one directory, `$LIBDIR`, in `rpath`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11587> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #11785: Kinds should be treated like types in TcSplice
by GHC 17 Aug '17

17 Aug '17

#11785: Kinds should be treated like types in TcSplice -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Template | Version: 8.1 Haskell | 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: -------------------------------------+------------------------------------- !TcSplice handles kinds differently than types. Now that they are the same, it's probably best to rewrite this code. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11785> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #12087: Inconsistency in GADTs?
by GHC 17 Aug '17

17 Aug '17

#12087: Inconsistency in GADTs? -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: GADTs | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs f :: Ord a => Eq a => a -> Bool f = … }}} this is allowed but not in GADTs {{{#!hs data F a where MkF :: Ord a => Eq a => a -> F a -- <interactive>:48:16: error: -- • Data constructor ‘MkF’ returns type ‘Eq a => a -> F a’ -- instead of an instance of its parent type ‘F a’ -- • In the definition of data constructor ‘MkF’ -- In the data type declaration for ‘F’ }}} not a big deal -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12087> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #10807: PatternGuards and MultiWayIf layout rules
by GHC 16 Aug '17

16 Aug '17

#10807: PatternGuards and MultiWayIf layout rules -------------------------------------+------------------------------------- Reporter: htebalaka | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- The layout rules for MultiWayIf currently require any lines starting with a comma to be further indented than the lines starting with a pipe when used in conjunction with PatternGuards. This is inconsistent with the examples given in [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/syntax- extns.html#pattern-guards]. For instance, we can't use the same indentation in the second example as in the first without triggering a parser error. {{{#!hs {-# LANGUAGE PatternGuards, MultiWayIf fine a pred | Just x <- a , pred x = True | otherwise = False notFine a pred = if | Just x <- a , pred x -> True | otherwise -> False }}} Though the documentation isn't ''incorrect'', if this intentional it could be pointed out, since it's counterintuitive. Otherwise, if there's no reason for MulitWayIf to require further indentation that should be fixed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10807> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11