August 2018 - ghc-tickets

[GHC] #15503: interpreter: sequence_ (replicate 100000000 (return ())) gobbles up memory
by GHC 19 Dec '18

19 Dec '18

#15503: interpreter: sequence_ (replicate 100000000 (return ())) gobbles up memory -------------------------------------+------------------------------------- Reporter: int-e | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 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 consider this to be more of a curiosity than a bug, but it might still be worth investigating. The following line, {{{#!hs sequence_ (replicate 100000000 (return ())) }}} causes `ghci` to grow quite big (here it's 6GB on 64 bit Linux; it's roughly proportional to the `100000000` number). This used to be better in ancient times--before version 8.0.1, ghci ran this code in what looks like constant memory. (This came up indirectly on #haskell; somebody had adapted Hutton's game of life program, http://www.cs.nott.ac.uk/~gmh/life.lhs which uses busy waiting for a delay.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15503> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #15003: Data.List documentation should list complexities of more functions
by GHC 18 Dec '18

18 Dec '18

#15003: Data.List documentation should list complexities of more functions -------------------------------------+------------------------------------- Reporter: gbaz | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.4.3 Component: | Version: 8.2.2 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: -------------------------------------+------------------------------------- Lots of functions in `Data.List` have overtly obvious complexity, like `delete`. It would still be nice to list all the complexities explicitly, especially for beginners. Also, just to set a good example. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15003> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #14146: Can GHC propose kind restrictions?
by GHC 17 Dec '18

17 Dec '18

#14146: Can GHC propose kind restrictions? -------------------------------------+------------------------------------- Reporter: Iceland_jack | 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: -------------------------------------+------------------------------------- This is UX. As my code gets more polykinded I find myself in situations such as these all the more often {{{#!hs instance (Comonad f, Representable f, Comonad g, Representable g) => Comonad (Compose f g) where extract = undefined duplicate = undefined instance ComonadApply (Compose f g) where (<@>) = undefined }}} {{{ /tmp/a.hs:20:10-35: error: • No instance for (Comonad (Compose f g)) arising from the superclasses of an instance declaration • In the instance declaration for ‘ComonadApply (Compose f g)’ | 20 | instance ComonadApply (Compose f g) where | ^^^^^^^^^^^^^^^^^^^^^^^^^^ Failed, modules loaded: none. }}} It would help me if GHC looked up a `Comonad (Compose _ _)` instance, compared the kinds {{{#!hs Comonad (Compose (f :: Type -> Type) (g :: Type -> Type) :: Type -> Type) ComonadApply (Compose (f :: k -> Type) (g :: Type -> k) :: Type -> Type) }}} a simple suggestion like this would be helpful {{{ • No instance for (Comonad (Compose f g)) arising from the superclasses of an instance declaration Try adding a kind signature (ComonadApply (Compose (f :: Type -> Type) g)). }}} Even more amazing would be {{{ • No instance for (Comonad (Compose f g)) arising from the superclasses of an instance declaration Try adding a context (Comonad f, Representable f, Comonad g, Representable g) => ComonadApply (Compose f g) }}} Which the compiler could in theory guess, since following GHC's suggestion iteratively you end up with {{{#!hs ComonadApply (Compose (f :: Type -> Type) g) -- ==> add (Comonad f) to the context of the instance declaration Comonad f => ComonadApply (Compose f g) -- ==> add (Comonad g) to the context of the instance declaration (Comonad f, Comonad g) => ComonadApply (Compose f g) -- ==> add (Representable f) to the context of the instance declaration (Comonad f, Comonad g, Representable g) => ComonadApply (Compose f g) -- ==> add (Representable f) to the context of the instance declaration (Comonad f, Comonad g, Representable g, Representable f) => ComonadApply (Compose f g) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14146> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13992: Error message, room for improvement (polykinds)
by GHC 17 Dec '18

17 Dec '18

