- ghc-tickets - Haskell.org

Re: [GHC] #3064: Very long compile times with type functions
by GHC 30 Dec '14

30 Dec '14

#3064: Very long compile times with type functions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: low | Milestone: 7.12.1 Component: Compiler (Type | Version: 6.10.1 checker) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | perf/compiler/T3064 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): It may be "a little disappointing" but nevertheless I think it's a notable step forward: * It eliminates a tricky and hard-to-explain complication in the implementation. * It fixes a substantial performance regression that affects programs with deeply-nested superclasses, affecting both compile time and run time. * It eliminates a collection of regressions, whereby silent superclasses actually cause some programs to fail unexpectedly, for very hard-to- explain reasons. They are listed in the commit message. * Moreover, there is no good workaround if you actually hit those regressions. In contrast, there is an immediate and easy workaround if you hit the new regression. * None of this bites you unless you are sailing close to the wind (`UndecidableInstances`). As to whether this belongs in 7.10 I am agnostic. The performance improvements will help everyone slightly (especially in monad-transformer- heavy code). The behaviour change is there all right, but will affect very few people. I don't feel strongly either way. I am not arguing to push it into 7.10, but I will not argue against doing so either. Does anyone else have a view? The default decision is "no" because it is a change wrt RC1. Incidentally, you say "in perverse but realistic scenarios, might cause the superclass dictionary to loop". Indeed it is realistic. It would be all too easy to add by accident {{{ instance (UserOfRegs r CmmExpr) => UserOfRegs r CmmReg where ... }}} perhaps even in another module. Guarding against such subtle loops is a very good thing, in my view. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3064#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7788: Recursive type family causes <<loop>>
by GHC 30 Dec '14

30 Dec '14

#7788: Recursive type family causes <<loop>> -------------------------------------+------------------------------------- Reporter: shachaf | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.6.2 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm all for having an evaluation depth. But I'm cautious about adding a flag. Just saying "lazier" doesn't say much. If we could somehow promise "lazy", for some well-specified meaning of that term, then I'd go for that. But not "disable some implementation optimisation that happens to allow one program (that one one cares about) to typecheck". Currently we flatten type-function applications, and reduce them aggressively. I think it's pretty odd that `id2` typechecks with the optimisation disabled; I strongly suspect that a simple variant will not. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7788#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7788: Recursive type family causes <<loop>>
by GHC 30 Dec '14

30 Dec '14

#7788: Recursive type family causes <<loop>> -------------------------------------+------------------------------------- Reporter: shachaf | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.6.2 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by goldfire): Here's what I'm worried about here. This function is clearly very innocent: {{{ id :: a -> a id x = x }}} It compiles, obviously, without complaint. But, with 7.10, the following doesn't: {{{ type family F a where F a = F a id2 :: F a -> F a id2 x = x }}} This is slightly disturbing because `id2` is merely a specialization of `id`. I think there is an easy solution here, though: allow users to disable the optimisation that we've put into !TcFlatten (`try_to_reduce`). If a user says `-flazier-type-families`, then we turn off the optimization. Most type-family-heavy programs will simply compile much more slowly... but a few will compile in finite time that didn't previously. As a separate solution here, we probably should also detect when we're looping while evaluating a type family by tracking evaluation depth. I'd much rather get an error saying we've blown a limited stack size than to just loop. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7788#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9847: Remove "Difficulty" field from the Trac
by GHC 29 Dec '14

29 Dec '14

#9847: Remove "Difficulty" field from the Trac -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When we recently discussed the [[Newcomers]] page on ghc-devs (this thread: https://www.haskell.org/pipermail/ghc- devs/2014-November/007297.html) we ended up with a conclusion that the "Difficulty" field is not very useful. Simon Marlow proposed that we should remove it: https://www.haskell.org/pipermail/ghc- devs/2014-November/007455.html I agree with Simon's opinion - we don't need Difficulty if we have Keywords. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9847> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #5364: Access RTS flag values from inside Haskell programs
by GHC 29 Dec '14

29 Dec '14

