August 2017 - ghc-tickets

[GHC] #14145: I expect `hp2ps -cd` to work as `hp2ps -c -d` does.
by GHC 23 Aug '17

23 Aug '17

#14145: I expect `hp2ps -cd` to work as `hp2ps -c -d` does. -------------------------------------+------------------------------------- Reporter: qbolec | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Profiling | Version: 7.10.2 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's a common convention among command-line programs that if the documentation describes short options, such as `-c` and `-d` then it should also accept their combination like `-cd`, unless otherwise stated. Alternatively, if this is not supported, then at least a warning abound unknown option "cd" should be displayed. Instead the process silently accepts `-cd`, and produces a colorful chart (-c) but does not sort by variance (ignores d). I'm not sure what version of hp2ps I use, because it seems to ignore `--version` and `-v` and `--help` does not produce version string anywhere. However: $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.10.2 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14145> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14138: Friend modules
by GHC 22 Aug '17

22 Aug '17

#14138: Friend modules -------------------------------------+------------------------------------- Reporter: andreas.abel | 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: -------------------------------------+------------------------------------- For the sake of testing, I would like to import everything from a module that I test, not only the things it exports. {{{#!hs friend import A -- everything from A friend import B (notExported) -- notExported from B friend import qualified C.D as E -- you guess it ... }}} Current work arounds: * Give up on export lists (ruins haddockumentation) * Extra levels of indirection, see https://mail.haskell.org/pipermail/beginners/2010-November/005717.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14138> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #13902: Misleading function arity mismatch error with TypeApplications
by GHC 22 Aug '17

22 Aug '17

#13902: Misleading function arity mismatch error with TypeApplications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple TypeApplications | Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE TypeApplications #-} f :: a -> a f x = x g :: Int g = f @Int 42 5 }}} {{{ GHCi, version 8.3.20170614: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:7:5: error: • Couldn't match expected type ‘Integer -> Int’ with actual type ‘Int’ • The function ‘f’ is applied to three arguments, but its type ‘Int -> Int’ has only one In the expression: f @Int 42 5 In an equation for ‘g’: g = f @Int 42 5 | 7 | g = f @Int 42 5 | ^^^^^^^^^^^ }}} That error message is quite confusing to read, since it reports that: * `f` is applied to three arguments, which //includes// a visible type application * `f` only has one argument, which //excludes// the visible type application We ought to be able to do better. My suggestion would be to report this instead: {{{ • The function ‘f @Int’ is applied to two arguments, but its type ‘Int -> Int’ has only one In the expression: f @Int 42 5 In an equation for ‘g’: g = f @Int 42 5 }}} Although I'm sure there are other ways the same information could be conveyed (e.g., `The function ‘f’ is applied to two value arguments`). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13902> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[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] #14114: Strange behavior when pattern variables are duplicated on pattern synonym RHS
by GHC 22 Aug '17

22 Aug '17

#14114: Strange behavior when pattern variables are duplicated on pattern synonym RHS -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- These might be two separate bugs, but they're similar enough that I'll bundle them under the same ticket. If you take a pattern variable bound on the LHS of a unidirectional pattern synonym and use it multiple locations on the RHS, then GHC accepts it, surprisingly: {{{#!hs pattern Foo a <- (a,a) }}} What does `Foo` do? As it turns out, the right-most occurrence of `a` in the RHS seems to take precedence: {{{ λ> :i Foo pattern Foo :: b -> (a, b) -- Defined at <interactive>:12:1 λ> case ('a', 'b') of Foo x -> x 'b' }}} I expect the definition of `Foo` to error. When duplicate pattern variables are used in the RHS of an implicitly bidirectional pattern synonym, then it does error. However, the error message is quite misleading: {{{ λ> pattern Foo a = (a,a) <interactive>:16:17: error: Invalid right-hand side of bidirectional pattern synonym ‘Foo’: ‘a’ is not bound by the LHS of the pattern synonym RHS pattern: (a, a) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14114> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14143: forkProcess leaks file descriptors
by GHC 22 Aug '17

22 Aug '17