#13992: Error message, room for improvement (polykinds) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: PolyKinds | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Something like {{{#!hs -- • No instance for (Show (Compose Proxy Proxy a)) -- arising from the 'deriving' clause of a data type declaration -- Possible fix: -- use a standalone 'deriving instance' declaration, -- so you can specify the instance context yourself -- • When deriving the instance for (Show (FlipProxy a)) {-# Language DerivingStrategies, GeneralizedNewtypeDeriving, PolyKinds, KindSignatures #-} import Data.Functor.Compose import Data.Proxy import Data.Kind newtype FlipProxy a = FlipProxy_ (Compose Proxy Proxy a) deriving newtype Show }}} where the solution is to constraint the kind of `a :: Type`, it would be nice if GHC could reference kind variables. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13992> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15562: `-XStrict -XNoStrict` is not neutral
by GHC 14 Dec '18

14 Dec '18

#15562: `-XStrict -XNoStrict` is not neutral -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- I assumed we already had a ticket about this, but it appears we have not. I'm not saying this is a necessarily a bug in the implementation; but we should make sure this is properly documented in the user's guide, and ideally justify why it's done this way rather than the alternatives: As described in StrictPragma, > `Strict` implies `StrictData` Currently however the inverse case does not hold, i.e. `NoStrict` does *not* imply `NoStrictData` This has the surprising property (assuming these were left-most flags on the CLI) that - `-XStrict -XNoStrict` == `-XStrictData` - `-XStrictData -XNoStrict` == `-XStrictData` However, if `-XNoStrict` was to naively imply `-XNoStrictData`, we'd have the properties - `-XStrict -XNoStrict` == *id* - `-XStrictData -XNoStrict` == *id* This might be a bit less confusing; another variant would be - `-XStrict -XNoStrict` == *id* - `-XStrictData -XNoStrict` == `-XStrictData` Btw, I'm not sure what the following means: - `-XStrict -XNoStrictData` == ? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15562> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #15333: Weird cachegrind results for binary-trees
by GHC 14 Dec '18

14 Dec '18

#15333: Weird cachegrind results for binary-trees -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Research needed Component: NoFib | Version: 8.5 benchmark suite | 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'm currently investigating an alleged regression in my branch of the late lambda lift and hit a confusing data point. Note that I'm very much relying on cachegrinds counted instructions/memory accesses for my findings. Check out the most recent version of `nofib` and run the following script: {{{#!sh #! /usr/bin/env zsh sed -i 's/import Debug.Trace//g' Main.hs # Make the following line idempotent echo "import Debug.Trace" | cat - Main.hs > Main.tmp && mv Main.tmp Main.hs # add the import for trace sed -i 's/trace "" \$ bit/bit/g' Main.hs # strip `trace $ ` prefixes in the call to `bit` ghc -O2 -XBangPatterns Main.hs -o bt1 sed -i 's/bit/trace "" $ bit/g' Main.hs # prepend `trace $ ` to the call to `bit` ghc -O2 -XBangPatterns Main.hs -o bt2 valgrind --tool=cachegrind ./bt1 12 2>&1 > /dev/null # without trace valgrind --tool=cachegrind ./bt2 12 2>&1 > /dev/null # with trace }}} This will compile two versions of `binary-trees`, one with an extra `trace "" $` call before the only call to the `bit` function. One would expect the version with the `trace` call (`bt1`) to allocate more than the version without (`bt2`). Indeed, the output of `+RTS -s` suggests that: {{{ $ ./bt1 12 +RTS -s ... 43,107,560 bytes allocated in the heap ... $ ./bt2 12 +RTS -s ... 43,116,888 bytes allocated in the heap ... }}} That's fine. A few benchmark runs by hand also suggested the tracing version is a little slower (probably due to IO). Compare that to the output of the above cachegrind calls: {{{ $ valgrind --tool=cachegrind ./bt1 12 > /dev/null ... I refs: 118,697,583 ... D refs: 43,475,212 ... $ valgrind --tool=cachegrind ./bt2 12 > /dev/null ... I refs: 116,340,710 ... D refs: 42,523,369 ... }}} It's the other way round here! How's that possible? Even if this isn't strictly a bug in GHC or NoFib, it's relevant nonetheless, as our benchmark infrastructure currently relies on instruction counts. I couldn't reproduce this by writing my own no-op `trace _ a = a; {-# NOINLINE trace #-}`, btw. I checked this on GHC 8.2.2 and a semi-recent HEAD commit (bb539cfe335eeec7989332b859b1f3162c5e105a). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15333> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #14473: Implement Underscores in Numeric Literals Proposal (NumericUnderscores extension)
by GHC 14 Dec '18