#5364: Access RTS flag values from inside Haskell programs -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ekmett Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.3 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D306 | -------------------------------------+------------------------------------- Changes (by hvr): * milestone: 7.12.1 => 7.10.1 Comment: btw, I noticed that the API exposed by GHC.RTS.Flags varies depending on `unsigned int`: {{{#!hs -- | @'nat'@ defined in @rts/Types.h@ type Nat = #{type unsigned int} data GCFlags = GCFlags { statsFile :: Maybe FilePath , giveStats :: GiveGCStats , maxStkSize :: Nat , initialStkSize :: Nat , stkChunkSize :: Nat ... }}} Is this really a good idea rather simply using `Word` which I assume should always be large enough to contain the range of `CULong`? Moreover, shouldn't most of those small-fields be `!`-ed to avoid thunks and unecessary pointer chasing? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5364#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5364: Access RTS flag values from inside Haskell programs
by GHC 29 Dec '14

29 Dec '14

#5364: Access RTS flag values from inside Haskell programs -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ekmett Type: feature | Status: new request | Milestone: 7.12.1 Priority: normal | Version: 7.3 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D306 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel <hvr@…>): In [changeset:"40561cd235f07d41904d2604ff7f0c942af4d35e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="40561cd235f07d41904d2604ff7f0c942af4d35e" Fix `heapSizeSuggesionAuto` typo (#9934) This was introduced in 1617a10a (re #5364) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5364#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5910: Holes with other constraints
by GHC 28 Dec '14

28 Dec '14

#5910: Holes with other constraints -------------------------------------+------------------------------------- Reporter: xnyhps | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.5 Component: Compiler | Keywords: holes (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: Other | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by ezyang): * priority: high => normal -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5910#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9067: Optimize clearNursery by short-circuiting when we get to currentNursery
by GHC 28 Dec '14

28 Dec '14

#9067: Optimize clearNursery by short-circuiting when we get to currentNursery ------------------------------+-------------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: low | Milestone: Component: Runtime | Version: 7.9 System | Operating System: Unknown/Multiple Keywords: | Type of failure: Runtime performance bug Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- This is a note to myself so I don't forget about this. Essentially, we can do something like this (this particular patch variant untested): {{{ diff --git a/rts/sm/Storage.c b/rts/sm/Storage.c index 36776b9..0311042 100644 --- a/rts/sm/Storage.c +++ b/rts/sm/Storage.c @@ -598,6 +598,11 @@ clearNursery (Capability *cap) ASSERT(bd->gen_no == 0); ASSERT(bd->gen == g0); IF_DEBUG(sanity,memset(bd->start, 0xaa, BLOCK_SIZE)); + if (bd == cap->r.rCurrentNursery) { + IF_DEBUG(sanity, for (bd = bd->link; bd; bd = bd->link) + ASSERT(bd->free == bd->start)); + break; + } } } } }}} This is due to invariants about how we manage the currentNursery pointer. But we need a note about it, and I need to test it more carefully. This optimization probably doesn't help too much on normal GHC, but when I have lots of nurseries it helps quite a bit. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9067> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9764: Home package modules silently override available modules from package database
by GHC 28 Dec '14

28 Dec '14

#9764: Home package modules silently override available modules from package database -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: GHC Blocked By: | accepts invalid program Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- To see this, define a module with the same name as some module in base. GHC will compile this: {{{ module Data.List where foo = 2 module A where import Data.List x = print foo }}} This behavior is intentional; the most compelling reason of behaving this way is that if you are calling `ghc` without `-hide-all-packages`, some random package you installed which just happened to provide a module name that conflicted with yours could cause your code to stop compiling if we treated the package database and home packages equally. However, this behavior seems undesirable when `-hide-all-packages` is provided; at the very least, it seems like you might want to provide a warning that you're defining a module which conflicts with a module from a package you have exposed. This behavior will be further undesirable when signatures come into the picture. Now, I will want to include a package containing a signature for `A`, and FURTHERMORE I may want to declare a signature `A.hsig` in the local package which augments this signature with some extra declarations I need. Under the current behavior, the externally imported signature is just ignored entirely, even though I wanted them to be merged together. My proposal is to switch the behavior so that we don't prefer home modules if `-hide-all-packages` is provided. What's not great about this proposal is that it adds yet another discrepancy between bare GHC use and GHC use with `-hide-all-packages`. I'm interested to know what people would like. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9764> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #7473: getModificationTime gives only second-level resolution
by GHC 28 Dec '14

28 Dec '14

#7473: getModificationTime gives only second-level resolution -------------------------------------+------------------------------------- Reporter: duncan | Owner: ekmett Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.6.1 Libraries | Keywords: directory Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by hvr): * status: new => closed * resolution: => fixed * milestone: 7.12.1 => 7.10.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7473#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0