December 2017 - ghc-tickets

Re: [GHC] #1290: ghc runs preprocessor too much
by GHC 02 Dec '17

02 Dec '17

#1290: ghc runs preprocessor too much -------------------------------------+------------------------------------- Reporter: guest | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 6.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: 14553 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * blockedby: => 14553 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1290#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #481: Recompilation check fails for TH
by GHC 02 Dec '17

02 Dec '17

#481: Recompilation check fails for TH -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 7.2.1 Component: Template Haskell | Version: 6.4.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: TH_recompile Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by saurabhnanda): * cc: saurabhnanda (added) Comment: Just wondering what would be the perf-impact of doing the extra "stability check" (as mentioned in https://ghc.haskell.org/trac/ghc/ticket/481#comment:11 )? A lot of the code that we write uses TH heavily (eg. deriving ToJSON/FromJSON instances, test-suites, deriving lenses, etc) and I was wondering if this particular issue is the reason for generally slow compile times. (Not that I have isolated this to be the reason -- just asking.) We have 1,200+ modules in our code-base and we use TH so heavily that it's enabled by default (via the Cabal file). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/481#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14382: The 'impossible' happened whilst installing gi-gtk via cabal
by GHC 02 Dec '17

02 Dec '17

#14382: The 'impossible' happened whilst installing gi-gtk via cabal --------------------------------------+--------------------------------- Reporter: maartenjacobs | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: gtk, pango | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- I've been trying to install gi-gtk using "cabal install gi-gtk". In the process I upgraded to the most recent stable GHC and cabal. I've also installed gtk3 libraries which I thought were necessary. {{{ ... [91 of 95] Compiling GI.Pango.Objects.Layout ( GI/Pango/Objects/Layout.hs, dist/build/GI/Pango/Objects/Layout.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-unknown-linux): tcIfaceGlobal (local): not found You are in a maze of twisty little passages, all alike. While forcing the thunk for TyThing Layout which was lazily initialized by initIfaceCheck typecheckLoop, I tried to tie the knot, but I couldn't find Layout in the current type environment. If you are developing GHC, please read Note [Tying the knot] and Note [Type-checking inside the knot]. Consider rebuilding GHC with profiling for a better stack trace. Contents of current type environment: [] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/iface/TcIface.hs:1696:23 in ghc:TcIface Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Failed to install gi-pango-1.0.15 cabal: Error: some packages failed to install: gi-gdk-3.0.14-INozoUgbf2HFkX3VeIwKfl depends on gi-gdk-3.0.14 which failed to install. gi-gtk-3.0.17-1AObKz0Ppj5GXVupmEC7Yc depends on gi-gtk-3.0.17 which failed to install. gi-pango-1.0.15-E4HLwHGC2n62ObUIQeuwp8 failed during the building phase. The exception was: ExitFailure 1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14382> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #14549: RecordWildCards doesn't work properly in repl
by GHC 02 Dec '17

02 Dec '17

#14549: RecordWildCards doesn't work properly in repl -------------------------------------+------------------------------------- Reporter: akegalj | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: GHCi | Version: 8.2.1 Keywords: repl, | Operating System: Unknown/Multiple recordwildcards | Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs Prelude> :set -XRecordWildCards Prelude> data Test = Test { t1 :: Int, t2 :: Int } deriving Show Prelude> t1 = 2 Prelude> Test { t2 = 2, ..} <interactive>:15:1: warning: [-Wmissing-fields] • Fields of 'Test' not initialised: t1 • In the expression: Test {t2 = 2, ..} In an equation for 'it': it = Test {t2 = 2, ..} <interactive>:15:1: warning: [-Wmissing-fields] • Fields of 'Test' not initialised: t1 • In the expression: Test {t2 = 2, ..} In an equation for 'it': it = Test {t2 = 2, ..} Test {t1 = *** Exception: <interactive>:15:1-18: Missing field in record construction t1 }}} I would expect above to return `Test {t1 = 2, t2 = 2}` instead of throwing an error. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14549> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14254: The Binary instance for TypeRep smells a bit expensive
by GHC 01 Dec '17

01 Dec '17

#14254: The Binary instance for TypeRep smells a bit expensive -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: Typeable | 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: -------------------------------------+------------------------------------- In particular, `get` uses `getSomeTypeRep`. `getSomeTypeRep`, in turn, calls `typeRepKind` through its recursion. But `typeRepKind` is itself recursive, fully inspecting the spine of its argument. That smells quadratic to me. The solution, I believe, is to change the type of `getSomeTypeRep` to `BinHandle -> IO (SomeTypeRep, TypeRep Type)`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14254> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

Re: [GHC] #1290: ghc runs preprocessor too much
by GHC 01 Dec '17

01 Dec '17

#1290: ghc runs preprocessor too much -------------------------------------+------------------------------------- Reporter: guest | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 6.7 Resolution: | Keywords: 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: | -------------------------------------+------------------------------------- Comment (by dfeuer): bgamari points out that if something like https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp goes in, we may get the information we need about preprocessor dependencies for CPP. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1290#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1290: ghc runs preprocessor too much
by GHC 01 Dec '17