14 Dec '18

#14473: Implement Underscores in Numeric Literals Proposal (NumericUnderscores extension) -------------------------------------+------------------------------------- Reporter: takenobu | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 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: #13126 #9224 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Implement Underscores in Numeric Literals Proposal. GHC supports various numeric literals such as decimal, octal, hexadecimal, binary, and floating point numbers. However, large numeric literals are hard to read. This proposal improves the readability, quality, expressiveness of numeric literals. This proposal allows underscores to numeric literals when the `NumericUnderscores` language extension is enabled. Underscores (`_`) in numeric literals are simply ignored. The specification of the feature is available here:\\ https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0009 -numeric-underscores.rst For a discussion:\\ https://github.com/ghc-proposals/ghc-proposals/pull/76 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14473> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #14345: Warning when linking with C++ code
by GHC 14 Dec '18

14 Dec '18

#14345: Warning when linking with C++ code -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When linking with a C++ file, GHC 8.2.1.20170928 produces a warning because it runs gcc with 'std=gnu99', even when I pass 'std=c++11' to cc- options (when using stack, I see that the command is something like 'gcc std=gnu99 ... std=c++11', so it isn't *ignoring* my input, just appending it.) I believe this warning is new as of 8.2. The attached example demonstrates the problem: {{{ > cabal configure > cabal build cc1plus: warning: command line option ‘-std=gnu99’ is valid for C/ObjC but not for C++ cc1plus: warning: command line option ‘-std=gnu99’ is valid for C/ObjC but not for C++ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14345> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15080: List Operators Sorted by Precedence in GHCi
by GHC 13 Dec '18

13 Dec '18

#15080: List Operators Sorted by Precedence in GHCi -------------------------------------+------------------------------------- Reporter: sjs | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.2 Keywords: operator | Operating System: Unknown/Multiple precedence | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In a large project, it can be difficult to keep track of the precedence of operators. It would be a nice quality-of-life improvement if there were a GHCi command to list the current operators in scope by precedence. It could list them in a table like this: {{{ :operators | prec | nonassoc | leftassoc | rightassoc | |------+----------+-----------+------------| | 9 | !! | | . | | 8 | | | ^ ^^ ** | | 7 | * / | | | | 6 | + - | | | | 5 | | | : ++ | | 4 | | == | | }}} Perhaps it could list all infix operators, as well as functions that have a fixity declaration? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15080> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #15485: GHC uses 300% CPU when calling into blocking C call
by GHC 13 Dec '18

13 Dec '18

#15485: GHC uses 300% CPU when calling into blocking C call -------------------------------------+------------------------------------- Reporter: oconnore | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime | Version: 8.4.3 System | Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hello, I'm trying to write a program that modifies /etc/passwd safely, and so I wrote a function that looks like this: {{{#!hs lockPwd f = bracket main recover (\_ -> f) where mode = unionFileModes ownerReadMode ownerWriteMode main = do fd <- openFd "/etc/.pwd.lock" WriteOnly (Just mode) defaultFileFlags putStrLn "waiting to set lock" waitToSetLock fd (WriteLock, AbsoluteSeek, 0, 0) putStrLn "got lock" return fd recover = flip setLock (Unlock, AbsoluteSeek, 0, 0) }}} When I run it, my fans go wild, and CPU usage hits 300%. /u/gelisam did some more in depth investigation here: https://www.reddit.com/r/haskell/comments/94wbfc/systemunixiowaittosetlock_… > Googling confirms that the parallel gc is using spin locks. So I think what is happening is that the waitToSetLock call makes the current thread unavailable for garbage collection (I don't know if that means the thread is "descheduled" as in the linked issue), which then causes the other threads to spin-lock while waiting for that thread at the next parallel GC. The problem still occurs with the latest release, GHC 8.4.3, and I could not find an existing issue describing the problem, so please file a ticket. Maybe an argument could be made that this waitToSetLock call should be converted to be [[https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ffi- chap.html#interruptible-foreign-calls|interruptible]], but it also seems like I should be able to make my haskell program block patiently if I want it to. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15485> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3