#14143: forkProcess leaks file descriptors ----------------------------------------+--------------------------- Reporter: danharaj | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.2.1 Keywords: | Operating System: POSIX Architecture: Unknown/Multiple | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------- This is normal behavior as forking a process in POSIX will copy all file descriptors unless they are marked O_CLOEXEC. But in Haskell it's quite difficult to figure out which FDs need to be manually closed. For example, if a `Handle` to a file is opened in the parent process and isn't referenced in the code passed to `forkProcess`, its FD will leak. In order to safely fork, a user has to know about all `Handle`s and other structures that use file descriptors currently active in the program as well as which ones will survive by being referenced in the child process. A simpler problem is wanting to close most FDs (e.g. perhaps excepting std*) when forking. When you don't know where the file descriptors in the current process are coming from but you want them to be closed, a not uncommon approach is to iterate over all file descriptors and close them all. The `process` library does this. This doesn't work for `forkProcess` if a Haskell program is built against the threaded runtime because the IO event manager holds on to file descriptors it uses for control. Attempting to iterate over all FDs carelessly causes the IO manager to die when `-threaded` is used. As far as I understand, all of these FDs are held by the `Control` structure associated with an `EventManager`: [https://hackage.haskell.org/package/base-4.10.0.0/docs/src/GHC.Event.Contro…] . The `base` library does not expose these modules so there is no way to figure out what they are from user code. In one's own application, these issues are tricky but ultimately surmountable as one in principle has the ability to track down every file descriptor being opened. However, when using `forkProcess` in a library, one might need a sledgehammer. For example, in the `hdaemonize` package it is noted that the library can leak file descriptors as there is no way to deal with this issue: [https://hackage.haskell.org/package/hdaemonize-0.5.4/docs/System-Posix- Daemonize.html#v:daemonize] I am writing a library in the same design space as `hdaemonize` that I would like to be able to sensibly handle file descriptors. In general the problem looks intractable (for example because arbitrary C libraries could initialize their own internal FDs), but if I could know which file descriptors are being used by the IO Manager, then I could at least provide for the use case where no FDs should be shared between parent and child. Would it be sensible to expose more of the guts of the IO Manager in `base`? Are there other parts of the RTS that use file descriptors that need to be preserved? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14143> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

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

22 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

Re: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals
by GHC 21 Aug '17

21 Aug '17

#5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: strings Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 #11312, #9719 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > These are statically allocated literals. I have a hard time believing that a one-word increase in binary size for each string literal will make a noticeable difference to GHC's binary sizes. Okay, I ran a quick experiment, compiling GHC with `-ddump-simpl` and grepping for primitive strings in the result. The result is merely ~30000 string literals. As I said earlier, a good fraction of these are short, so the relative change in space needed by string literals is rather large. However, compared to the rest of the program, it's quite small: each literal blowing up by a word would be around 250kB. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:95> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals
by GHC 21 Aug '17

21 Aug '17

#5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: strings Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 #11312, #9719 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by winter): > That's a separate issue. It is indeed what OverloadedStrings is for. Perhaps we can have a new ticket for it. But we can't talk meaningfully about it until we settle the first issue: what are the primitive types and operations over them. There I think we have a preliminary consensus, with B# = ByteArray#. My intention is to add a way to let user choose which primitive types he/she wants. But if there's a must to fix a primitive type, `ByteArray#` may be better than `Addr#` since it can be cast into `Addr#` not vice- versa(at the cost of extra info-header and length words). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:94> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals
by GHC 21 Aug '17

21 Aug '17

#5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: strings Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 #11312, #9719 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > It's the ability to choose between Addr# or ByteArray#' or (# Int#, Addr# #), etc. that matters That's a separate issue. It is indeed what `OverloadedStrings` is for. Perhaps we can have a new ticket for it. But we can't talk meaningfully about it until we settle the first issue: what are the primitive types and operations over them. There I think we have a preliminary consensus, with `B#` = `ByteArray#`. Moreover, I think jscholl has a preliminary implementation (comment:74). jscholl: would you like to write up your design as a wiki page? Can you share it? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:93> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0