01 Dec '17

#1290: ghc runs preprocessor too much -------------------------------------+------------------------------------- Reporter: guest | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 6.7 Resolution: | Keywords: 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 dfeuer): * cc: dfeuer (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1290#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1290: ghc runs preprocessor too much
by GHC 01 Dec '17

01 Dec '17

#1290: ghc runs preprocessor too much -------------------------------------+------------------------------------- Reporter: guest | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 6.7 Resolution: | Keywords: 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: | -------------------------------------+------------------------------------- Comment (by dfeuer): I think this is essentially impossible to fix. Along with the ''import'' dependencies, there are also the ''preprocessing'' dependencies. If I have {{{#!hs module Blah where #include Foo.h }}} then I need to preprocess `Blah.hs` any time `Foo.h` changes. But that means we need to know that `Blah.hs` depends on `Foo.h`. Without detailed knowledge of the preprocessor language, I don't see any way to determine this. I'm very tempted to close this ticket as invalid, but let's see if anyone disagrees. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1290#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14550: Report the provenance of TyThings
by GHC 01 Dec '17

01 Dec '17

#14550: Report the provenance of TyThings -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: task | 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: -------------------------------------+------------------------------------- One thing we are slightly nervous about regarding our resolution to #14396 is whether or not there will be a difficult to understand bug stemming from the fact that we may silently pick up an hs-boot TyThing, depending on when you do a lookup. You may be able to find the information by printing the TyThing with pprTyThing, but nothing is going to tell you, in the face, "Hey! This came from a boot file!" So, simonpj suggested that we extend the TyThing pretty-printer to say where a TyThing came from. This is a good question. The big question: where will we put the provenance? There are two possibilities: 1. Add a field in each constructor TyThing recording the provenance (this feels like a disruptive to an otherwise very simple union) 2. Add a field to each of the constructors Id, ConLike, TyCon, CoAxiom (this involves a lot more typing, but these constructors already have lots of fields so it's not as disruptive) The provenance will, for now, look something like: {{{ newtype TyThingSrc = TyThingSrc { tyThingFromBoot :: Bool } }}} and then `TcIface` will be extended to know if we're in boot and will fill things in accordingly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14550> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #14490: TTG Snags
by GHC 01 Dec '17

01 Dec '17

#14490: TTG Snags -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #14482 Differential Rev(s): | Wiki Page: | ImplementingTreesThatGrow -------------------------------------+------------------------------------- == Context ImplementingTreesThatGrow The intention is to get the first-pass implementation of Trees that Grow into GHC 8.4.1. So far the following commits are on master - https://phabricator.haskell.org/rGHC438dd1cbba13d35f3452b4dcef3f94ce9a216905 - https://phabricator.haskell.org/rGHCe3ec2e7ae94524ebd111963faf34b84d942265b4 - https://phabricator.haskell.org/rGHC47ad6578ea460999b53eb4293c3a3b3017a56d65 Unfortunately we have picked up compile-time performance regressions in compiling GHC itself, with these patches. The perf.haskell.org results are - https://perf.haskell.org/ghc/#revision/438dd1cbba13d35f3452b4dcef3f94ce9a21… - https://perf.haskell.org/ghc/#revision/e3ec2e7ae94524ebd111963faf34b84d9422… - https://perf.haskell.org/ghc/#revision/47ad6578ea460999b53eb4293c3a3b3017a5… Summary: each of the three patches caused GHC validate time to worsen by another 5% or so, cumulatively pushing compile time from 2011 to 2400 seconds. It seems the major culprit is deriving the `Data` instances, probably related to the complex constraint sets required to ensure that all the extension points have `Data` instances too. Some discussion around this is captured in ImplementingTreesThatGrow/Instances == Things tried so far PLAN E (ImplementingTreesThatGrow/Instances#PLANE), in https://github.com/ghc/ghc/tree/wip/ttg5-data-one-file-2017-11-17. This puts all the `Data` derivations for the hsSyn AST into a single file, `hsSyn/HsInstances.hs`. This causes compile-time memory usage to spike up to around 7GB when compiling this file. Gipedia reports a compilation time of 2468 secs for this version, which perhaps indicates that the instance derivation is not the main culprit. The module itself only takes in the order of 45secs to compile, on `home .smart-cactus.org` (http://lpaste.net/7779809210564345856) Splitting the `HsInstances.hs` file in 2, as per https://github.com/ghc/ghc/tree/wip/ttg5-data-2017-11-17 reduces the memory requirement for each, but shows up #14482, where there is a linker failure due to incorrectly processing boot files. == Next Steps I guess the first thing to do is to try to isolate what precisely is causing the slowdown. It may not be instance generation at all. Also, it is probably better to revert the three patches from master, when cutting the 8.4 initial freeze. Open to suggestions ... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14490> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 48