From ghc-devs at haskell.org Tue May 1 01:57:21 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 May 2018 01:57:21 -0000 Subject: [GHC] #14970: GHC.Err.errorWithoutStackTrace produces stack trace when profiling enabled In-Reply-To: <046.a5415cff0c88c89467e1859ff9e5e10d@haskell.org> References: <046.a5415cff0c88c89467e1859ff9e5e10d@haskell.org> Message-ID: <061.9c6cbe605eb79041224209144caf22d9@haskell.org> #14970: GHC.Err.errorWithoutStackTrace produces stack trace when profiling enabled -------------------------------------+------------------------------------- Reporter: rotaerk | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: libraries/base | Version: 8.2.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4648 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) Comment: bgamari, that's a bit tricky. It's only possible to avoid building the call stack if the demand analyzer can see that it won't be used. I think the only reliable way to avoid building one is to be careful with your constraints. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 1 02:04:03 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 May 2018 02:04:03 -0000 Subject: [GHC] #15108: Panic: collectNBinders In-Reply-To: <050.b2ce8b77cab404f5ee4296cbccf39745@haskell.org> References: <050.b2ce8b77cab404f5ee4296cbccf39745@haskell.org> Message-ID: <065.48c57e47b534f34fa9226e0ce18640ab@haskell.org> #15108: Panic: collectNBinders -------------------------------------+------------------------------------- Reporter: cdisselkoen | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.4.2 Resolution: | Keywords: panic | collectNBinders Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by cdisselkoen): Note: also reproduces with GHC 8.2.2 (stackage `lts-11.7`). {{{ $ stack ghc -- --version The Glorious Glasgow Haskell Compilation System, version 8.2.2 $ stack build --profile bug-0.1.0.0: configure (exe) Configuring bug-0.1.0.0... bug-0.1.0.0: build (exe) Preprocessing executable 'bug' for bug-0.1.0.0.. Building executable 'bug' for bug-0.1.0.0.. [1 of 1] Compiling Main ( Main.hs, .stack-work/dist/x86_64 -linux-tinfo6-nopie/Cabal-2.0.1.0/build/bug/bug-tmp/Main.p_o ) ghc: panic! (the 'impossible' happened) (GHC version 8.2.2 for x86_64-unknown-linux): collectNBinders 1 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/coreSyn/CoreSyn.hs:1997:25 in ghc:CoreSyn Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- While building custom Setup.hs for package bug-0.1.0.0 using: /usr/local/home/cdisselk/.stack/setup-exe-cache/x86_64-linux- tinfo6-nopie/Cabal-simple_mPHDZzAJ_2.0.1.0_ghc-8.2.2 --builddir=.stack- work/dist/x86_64-linux-tinfo6-nopie/Cabal-2.0.1.0 build exe:bug --ghc- options " -ddump-hi -ddump-to-file -fdiagnostics-color=always" Process exited with code: ExitFailure 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 1 02:16:13 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 May 2018 02:16:13 -0000 Subject: [GHC] #15108: Panic: collectNBinders In-Reply-To: <050.b2ce8b77cab404f5ee4296cbccf39745@haskell.org> References: <050.b2ce8b77cab404f5ee4296cbccf39745@haskell.org> Message-ID: <065.7d1f6a06fb15bdd5a8745df45f57a1f5@haskell.org> #15108: Panic: collectNBinders -------------------------------------+------------------------------------- Reporter: cdisselkoen | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.4.2 Resolution: | Keywords: panic | collectNBinders Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"4e45ebeea097b662076936f5a50c0873d8737923/ghc" 4e45ebe/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4e45ebeea097b662076936f5a50c0873d8737923" Add test case for #15108 thanks to cdisselkoen for the nicely minimized test case. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 1 02:19:18 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 May 2018 02:19:18 -0000 Subject: [GHC] #15108: Panic: collectNBinders In-Reply-To: <050.b2ce8b77cab404f5ee4296cbccf39745@haskell.org> References: <050.b2ce8b77cab404f5ee4296cbccf39745@haskell.org> Message-ID: <065.30d720298cb83e75e883cbcf36605165@haskell.org> #15108: Panic: collectNBinders -------------------------------------+------------------------------------- Reporter: cdisselkoen | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.4.2 Resolution: | Keywords: panic | collectNBinders Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Thanks for the nice test case, I added it to the test suite. JFTR, this can be easily reproduced without stack or GHC: {{{ ~/build/haskell/ghc-master $ ./inplace/bin/ghc-stage2 testsuite/tests/profiling/should_compile/T15108.hs -prof -fprof-auto -dcore-lint [1 of 1] Compiling Main ( testsuite/tests/profiling/should_compile/T15108.hs, testsuite/tests/profiling/should_compile/T15108.o ) *** Core Lint errors : in result of Desugar (after optimization) *** testsuite/tests/profiling/should_compile/T15108.hs:22:7: warning: [RHS of myInt_aVZ :: Int -> MyInt] Join point has too few lambdas Join var: myInt_aVZ Join arity: 1 Number of lambdas: 0 Rhs = scctick MyInt *** Offending Program *** getInt :: Shape -> MyInt [LclIdX] getIntghc-stage2: panic! (the 'impossible' happened) (GHC version 8.5.20180410 for x86_64-unknown-linux): collectNBinders 1 Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1162:37 in ghc:Outputable pprPanic, called at compiler/coreSyn/CoreSyn.hs:2056:25 in ghc:CoreSyn Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} As you can see, it does not require any optimization level, and the bug is in place right after the desugarer. Maybe the optimizer copies the join arity from `MyInt` to `myInt`, under the assumption that `myInt` will be inlined, but the `scctick` prevents that from happening? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 1 04:53:58 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 May 2018 04:53:58 -0000 Subject: [GHC] #15038: Memory Corruption (strange closure type) In-Reply-To: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> References: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> Message-ID: <064.cb4a076d6e46cab5573324c73a82ea03@haskell.org> #15038: Memory Corruption (strange closure type) -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #9718 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Andrew, > It sounds like the crash I have been experiencing will be fixed in GHC 8.6 That's correct. I'm implementing a fix right now, it should be merged in a few days. > What I don’t fully grasp is the set of circumstances under which this error manifests itself. This error happens when: - You have a top-level definition that uses unboxed sums and is not CAFFY (i.e. does not reference to CAFs directly or transitively). Note that GHC as a result of optimisations can introduce top-level definitions so predicting whether you'll have such definitions is impossible from the source code. - Unboxed sums used in this top-level definition have unused fields. This happens when you have a sum with type ``` (# Int# | Int #) ``` Here you need 3 slots: a tag, an `Int#` and an `Int`, because pointer and non-pointer fields can't overlap (GC concerns). Now here are two terms and what they're compiled to: ``` (# 1# | #) ===> (# 0#, 1#, UNUSED_POINTER #) (# | 1 #) ===> (# 1#, UNUSED_INT#, 1 #) ``` We don't want to leave these unused fields uninitialized (for various reasons, like safety and IIRC also has to do with Cmm code generation which used to panic when pointer field is left with uninitialized garbage), so we use something called `absentError`. `absentError` should not be CAFFY otherwise it would make everything transitively referring to it CAFFY (I think when we first implemented unboxed sums `absentError` was not CAFFY), and CAFFY objects need special treatment from code generator and garbage collector. This causes the problem because CAFFY-ness is calculated in an early stage than the pass that compiles unboxed sums to unboxed tuples, causing inconsistent CAFFY information. In summary if at least one of these conditions hold you're safe: - You don't have `UNUSED_POINTER` fields in your unboxed sum types - The functions that use unboxed sums are CAFFY I'd suggest updating to next GHC when it's released. Simon, > It's #9718, and I wonder if we should devote some effort to nailing it? It's not that hard, and the status quo is a continuing source of fragility. I can work on this. > That is pretty terrible. I suggest making a separate ticket and fixing it asap. I'll do that now. The new function/primop we'll use instead of `absentError` won't be CAFFY so it'll fix this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 1 06:04:49 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 May 2018 06:04:49 -0000 Subject: [GHC] #15081: Finite list becomes infinite after maping fractional function for high numbers In-Reply-To: <044.f762bf620383822c5337aa8807210278@haskell.org> References: <044.f762bf620383822c5337aa8807210278@haskell.org> Message-ID: <059.a39f93400e29faaa8615673fa688e5a9@haskell.org> #15081: Finite list becomes infinite after maping fractional function for high numbers -------------------------------------+------------------------------------- Reporter: Onsed | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | libraries/base/tests/enumNumeric Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4650 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sighingnow): * testcase: => libraries/base/tests/enumNumeric * status: new => patch * differential: => Phab:D4650 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 1 06:12:53 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 May 2018 06:12:53 -0000 Subject: [GHC] #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) In-Reply-To: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> References: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> Message-ID: <057.66c710989352d57682377b2d5e52c343@haskell.org> #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 (CodeGen) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: T13658 at runtime | T14779a T14779b T14868 debug | parsing001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4651 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => patch * differential: => Phab:D4651 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 1 07:36:14 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 May 2018 07:36:14 -0000 Subject: [GHC] #15081: Finite list becomes infinite after maping fractional function for high numbers In-Reply-To: <044.f762bf620383822c5337aa8807210278@haskell.org> References: <044.f762bf620383822c5337aa8807210278@haskell.org> Message-ID: <059.7278059f201d73055929132c6ccb96d4@haskell.org> #15081: Finite list becomes infinite after maping fractional function for high numbers -------------------------------------+------------------------------------- Reporter: Onsed | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | libraries/base/tests/enumNumeric Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4650 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Thanks for the patch. I've commented (silently). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 1 07:43:48 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 May 2018 07:43:48 -0000 Subject: [GHC] #14975: Refactor (Maybe Coercion) In-Reply-To: <047.51816057ba89e62ff311692e8071c67c@haskell.org> References: <047.51816057ba89e62ff311692e8071c67c@haskell.org> Message-ID: <062.006787c98b0a190af0d2aa7454e167a4@haskell.org> #14975: Refactor (Maybe Coercion) -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11735 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Replying to [comment:7 ningning]: > Hi there. This is Ningning. I am one of the students of GSoC this year under advised by Richard. Find more information about [https://summerofcode.withgoogle.com/projects/#5851493949767680/ my proposal]. > > Thanks to tdammers, I am taking this ticket as my warm-up exercise :). Great! The code I have so far is on the GHC git repo, in the wip/T14975 branch. Though not strictly necessary for this, you may want to also look into tickets #11735, #14737 and #15019 for context. Let us know if there's anything else you need. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 1 09:29:04 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 May 2018 09:29:04 -0000 Subject: [GHC] #15108: Panic: collectNBinders In-Reply-To: <050.b2ce8b77cab404f5ee4296cbccf39745@haskell.org> References: <050.b2ce8b77cab404f5ee4296cbccf39745@haskell.org> Message-ID: <065.e3da8aec811a0b6dd9d52d00d6e78c0f@haskell.org> #15108: Panic: collectNBinders -------------------------------------+------------------------------------- Reporter: cdisselkoen | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.4.2 Resolution: | Keywords: panic | collectNBinders Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 1 09:30:56 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 May 2018 09:30:56 -0000 Subject: [GHC] #11323: powerpc64: recomp015 fails with redundant linking In-Reply-To: <047.1148580a44ecdf753373d9211c559f12@haskell.org> References: <047.1148580a44ecdf753373d9211c559f12@haskell.org> Message-ID: <062.fa75f79c062c776b3ef9fd1a8d0324c7@haskell.org> #11323: powerpc64: recomp015 fails with redundant linking -------------------------------------+------------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: Compile-time | Test Case: performance bug | driver/recomp15 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * owner: trommler => (none) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 1 09:57:21 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 May 2018 09:57:21 -0000 Subject: [GHC] #15109: T12425 is failing on CI since 3d38e8284b73 Message-ID: <043.96a8c019ca8d67abbdeb868f82e51005@haskell.org> #15109: T12425 is failing on CI since 3d38e8284b73 -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- T12425 (a perf test) is failing on Linux CI box. tdammers realized it started failing with [https://phabricator.haskell.org/rGHC3d38e8284b7382844f9862e8d8afbae9c7248b09 3d38e8284b73]. It seems like Simon is aware of the performance implications so perhaps we should just bump the numbers. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 1 11:47:13 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 May 2018 11:47:13 -0000 Subject: [GHC] #10572: Type signatures are not implicitly quantified over TH type variables In-Reply-To: <045.ba132a89df5c5be9ce7705320ad52764@haskell.org> References: <045.ba132a89df5c5be9ce7705320ad52764@haskell.org> Message-ID: <060.59e5bb95a1561cefc8c7d8bbf715034e@haskell.org> #10572: Type signatures are not implicitly quantified over TH type variables -------------------------------------+------------------------------------- Reporter: spinda | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | tests/th/T10572a, tests/th/T10572a Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4641 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: goldfire (added) Comment: Thanks for the patch. I've had a look, and I really wonder whether the gain is worth the pain. The pain is significant: a whole extra usually-wasted pass `trySpliceTy` over every `HsType` to expand any splices, before renaming. And I'm not even certain that will work; what about {{{ f :: $(g 'a) -> a }}} Here `g 'a` might expand to some type involving `a`; but it does require `a` to be in scope already. In the examples, wouldn't it all be clearer if we had an explicit forall? Thus {{{ const'' :: forall a. [tv|a|] -> b -> [tv|a|] }}} Overall, I feel unsure about this. Richard, you are TH supremo, and you wrote the still-rather-cyptic note {{{ Note [rnSplicePat] ~~~~~~~~~~~~~~~~~~ Renaming a pattern splice is a bit tricky, because we need the variables bound in the pattern to be in scope in the RHS of the pattern. This scope management is effectively done by using continuation-passing style in RnPat, through the CpsRn monad. We don't wish to be in that monad here (it would create import cycles and generally conflict with renaming other splices), so we really want to return a (Pat RdrName) -- the result of running the splice -- which can then be further renamed in RnPat, in the CpsRn monad. The problem is that if we're renaming a splice within a bracket, we *don't* want to run the splice now. We really do just want to rename it to an HsSplice Name. Of course, then we can't know what variables are bound within the splice. So we accept any unbound variables and rename them again when the bracket is spliced in. If a variable is brought into scope by a pattern splice all is fine. If it is not then an error is reported. In any case, when we're done in rnSplicePat, we'll either have a Pat RdrName (the result of running a top-level splice) or a Pat Name (the renamed nested splice). Thus, the awkward return type of rnSplicePat. }}} (NB: the pattern situation is much less bad than the propose solution for types, because it doesn't require a whole extra pass.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 1 12:07:06 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 May 2018 12:07:06 -0000 Subject: [GHC] #14547: Wrong warning by -Wincomplete-patterns In-Reply-To: <052.21a9ad8704f084ec9db31f385a693f01@haskell.org> References: <052.21a9ad8704f084ec9db31f385a693f01@haskell.org> Message-ID: <067.54f68c13ed6bc50a40761abeff65ccef@haskell.org> #14547: Wrong warning by -Wincomplete-patterns -------------------------------------+------------------------------------- Reporter: YoshikuniJujo | Owner: (none) Type: bug | Status: patch Priority: low | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: incomplete- | patterns OverloadedLists, | PatternMatchWarnings TypeFamilies Operating System: Linux | Architecture: x86 Type of failure: Incorrect | Test Case: error/warning at compile-time | deSugar/should_compile/T14547 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4624 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Alas, with `RebindableSyntax` we don't know ''anything'' about `toList`. (Without `RebindableSyntax` I think your reasoning is correct.) But now I am worried about {{{ f (x:xs) = .. f [p,q] = ... }}} The `(x:xs)` pattern will translate as an ordinary cons pattern. The `[p,q]` pattern will be subject to overloaded lists. So if `RebindableSyntax` is on and `toList` does something strange, simply dropping the `toList` altogether, and desugaring to {{{ f (x:xs) = .. f (p:q:[]) = ... }}} may not be right. So in the presence of `RebindableSyntax` I think we should treat `ListPat` like any other view pattern; i.e. coverage/exhaustiveness does not help much. In the absence of `RebindableSyntax`, but with `-XOverloadedStrings`, can we be sure that `toList` is the identity function if the pattern type is a list type? I think so. In which case your simplified version is fine. Bottom line: check for `NoRebindableSyntax`! > Another silly question is that I still can't see why we need to concern about the view pattern for exhaustiveness checking of overloaded list. I think the toList and the [a] instance of IsList are different with ordinary view functions in view pattern. I could not parse the question. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 1 12:18:58 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 May 2018 12:18:58 -0000 Subject: [GHC] #15108: Panic: collectNBinders In-Reply-To: <050.b2ce8b77cab404f5ee4296cbccf39745@haskell.org> References: <050.b2ce8b77cab404f5ee4296cbccf39745@haskell.org> Message-ID: <065.0e51fbc0e09000c582217181edfca363@haskell.org> #15108: Panic: collectNBinders -------------------------------------+------------------------------------- Reporter: cdisselkoen | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.4.2 Resolution: | Keywords: panic | collectNBinders Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"07cc6039dccff82790bf1d84a81e26df234ad899/ghc" 07cc603/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="07cc6039dccff82790bf1d84a81e26df234ad899" Don't crash when pretty-printing bad joins Trac #15108 showed that the Core pretty-printer would crash if it found a join-point binding with too few lambda on the RHS. That is super-unhelpful! Lint will find it, but pretty-printing should not crash. This patch just makes the pretty printer behave more robustly; it leaves the job of error reporting to Lint. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 1 12:18:58 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 May 2018 12:18:58 -0000 Subject: [GHC] #15108: Panic: collectNBinders In-Reply-To: <050.b2ce8b77cab404f5ee4296cbccf39745@haskell.org> References: <050.b2ce8b77cab404f5ee4296cbccf39745@haskell.org> Message-ID: <065.0b91e667b41963de2a2799db1282f5e6@haskell.org> #15108: Panic: collectNBinders -------------------------------------+------------------------------------- Reporter: cdisselkoen | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.4.2 Resolution: | Keywords: panic | collectNBinders Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"d4cc74f1a5d1aafc8a2fde3c80019e2ef88d146b/ghc" d4cc74f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d4cc74f1a5d1aafc8a2fde3c80019e2ef88d146b" Preserve join-point arity in CoreOpt Trac #15108 showed that the simple optimiser in CoreOpt was accidentally eta-reducing a join point, so it didn't meet its arity invariant. This patch fixes it. See Note [Preserve join-binding arity]. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 1 12:23:04 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 May 2018 12:23:04 -0000 Subject: [GHC] #15108: Panic: collectNBinders In-Reply-To: <050.b2ce8b77cab404f5ee4296cbccf39745@haskell.org> References: <050.b2ce8b77cab404f5ee4296cbccf39745@haskell.org> Message-ID: <065.d17f509dfff047dcfe40637f5a4ce45a@haskell.org> #15108: Panic: collectNBinders -------------------------------------+------------------------------------- Reporter: cdisselkoen | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Profiling | Version: 8.4.2 Resolution: fixed | Keywords: panic | collectNBinders Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed * milestone: => 8.6.1 Comment: OK, fixed. Thanks for a great report. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 1 12:37:50 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 May 2018 12:37:50 -0000 Subject: [GHC] #15108: Panic: collectNBinders In-Reply-To: <050.b2ce8b77cab404f5ee4296cbccf39745@haskell.org> References: <050.b2ce8b77cab404f5ee4296cbccf39745@haskell.org> Message-ID: <065.e63ec4e17ef676baefb6168b9b1a75f8@haskell.org> #15108: Panic: collectNBinders -------------------------------------+------------------------------------- Reporter: cdisselkoen | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Profiling | Version: 8.4.2 Resolution: fixed | Keywords: panic | collectNBinders Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Have you considered adding {{{ | JoinNonRec v [v] (Expr v) | JoinRec [(v, [v], Expr v)] }}} to `Bind v`? It seems that a great lot of code has to zoom past the binders of a join point, causing bugs. With these constructors, one would be forced to handle them properly – and code that does not need to pay attention can use a pattern synonym that recreates the original view. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 1 12:49:11 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 May 2018 12:49:11 -0000 Subject: [GHC] #15108: Panic: collectNBinders In-Reply-To: <050.b2ce8b77cab404f5ee4296cbccf39745@haskell.org> References: <050.b2ce8b77cab404f5ee4296cbccf39745@haskell.org> Message-ID: <065.24a077341b0f38da94bbb7027472a8ed@haskell.org> #15108: Panic: collectNBinders -------------------------------------+------------------------------------- Reporter: cdisselkoen | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Profiling | Version: 8.4.2 Resolution: fixed | Keywords: panic | collectNBinders Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I suppose we could, but a key aspect of the current join points is that their semantics is exactly that of let-bindings; and often code (e.g. strictness analysis) can work uniformly for both. Yes, there are many ways in which we could change the representation. E.g. maybe `Lam` should take a list of binders, or `App` should take a list of arguments. But my instinct is that you save code in some places and lose it in others. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 1 12:50:07 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 May 2018 12:50:07 -0000 Subject: [GHC] #15108: Panic: collectNBinders In-Reply-To: <050.b2ce8b77cab404f5ee4296cbccf39745@haskell.org> References: <050.b2ce8b77cab404f5ee4296cbccf39745@haskell.org> Message-ID: <065.c9cfbf2462d1051d116dff0a7ff76287@haskell.org> #15108: Panic: collectNBinders -------------------------------------+------------------------------------- Reporter: cdisselkoen | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Profiling | Version: 8.4.2 Resolution: fixed | Keywords: panic | collectNBinders Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Yeah, it’d probably amount to shifting boxes around without making any new space :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 1 13:38:28 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 May 2018 13:38:28 -0000 Subject: [GHC] #12457: Deriving should be (more closely) integrated with other metaprogramming methods In-Reply-To: <049.722143f91b930762e66d90cff1b491ea@haskell.org> References: <049.722143f91b930762e66d90cff1b491ea@haskell.org> Message-ID: <064.82c48591d517d68be48df3862cfff37d@haskell.org> #12457: Deriving should be (more closely) integrated with other metaprogramming methods -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I suppose it depends on what you mean by "solved" :) It's true that `DerivingVia` provides a much higher degree of configurability than other deriving strategies, but it falls short of some goals: * If one's goal is to have a equivalent of, say, `deriving Ord` that produces equally efficient code, then `DerivingVia` isn't up to the task. Ultimately, the closest you could get is by leveraging `GHC.Generics` under the hood, which isn't always going to produce as efficient of code as a non-generics–based `Ord` instance. * Speaking of which, combining `GHC.Generics` with `DerivingVia` will only get you so far. You wouldn't be able to use this approach to derive `Bifunctor`, for instance, since we only have the `Generic` and `Generic1` classes for handling classes of kinds `* -> Constraint` and `(k -> *) -> Constraint`, respectively. * Ultimately, `DerivingVia` still relies on compiler magic. The original ambition here was to make `deriving` syntactic sugar for a Template Haskell splice so that the code underlying `deriving` could be expressed as a normal TH program. (That way, folks could extend it quite naturally.) There's still a long ways to go before that is possible. I'm not sure if those are what you had in mind when opening this ticket, so if they're not, feel free to close this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 1 13:39:05 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 May 2018 13:39:05 -0000 Subject: [GHC] #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) In-Reply-To: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> References: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> Message-ID: <057.acff186cf1d40de1d2a3d3fd6544ab0d@haskell.org> #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 (CodeGen) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: T13658 at runtime | T14779a T14779b T14868 debug | parsing001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: patch => new * differential: Phab:D4651 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 1 13:39:26 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 May 2018 13:39:26 -0000 Subject: [GHC] #15102: GHC panic when compiling gi-pango-1.0.15 In-Reply-To: <050.5b70d2ad161b21b5ae58473955663635@haskell.org> References: <050.5b70d2ad161b21b5ae58473955663635@haskell.org> Message-ID: <065.88ae08e3477381d99722279ef2acbad3@haskell.org> #15102: GHC panic when compiling gi-pango-1.0.15 -------------------------------------+------------------------------------- Reporter: PaulJohnson | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14382 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #14382 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 1 14:25:15 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 May 2018 14:25:15 -0000 Subject: [GHC] #15038: Memory Corruption (strange closure type) In-Reply-To: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> References: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> Message-ID: <064.8cc958218f9facc29a0dd7ea4250cf1e@haskell.org> #15038: Memory Corruption (strange closure type) -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #9718 | Differential Rev(s): Phab:D4652 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => patch * differential: => Phab:D4652 Comment: Simon, I submitted a fix for the absent error problem, but did not make a new ticket because it also fixes this. I'll continue with #9718. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 1 14:31:39 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 May 2018 14:31:39 -0000 Subject: [GHC] #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) In-Reply-To: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> References: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> Message-ID: <057.8d20847d54e14e1803454c41166b6b02@haskell.org> #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 (CodeGen) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: T13658 at runtime | T14779a T14779b T14868 debug | parsing001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Apparently I interpreted the uleb128 argument wrong. int-e has a fix and will submit soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 1 14:39:45 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 May 2018 14:39:45 -0000 Subject: [GHC] #15038: Memory Corruption (strange closure type) In-Reply-To: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> References: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> Message-ID: <064.be8901992f8eecd08abc7313267aba98@haskell.org> #15038: Memory Corruption (strange closure type) -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #9718 | Differential Rev(s): Phab:D4652 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > I also realized that unarise uses absentError wrong: absentError expects an Addr# argument (for a string that represents the "absent" argument) but unarise just uses absentError without an argument. So there's also a type error. I think your patch is to fix this problem. But I see nothing about giving it an argument of the right type ... I see stuff about not giving it an argument at all for some reason; and strange stable pointers. If we are going to fix #9718, how much of this do we need? Perhaps very little? At least, if there's 1. something that is necessary regardless; and 2. something that's a temporary sticking plaster to deal with the absence of #9718 then let's keep them separate so we can revert (2) when we get #9718. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 1 14:55:10 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 May 2018 14:55:10 -0000 Subject: [GHC] #15038: Memory Corruption (strange closure type) In-Reply-To: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> References: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> Message-ID: <064.78e293cc2fc81e2496f2ec1e5c5b9ae0@haskell.org> #15038: Memory Corruption (strange closure type) -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #9718 | Differential Rev(s): Phab:D4652 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I responded in the diff. > If we are going to fix #9718, how much of this do we need? Perhaps very little? I don't think fixing #9718 would fix this bug because this bug happens in unarise which happens much later than both TidyPgm and CorePrep. I think to avoid this bug we need a way to ensure we don't make things more CAFFY after CAFFYness information is calculated in TidyPgm. This includes all the Stg-to-Stg transforms (CSE, unarise, perhaps new passes added in the future). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 1 14:59:04 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 May 2018 14:59:04 -0000 Subject: [GHC] #15038: Memory Corruption (strange closure type) In-Reply-To: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> References: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> Message-ID: <064.f8a8d3d20fd1b15fad0b37e9ac0bdc53@haskell.org> #15038: Memory Corruption (strange closure type) -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #9718 | Differential Rev(s): Phab:D4652 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > I think to avoid this bug we need a way to ensure we don't make things more CAFFY after CAFFYness information is calculated in TidyPgm The whole point of #9718 is to ''stop'' `TidyPgm` predicting CAF-hood. Instead compute CAF-hood just before code generation, after all transformations (including any on STG) have settled down. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 1 15:06:22 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 May 2018 15:06:22 -0000 Subject: [GHC] #15110: Exitification abstracts over shadowed variables Message-ID: <046.1f66d36ba677e4f82515b4854d1fe4c2@haskell.org> #15110: Exitification abstracts over shadowed variables -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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: -------------------------------------+------------------------------------- Simon did some code review of `Exitify.hs` in https://ghc.haskell.org/trac/ghc/ticket/14152#comment:36 and he was onto something; the code is wrong after all: Consider this core term {{{ joinrec j (x :: Bool) (x :: Int) = if x == 0 then foo x else jump j True (x - 1) in … }}} where the two parameters `x` and `x` are different variables, but shadow each other (i.e. have the same unique). This is legal Core! But Exitification chooses the variables to abstract over in this line: {{{ -- The possible arguments of this exit join point -- No need for `sortQuantVars`, `captured` is already in dependency order abs_vars = map zap $ filter (`elemVarSet` fvs) captured }}} where `captured = [x::Bool,x::Int]` in this case, which would yield this code {{{ join exit (x :: Bool) (x :: Int) = foo x in joinrec j (x :: Bool) (x :: Int) = if x == 0 then jump exit (x::Bool) (x::Int) else jump j True (x - 1) in … }}} which is no longer type correct (or even “scope-correct”) any more, as it passes the `Int`-typed `x` as the `Bool` argument to `exit`. The conditions where this happens, i.e. such shadowing, is rather obscure so I did not even try to produce a lint error here. It also means that this is rather low severity, but I’ll still go and fix it. An application of `reverseNub` seems to be in order – or simply switching to keeping `captured` in a `DVarSet` rather than a list (in which case `sortQuantVars` would be required…) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 1 15:11:05 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 May 2018 15:11:05 -0000 Subject: [GHC] #15038: Memory Corruption (strange closure type) In-Reply-To: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> References: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> Message-ID: <064.2c98f643e4fca87fe06f67046c96f533@haskell.org> #15038: Memory Corruption (strange closure type) -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #9718 | Differential Rev(s): Phab:D4652 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Fair enough. Sorry I'm confused because the title says "predicting what CorePrep will do" not "predicting what CodePrep and later stages (including code generator) do". I think for efficiency reasons unboxed sums should really not make things CAFFY (similar to how unboxed tuples or unboxed literals do not make things CAFFY) so whatever we'll be using for the absent pointer values should not be considered as CAFFY in the code generator. Phab:D4652 fixes this so I think it's "something that is necessary regardless" and not a temporary workaround (e.g. would not be reverted after #9718). As mentioned in the diff there's an alternative implementation that I think wouldn't need the business with stable pointers, while still fixing the problems with the type error and making things CAFFY. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 1 15:44:43 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 May 2018 15:44:43 -0000 Subject: [GHC] #15111: GHCi leaks the first modules loaded Message-ID: <047.0c4c39abd5bd384dc6fc34801a3d6baa@haskell.org> #15111: GHCi leaks the first modules loaded -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: ghci | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- How to reproduce the leak: {{{ cd nofib/real/veritas ghci +RTS -S Prelude> :load Main *Main> System.Mem.performGC 10554832 32639712 38824584 0.048 0.058 2.317 8.386 0 0 (Gen: 1) }}} Live data is ~38Mb (3rd number). Now unload everything: {{{ *Main> :load Prelude> System.Mem.performGC 4005376 32681280 38850224 0.013 0.048 2.330 29.896 0 0 (Gen: 1) }}} Note the live data didn't go down. Load the program again: {{{ Prelude> :load Main ... *Main> System.Mem.performGC 16344112 47790304 54799632 0.070 0.074 4.343 82.235 0 0 (Gen: 1) }}} Note the live memory is almost 2x what it was before. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 1 15:44:53 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 May 2018 15:44:53 -0000 Subject: [GHC] #15111: GHCi leaks the first modules loaded In-Reply-To: <047.0c4c39abd5bd384dc6fc34801a3d6baa@haskell.org> References: <047.0c4c39abd5bd384dc6fc34801a3d6baa@haskell.org> Message-ID: <062.9bc4106e42658a3b91c9e8d048ef12a2@haskell.org> #15111: GHCi leaks the first modules loaded -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: ghci Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * owner: (none) => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 1 16:43:02 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 May 2018 16:43:02 -0000 Subject: [GHC] #15107: Testsuite failures on Windows In-Reply-To: <046.8e0cbe335a7ce09f5a7e747d4e07162e@haskell.org> References: <046.8e0cbe335a7ce09f5a7e747d4e07162e@haskell.org> Message-ID: <061.bd59bfa9e427af21a58d4223972a0fef@haskell.org> #15107: Testsuite failures on Windows -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): I used to track these daily but stopped about 20 days ago. But before I did there were only about 12 to 13 failures, and some were due to issues in msys2, like the complicated way the backpack tests are written w.r.t to shell interactions. https://github.com/Mistuke/GhcWindowsBuild/blob/master/testresults/testsuite_summary.x64.windows.2018.04.01.txt are the ones I know and expect to fail it looks like somthing broke in the rts. Harbormaster shows the same errors now, but I don't build nightlies anymore. Ideally, we'd stop ignoring the test results in Habormaster. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 1 18:00:55 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 May 2018 18:00:55 -0000 Subject: [GHC] #15107: Testsuite failures on Windows In-Reply-To: <046.8e0cbe335a7ce09f5a7e747d4e07162e@haskell.org> References: <046.8e0cbe335a7ce09f5a7e747d4e07162e@haskell.org> Message-ID: <061.a9b79e58cea9dbb3fe1d92529b029c92@haskell.org> #15107: Testsuite failures on Windows -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Ok, so some, like the ghci ones are just caused by an output change, `-fexternal-dynamic-refs` seemt o have been removed but the tests not updates. those just need to accept the new test output. The majority of the rest is due to `TEST_HC` expansion broken in `--info` which will be fixed by same fix as #15101. That gets the list back to what I expect. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 1 19:17:01 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 May 2018 19:17:01 -0000 Subject: [GHC] #15094: unknown symbol `___divmoddi4' error with clock on 32-bit windows In-Reply-To: <047.8ee6c03f4894789ea17cc392d368199d@haskell.org> References: <047.8ee6c03f4894789ea17cc392d368199d@haskell.org> Message-ID: <062.be026cea55e7abd66a3f9537121b80f1@haskell.org> #15094: unknown symbol `___divmoddi4' error with clock on 32-bit windows ---------------------------------+------------------------------ Reporter: simonmic | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+------------------------------ Comment (by RyanGlScott): I might be slow on the uptake here, but I don't see how the `clock` library is using `divmod` (directly, at least). The only `foreign import`s that `clock` uses reference [https://github.com/corsis/clock/blob/00435ddf926b3603a3576d98e44763d165d2ec2c/cbits/hs_clock_win32.c its own C file], which is: {{{#!c #ifdef _WIN32 #include #if defined(_MSC_VER) || defined(_MSC_EXTENSIONS) #define U64(x) x##Ui64 #else #define U64(x) x##ULL #endif #define DELTA_EPOCH_IN_100NS U64(116444736000000000) static long ticks_to_nanos(LONGLONG subsecond_time, LONGLONG frequency) { return (long)((1e9 * subsecond_time) / frequency); } static ULONGLONG to_quad_100ns(FILETIME ft) { ULARGE_INTEGER li; li.LowPart = ft.dwLowDateTime; li.HighPart = ft.dwHighDateTime; return li.QuadPart; } static void to_timespec_from_100ns(ULONGLONG t_100ns, long long *t) { t[0] = (long)(t_100ns / 10000000UL); t[1] = 100*(long)(t_100ns % 10000000UL); } void hs_clock_win32_gettime_monotonic(long long* t) { LARGE_INTEGER time; static LARGE_INTEGER frequency; static int hasFreq = 0; QueryPerformanceCounter(&time); if (!hasFreq) { hasFreq = 1; QueryPerformanceFrequency(&frequency); } // seconds t[0] = time.QuadPart / frequency.QuadPart; // nanos = t[1] = ticks_to_nanos(time.QuadPart % frequency.QuadPart, frequency.QuadPart); } void hs_clock_win32_gettime_realtime(long long* t) { FILETIME ft; ULONGLONG tmp; GetSystemTimeAsFileTime(&ft); tmp = to_quad_100ns(ft); tmp -= DELTA_EPOCH_IN_100NS; to_timespec_from_100ns(tmp, t); } void hs_clock_win32_gettime_processtime(long long* t) { FILETIME creation_time, exit_time, kernel_time, user_time; ULONGLONG time; GetProcessTimes(GetCurrentProcess(), &creation_time, &exit_time, &kernel_time, &user_time); // Both kernel and user, acc. to http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#tag_03_117 time = to_quad_100ns(user_time) + to_quad_100ns(kernel_time); to_timespec_from_100ns(time, t); } void hs_clock_win32_gettime_threadtime(long long* t) { FILETIME creation_time, exit_time, kernel_time, user_time; ULONGLONG time; GetThreadTimes(GetCurrentThread(), &creation_time, &exit_time, &kernel_time, &user_time); // Both kernel and user, acc. to http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#tag_03_117 time = to_quad_100ns(user_time) + to_quad_100ns(kernel_time); to_timespec_from_100ns(time, t); } void hs_clock_win32_getres_monotonic(long long* t) { LARGE_INTEGER frequency; QueryPerformanceFrequency(&frequency); ULONGLONG resolution = U64(1000000000)/frequency.QuadPart; t[0] = resolution / U64(1000000000); t[1] = resolution % U64(1000000000); } void hs_clock_win32_getres_realtime(long long* t) { t[0] = 0; t[1] = 100; } void hs_clock_win32_getres_processtime(long long* t) { t[0] = 0; t[1] = 100; } void hs_clock_win32_getres_threadtime(long long* t) { t[0] = 0; t[1] = 100; } #endif /* _WIN32 */ }}} Surely this shouldn't require linking against `gcc` to work, no? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 1 19:21:35 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 May 2018 19:21:35 -0000 Subject: [GHC] #10241: BlockedIndefinitelyOnMVar thrown to the thread which is not blocked indefinitely In-Reply-To: <049.aa2da898b4545668797a015c17e2bd6d@haskell.org> References: <049.aa2da898b4545668797a015c17e2bd6d@haskell.org> Message-ID: <064.03701b192f11f07b771d99f50aaad905@haskell.org> #10241: BlockedIndefinitelyOnMVar thrown to the thread which is not blocked indefinitely -------------------------------------+------------------------------------- Reporter: asukamirai | Owner: simonmar Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #10793 | Differential Rev(s): Phab:D4644 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): This comes up from time to time. We can't pick an order to resurrect threads in because we don't know which one to resurrect first (as I commented on Phab:D4644). e.g. if we happened to resurrect the main thread first in this example, the result would be exactly the same. We could do multiple traversals of the heap to figure out the relationship, but that's not practical. The only deterministic thing to do is to treat all unreachable threads as deadlocked and send them all an exception at the same time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 1 20:04:20 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 May 2018 20:04:20 -0000 Subject: [GHC] #15086: hT profiling option In-Reply-To: <047.6ebe77afde6007a7c0d9af0949915a5b@haskell.org> References: <047.6ebe77afde6007a7c0d9af0949915a5b@haskell.org> Message-ID: <062.779305f31282d6ed7e26495693d77823@haskell.org> #15086: hT profiling option -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4643 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"260e23b4033f92c1d7326a60320067922ef06da2/ghc" 260e23b4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="260e23b4033f92c1d7326a60320067922ef06da2" rts: Add -hT to the rts usage message Reviewers: erikd, simonmar Subscribers: thomie, carter GHC Trac Issues: #15086 Differential Revision: https://phabricator.haskell.org/D4643 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 1 20:30:11 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 May 2018 20:30:11 -0000 Subject: [GHC] #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) In-Reply-To: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> References: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> Message-ID: <057.e27977b1a9d5ca860b4ec542c14f6385@haskell.org> #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 (CodeGen) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: T13658 at runtime | T14779a T14779b T14868 debug | parsing001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D4654 Wiki Page: | -------------------------------------+------------------------------------- Changes (by int-e): * status: new => patch * differential: => D4654 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 1 20:48:13 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 May 2018 20:48:13 -0000 Subject: [GHC] #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) In-Reply-To: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> References: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> Message-ID: <057.060da6599c9c165a684f39f30093865e@haskell.org> #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 (CodeGen) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: T13658 at runtime | T14779a T14779b T14868 debug | parsing001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4654 Wiki Page: | -------------------------------------+------------------------------------- Changes (by int-e): * differential: D4654 => Phab:D4654 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 1 20:58:27 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 May 2018 20:58:27 -0000 Subject: [GHC] #15094: unknown symbol `___divmoddi4' error with clock on 32-bit windows In-Reply-To: <047.8ee6c03f4894789ea17cc392d368199d@haskell.org> References: <047.8ee6c03f4894789ea17cc392d368199d@haskell.org> Message-ID: <062.b3a33118b53e053b0ed3795ab653b688@haskell.org> #15094: unknown symbol `___divmoddi4' error with clock on 32-bit windows ---------------------------------+------------------------------ Reporter: simonmic | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+------------------------------ Comment (by Phyx-): It does. It's right there in {{{ void hs_clock_win32_gettime_monotonic(long long* t) { LARGE_INTEGER time; LARGE_INTEGER frequency; QueryPerformanceCounter(&time); QueryPerformanceFrequency(&frequency); // seconds t[0] = time.QuadPart / frequency.QuadPart; // nanos = t[1] = ticks_to_nanos(time.QuadPart % frequency.QuadPart, frequency.QuadPart); } }}} At the optimization level `clock` is requesting, namely `-O3` GCC will do multiplication widening optimizations. This optimize `time.QuadPart / frequency.QuadPart` and `time.QuadPart % frequency.QuadPart` into a single `divmod`. It even says so {{{ Pass statistics of "widening_mul": ---------------- divmod calls inserted: 1 hs_clock_win32_gettime_monotonic (long long intD.8 * tD.60113) { # PT = nonlocal null long long intD.8 * t_9(D) = tD.60113; union LARGE_INTEGERD.2224 frequencyD.60117; union LARGE_INTEGERD.2224 timeD.60116; long long intD.8 _1; long long intD.8 _2; long long intD.8 _3; long long intD.8 _4; long long intD.8 _5; doubleD.23 _11; doubleD.23 _15; doubleD.23 _16; doubleD.23 _17; long intD.3 _18; __complex__ long long intD.8 divmod_tmp_19; ;; basic block 2, loop depth 0, count 0, freq 10000, maybe hot ;; prev block 0, next block 1, flags: (NEW, REACHABLE, VISITED) ;; pred: ENTRY [100.0%] (FALLTHRU,EXECUTABLE) # .MEM_7 = VDEF <.MEM_6(D)> # USE = nonlocal { D.60116 D.60117 } (escaped) # CLB = nonlocal { D.60116 D.60117 } (escaped) QueryPerformanceCounter at 4D.8347 (&timeD.60116); # .MEM_8 = VDEF <.MEM_7> # USE = nonlocal { D.60116 D.60117 } (escaped) # CLB = nonlocal { D.60116 D.60117 } (escaped) QueryPerformanceFrequency at 4D.8349 (&frequencyD.60117); # VUSE <.MEM_8> _1 = timeD.60116.QuadPartD.2223; # VUSE <.MEM_8> _2 = frequencyD.60117.QuadPartD.2223; divmod_tmp_19 = DIVMOD (_1, _2); <---- divmod inserted here. - Phyx _3 = REALPART_EXPR ; # .MEM_10 = VDEF <.MEM_8> *t_9(D) = _3; # RANGE [-9223372036854775807, 9223372036854775807] _4 = IMAGPART_EXPR ; _11 = (doubleD.23) _4; _15 = _11 * 1.0e+9; _16 = (doubleD.23) _2; _17 = _15 / _16; _18 = (long intD.3) _17; # RANGE [-2147483648, 2147483647] _5 = (long long intD.8) _18; # .MEM_12 = VDEF <.MEM_10> MEM[(long long intD.8 *)t_9(D) + 8B] = _5; # .MEM_13 = VDEF <.MEM_12> timeD.60116 ={v} {CLOBBER}; # .MEM_14 = VDEF <.MEM_13> frequencyD.60117 ={v} {CLOBBER}; # VUSE <.MEM_14> return; ;; succ: EXIT [100.0%] (EXECUTABLE) } }}} This entire file, always uses 64 bit types. You have no hardware support for 64 bit `divmod`. The compiler is smart enough to know this and expands the built-in `DIVMOD` to a library call which is expected to do the operation. The implementation for the call is in `libgcc`. The explicit purpose for `libgcc` is to handle these calls the compiler emits to do the software emulation[1]. {{{ GCC provides a low-level runtime library, libgcc.a or libgcc_s.so.1 on some platforms. GCC generates calls to routines in this library automatically, whenever it needs to perform some operation that is too complicated to emit inline code for. Most of the routines in libgcc handle arithmetic operations that the target processor cannot perform directly. This includes integer multiply and divide on some machines, and all floating-point and fixed-point operations on other machines. libgcc also includes routines for exception handling, and a handful of miscellaneous operations. }}} So yes, using a complex operation that the architecture has no support for requires explicit software emulation, and thus requires compiling against `libgcc`. Or turning off the optimization. Possibly for that function alone using an attribute. Either way, this is not a GHC bug. [1] https://gcc.gnu.org/onlinedocs/gccint/Libgcc.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 1 21:56:22 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 May 2018 21:56:22 -0000 Subject: [GHC] #15110: Exitification abstracts over shadowed variables In-Reply-To: <046.1f66d36ba677e4f82515b4854d1fe4c2@haskell.org> References: <046.1f66d36ba677e4f82515b4854d1fe4c2@haskell.org> Message-ID: <061.782fb7b4ba269d3da4413f6c2f3f9aab@haskell.org> #15110: Exitification abstracts over shadowed variables -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Ha, quite true -- although you give me too much credit for spotting it. NB: in your explanation (which should end up in a Note, be sure to point out that Core distinguishes variables by their `Unique` so their `OccName` is irrelevant. What you write should be understood to mean that the two `x`'s are variable with the same `Unique`, rather than with the same `OccName`. It's difficult to make this happen, and the Simplifier removes such shadowing, but yes, it's valid. Easy fix: {{{ abs_vars = map zap proto_abs_vars (proto_abs_vars, _) = foldr add ([], fvs) captured add v (acc, fvs) = (acc', fvs `delVarSet` b) where acc' | v `elemVarSet` fvs = v : acc | otherwise = acc }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 1 22:02:46 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 May 2018 22:02:46 -0000 Subject: [GHC] #15110: Exitification abstracts over shadowed variables In-Reply-To: <046.1f66d36ba677e4f82515b4854d1fe4c2@haskell.org> References: <046.1f66d36ba677e4f82515b4854d1fe4c2@haskell.org> Message-ID: <061.a96fe3a3bd27dcdccf2ba6fbe4bb2352@haskell.org> #15110: Exitification abstracts over shadowed variables -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => JoinPoints -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 1 22:13:34 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 May 2018 22:13:34 -0000 Subject: [GHC] #15107: Testsuite failures on Windows In-Reply-To: <046.8e0cbe335a7ce09f5a7e747d4e07162e@haskell.org> References: <046.8e0cbe335a7ce09f5a7e747d4e07162e@haskell.org> Message-ID: <061.0e0372e5c647589742b8eef99359c6e5@haskell.org> #15107: Testsuite failures on Windows -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > those just need to accept the new test output. Great... can you do that? I don't know which ones and lack knowledge to do the right thing with confidence. > The majority of the rest is due to TEST_HC expansion broken in --info which will be fixed by same fix as #15101. Very good! > That gets the list back to what I expect. Well, could we mark them as expect-broken on Windows (suitably commented, and with ticket(s) if necessary), so that we validate green, and new failures show up clearly? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 1 23:26:33 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 May 2018 23:26:33 -0000 Subject: [GHC] #15094: unknown symbol `___divmoddi4' error with clock on 32-bit windows In-Reply-To: <047.8ee6c03f4894789ea17cc392d368199d@haskell.org> References: <047.8ee6c03f4894789ea17cc392d368199d@haskell.org> Message-ID: <062.ab7f19c4ae4b2a633f09116a7ef9abca@haskell.org> #15094: unknown symbol `___divmoddi4' error with clock on 32-bit windows ---------------------------------+------------------------------ Reporter: simonmic | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+------------------------------ Comment (by RyanGlScott): I see. In that case, how should `clock` be patched so as to ensure backwards compatibility with old versions of GHC? On 32-bit GHC 8.4.2, at least, this patch suffices: {{{#!diff diff --git a/clock.cabal b/clock.cabal index 67d232e..1b21682 100644 --- a/clock.cabal +++ b/clock.cabal @@ -74,6 +74,10 @@ library c-sources: cbits/hs_clock_darwin.c if os(windows) c-sources: cbits/hs_clock_win32.c + + -- See https://ghc.haskell.org/trac/ghc/ticket/15094 + if arch(i386) + extra-libraries: gcc_s_dw2-1 include-dirs: cbits ghc-options: -O3 -Wall }}} Should that work for other GHCs as well? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 2 02:37:58 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 May 2018 02:37:58 -0000 Subject: [GHC] #15110: Exitification abstracts over shadowed variables In-Reply-To: <046.1f66d36ba677e4f82515b4854d1fe4c2@haskell.org> References: <046.1f66d36ba677e4f82515b4854d1fe4c2@haskell.org> Message-ID: <061.d416bb508316d0fb59e7258589e2bddb@haskell.org> #15110: Exitification abstracts over shadowed variables -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"60f9e46a5a2867127ca04ce4b87b370ec8170e55/ghc" 60f9e46/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="60f9e46a5a2867127ca04ce4b87b370ec8170e55" Exitify: Do not trip over shadowing (fixes #15110) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 2 02:47:53 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 May 2018 02:47:53 -0000 Subject: [GHC] #15110: Exitification abstracts over shadowed variables In-Reply-To: <046.1f66d36ba677e4f82515b4854d1fe4c2@haskell.org> References: <046.1f66d36ba677e4f82515b4854d1fe4c2@haskell.org> Message-ID: <061.fe2dd6e0c5e3705e19f9522c9e8f2901@haskell.org> #15110: Exitification abstracts over shadowed variables -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: fixed | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 2 06:23:45 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 May 2018 06:23:45 -0000 Subject: [GHC] #15112: ghc 8.4.2 on OS X: clang: warning: argument unused during compilation: '-nopie' Message-ID: <047.e2e05ed138c24fadcd4842fa8e08b91d@haskell.org> #15112: ghc 8.4.2 on OS X: clang: warning: argument unused during compilation: '-nopie' -------------------------------------+------------------------------------- Reporter: elaforge | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- {{{ % cat Nopie.hs module Nopie where main :: IO () main = putStrLn "hi" % ghc -fforce-recomp -c -fhpc Nopie.hs clang: warning: argument unused during compilation: '-nopie' [-Wunused- command-line-argument] clang: warning: argument unused during compilation: '-nopie' [-Wunused- command-line-argument] }}} This happens for every source file when -fhpc is given, but also happens on links even when -fhpc isn't given. With -v, I see a call to gcc with -no-pie. When I run the same compile with ghc 8.4.1, I see the same call to gcc, only without that -no-pie flag, so this is new. It seems to be a harmless warning, but really clutters up the output. Incidentally, it looks like the particular spelling of -no-pie was added to LLVM a year ago due to ghc: https://reviews.llvm.org/D35462 Not sure if that's relevant. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 2 06:24:23 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 May 2018 06:24:23 -0000 Subject: [GHC] #15112: ghc 8.4.2 on OS X: clang: warning: argument unused during compilation: '-nopie' In-Reply-To: <047.e2e05ed138c24fadcd4842fa8e08b91d@haskell.org> References: <047.e2e05ed138c24fadcd4842fa8e08b91d@haskell.org> Message-ID: <062.3d68ae8f0c03f3cb5506c7c90706de1f@haskell.org> #15112: ghc 8.4.2 on OS X: clang: warning: argument unused during compilation: '-nopie' ---------------------------------+---------------------------------------- Reporter: elaforge | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by elaforge): * os: Unknown/Multiple => MacOS X -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 2 07:12:12 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 May 2018 07:12:12 -0000 Subject: [GHC] #15003: Data.List documentation should list complexities of more functions In-Reply-To: <043.7ec461499989f0acca4423edd3731e7e@haskell.org> References: <043.7ec461499989f0acca4423edd3731e7e@haskell.org> Message-ID: <058.ee1e3c37bd64dcc07c3a4ffb6c9043a7@haskell.org> #15003: Data.List documentation should list complexities of more functions -------------------------------------+------------------------------------- Reporter: gbaz | Owner: supersven Type: feature request | Status: new Priority: normal | Milestone: 8.4.3 Component: libraries/base | Version: 8.2.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by supersven): * owner: (none) => supersven -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 2 09:56:14 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 May 2018 09:56:14 -0000 Subject: [GHC] #15113: Do not make CAFs from literal strings Message-ID: <046.d042ad82da8658ea11bcd44bf2d86387@haskell.org> #15113: Do not make CAFs from literal strings -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Currently (as I discovered in #15038), we get the following code for `GHC.Exception.Base.patError`: {{{ lvl2_r3y3 :: [Char] [GblId] lvl2_r3y3 = unpackCString# lvl1_r3y2 -- RHS size: {terms: 7, types: 6, coercions: 2, joins: 0/0} patError :: forall a. Addr# -> a [GblId, Arity=1, Str=x, Unf=OtherCon []] patError = \ (@ a_a2kh) (s_a1Pi :: Addr#) -> raise# @ SomeException @ 'LiftedRep @ a_a2kh (Control.Exception.Base.$fExceptionPatternMatchFail_$ctoException ((untangle s_a1Pi lvl2_r3y3) `cast` (Sym (Control.Exception.Base.N:PatternMatchFail[0]) :: (String :: *) ~R# (PatternMatchFail :: *)))) }}} That stupid `lvl2_r3y3 :: String` is a CAF, and hence `patError` has CAF- refs, and hence so does any function that calls `patError`, and any function that calls them. That's bad! Lots more CAF entries in SRTs, lots more work traversing those SRTs in the garbage collector. And for what? To share the work of unpacking a C string! This is nuts. What to do? * Somehow refrain from floating `unpackCSTring# lit` to top level, even if you could otherwise do so. But that seems very ad-hoc, and it make the function bigger and less inlinable. * Treat a top level definition {{{ x :: [Char] x = unpackCString# y }}} as NOT a CAF, and make it single-entry so that the thunk is not updated. Then every use of `x` will unpack the string afresh, which is probably a good idea anyhow. I like this more. It would be implemented somewhere in the code generator. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 2 09:58:02 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 May 2018 09:58:02 -0000 Subject: [GHC] #15038: Memory Corruption (strange closure type) In-Reply-To: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> References: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> Message-ID: <064.2cb37d19d35861ae7e34c8cc977ccc85@haskell.org> #15038: Memory Corruption (strange closure type) -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #9718 | Differential Rev(s): Phab:D4652 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): >I think for efficiency reasons unboxed sums should really not make things CAFFY I rather agree. But the same is true for `patError` etc, not just `absentError`. I've opened a new ticket #15113. So if that was fixed, again this patch (or part of it) becomes a patch we'd want to revert. But perhaps not all of it? I'm not even sure any more :-(. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 2 10:19:48 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 May 2018 10:19:48 -0000 Subject: [GHC] #15113: Do not make CAFs from literal strings In-Reply-To: <046.d042ad82da8658ea11bcd44bf2d86387@haskell.org> References: <046.d042ad82da8658ea11bcd44bf2d86387@haskell.org> Message-ID: <061.1ddb484c7cc2918d8ba36f32871c2637@haskell.org> #15113: Do not make CAFs from literal strings -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * cc: osa1 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 2 11:45:58 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 May 2018 11:45:58 -0000 Subject: [GHC] #15105: `typecheckModule` from GHC API crashes on MacOS for files with TH In-Reply-To: <050.a57b50b77df5fd7c6386ac1485c8460f@haskell.org> References: <050.a57b50b77df5fd7c6386ac1485c8460f@haskell.org> Message-ID: <065.15a24e8bebc1d7337f898bb2db979786@haskell.org> #15105: `typecheckModule` from GHC API crashes on MacOS for files with TH ----------------------------------+---------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHC API | Version: 8.4.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+---------------------------------------- Comment (by darchon): We have some code in the Clash compiler to do with dynamic linking, which I expect is TH-related: https://github.com/clash-lang/clash- compiler/blame/d7dfef9d89b30d096370887899be24b9027914ac/clash-ghc/src- ghc/Clash/GHC/LoadModules.hs#L174-L179 {{{ let ghcDynamic = case lookup "GHC Dynamic" (DynFlags.compilerInfo dflags) of Just "YES" -> True _ -> False let dflags3 = if ghcDynamic then DynFlags.gopt_set dflags2 DynFlags.Opt_BuildDynamicToo else dflags2 _ <- GHC.setSessionDynFlags dflags3 }}} I don't have access to an OS X machine, so could you check if setting the {{{Opt_BuildDynamicToo}}} flag fixes the TH issue? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 2 11:48:52 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 May 2018 11:48:52 -0000 Subject: [GHC] #14970: GHC.Err.errorWithoutStackTrace produces stack trace when profiling enabled In-Reply-To: <046.a5415cff0c88c89467e1859ff9e5e10d@haskell.org> References: <046.a5415cff0c88c89467e1859ff9e5e10d@haskell.org> Message-ID: <061.e2fee561067425739f75bc36408b75e2@haskell.org> #14970: GHC.Err.errorWithoutStackTrace produces stack trace when profiling enabled -------------------------------------+------------------------------------- Reporter: rotaerk | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: libraries/base | Version: 8.2.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4648 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Marlow ): In [changeset:"dc655bf0310012b193cf49cce9f5b0bfbc53764c/ghc" dc655bf0/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="dc655bf0310012b193cf49cce9f5b0bfbc53764c" errorWithoutStackTrace: omit profiling stack trace (#14970) Test Plan: validate Reviewers: hvr, bgamari, erikd Subscribers: thomie, carter Differential Revision: https://phabricator.haskell.org/D4648 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 2 11:49:39 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 May 2018 11:49:39 -0000 Subject: [GHC] #14970: GHC.Err.errorWithoutStackTrace produces stack trace when profiling enabled In-Reply-To: <046.a5415cff0c88c89467e1859ff9e5e10d@haskell.org> References: <046.a5415cff0c88c89467e1859ff9e5e10d@haskell.org> Message-ID: <061.b979259d35714c1ab7f2e277c9a1a294@haskell.org> #14970: GHC.Err.errorWithoutStackTrace produces stack trace when profiling enabled -------------------------------------+------------------------------------- Reporter: rotaerk | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: libraries/base | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4648 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 2 11:58:13 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 May 2018 11:58:13 -0000 Subject: [GHC] #15111: GHCi leaks the first modules loaded In-Reply-To: <047.0c4c39abd5bd384dc6fc34801a3d6baa@haskell.org> References: <047.0c4c39abd5bd384dc6fc34801a3d6baa@haskell.org> Message-ID: <062.71068e8f7405d8172dc5c681f7fc9525@haskell.org> #15111: GHCi leaks the first modules loaded -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: ghci Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | Phab:D4658,Phab:D4659 -------------------------------------+------------------------------------- Changes (by simonmar): * differential: => Phab:D4658,Phab:D4659 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 2 11:58:29 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 May 2018 11:58:29 -0000 Subject: [GHC] #15111: GHCi leaks the first modules loaded In-Reply-To: <047.0c4c39abd5bd384dc6fc34801a3d6baa@haskell.org> References: <047.0c4c39abd5bd384dc6fc34801a3d6baa@haskell.org> Message-ID: <062.dbbcffa076068f786ea2eb9efaa120d2@haskell.org> #15111: GHCi leaks the first modules loaded -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: ghci Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4658 Wiki Page: | Phab:D4659 -------------------------------------+------------------------------------- Changes (by simonmar): * differential: Phab:D4658,Phab:D4659 => Phab:D4658 Phab:D4659 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 2 14:45:03 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 May 2018 14:45:03 -0000 Subject: [GHC] #15094: unknown symbol `___divmoddi4' error with clock on 32-bit windows In-Reply-To: <047.8ee6c03f4894789ea17cc392d368199d@haskell.org> References: <047.8ee6c03f4894789ea17cc392d368199d@haskell.org> Message-ID: <062.caa01c1d5109425d540cad2f50495cc3@haskell.org> #15094: unknown symbol `___divmoddi4' error with clock on 32-bit windows ---------------------------------+------------------------------ Reporter: simonmic | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: invalid | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+------------------------------ Changes (by RyanGlScott): * status: new => closed * resolution: => invalid Comment: I've opened a pull request against `clock` at https://github.com/corsis/clock/pull/51, so I'll close this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 2 15:02:01 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 May 2018 15:02:01 -0000 Subject: [GHC] #15094: unknown symbol `___divmoddi4' error with clock on 32-bit windows In-Reply-To: <047.8ee6c03f4894789ea17cc392d368199d@haskell.org> References: <047.8ee6c03f4894789ea17cc392d368199d@haskell.org> Message-ID: <062.78dcd8c07e04f849a7969a3f684c586f@haskell.org> #15094: unknown symbol `___divmoddi4' error with clock on 32-bit windows ---------------------------------+------------------------------ Reporter: simonmic | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: invalid | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+------------------------------ Comment (by Phyx-): While that will work, it will break the compiler's ability to be able to decide between static and dynamic linking. So I recommended `extra- libraries: gcc` for this exact reason and that linking against dlls directly is just asking for trouble like the postgres ticket. But older gcc before 8.2 won't work with just `gcc`. Also depending on the license if libgcc (LGPL vs GPL) this change may make clock unusable for commercial development. In this specific case I would have just turned off the Optimization for that function. Instead of linking an entire library in just for an optimization that won't really give you any gain in this case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 2 15:03:59 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 May 2018 15:03:59 -0000 Subject: [GHC] #15094: unknown symbol `___divmoddi4' error with clock on 32-bit windows In-Reply-To: <047.8ee6c03f4894789ea17cc392d368199d@haskell.org> References: <047.8ee6c03f4894789ea17cc392d368199d@haskell.org> Message-ID: <062.3f04d0c51988886faf99e6ddf35b57bf@haskell.org> #15094: unknown symbol `___divmoddi4' error with clock on 32-bit windows ---------------------------------+------------------------------ Reporter: simonmic | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: invalid | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+------------------------------ Comment (by RyanGlScott): OK. Do you mind saying this on the GitHub PR, and showing how the optimization can be disabled for that one particular function? (I'm rather unfamiliar with GCC attributes.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 2 15:15:22 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 May 2018 15:15:22 -0000 Subject: [GHC] #15094: unknown symbol `___divmoddi4' error with clock on 32-bit windows In-Reply-To: <047.8ee6c03f4894789ea17cc392d368199d@haskell.org> References: <047.8ee6c03f4894789ea17cc392d368199d@haskell.org> Message-ID: <062.359aa9a2be110024b2d300b85a0b8ef6@haskell.org> #15094: unknown symbol `___divmoddi4' error with clock on 32-bit windows ---------------------------------+------------------------------ Reporter: simonmic | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: invalid | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+------------------------------ Comment (by Phyx-): Sure, I'll comment when I get home later tonight -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 2 15:53:13 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 May 2018 15:53:13 -0000 Subject: [GHC] #15105: `typecheckModule` from GHC API crashes on MacOS for files with TH In-Reply-To: <050.a57b50b77df5fd7c6386ac1485c8460f@haskell.org> References: <050.a57b50b77df5fd7c6386ac1485c8460f@haskell.org> Message-ID: <065.8a1f5b64fb7ba729510edb4d95a079bc@haskell.org> #15105: `typecheckModule` from GHC API crashes on MacOS for files with TH ----------------------------------+---------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHC API | Version: 8.4.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+---------------------------------------- Comment (by harpocrates): Replying to [comment:2 darchon]: > We have some code in the Clash compiler to do with dynamic linking, which I expect is TH-related: https://github.com/clash-lang/clash- compiler/blame/d7dfef9d89b30d096370887899be24b9027914ac/clash-ghc/src- ghc/Clash/GHC/LoadModules.hs#L174-L179 > > {{{ > let ghcDynamic = case lookup "GHC Dynamic" (DynFlags.compilerInfo dflags) of > Just "YES" -> True > _ -> False > let dflags3 = if ghcDynamic then DynFlags.gopt_set dflags2 DynFlags.Opt_BuildDynamicToo > else dflags2 > _ <- GHC.setSessionDynFlags dflags3 > }}} > > I don't have access to an OS X machine, so could you check if setting the {{{Opt_BuildDynamicToo}}} flag fixes the TH issue? I just tried this on OS X and it unfortunately makes no difference: in either case, `lookup "GHC Dynamic" (DynFlags.compilerInfo dynflags')` produced `Just "NO"` (and then manually enabling `DynFlags.Opt_BuildDynamicToo` also didn't change anything). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 2 17:37:14 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 May 2018 17:37:14 -0000 Subject: [GHC] #14973: Location in GHCi debugger prompt printed twice when default prompt is used In-Reply-To: <043.77b079247cf81e1c9a49efb3c90c1743@haskell.org> References: <043.77b079247cf81e1c9a49efb3c90c1743@haskell.org> Message-ID: <058.cea40d14183f3be4c803cc88815fb6e5@haskell.org> #14973: Location in GHCi debugger prompt printed twice when default prompt is used -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.5 Resolution: | Keywords: debugger Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Nolan): https://phabricator.haskell.org/D4660 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 2 19:30:02 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 May 2018 19:30:02 -0000 Subject: [GHC] #11352: Allow applying type to label In-Reply-To: <051.6bddcecc381d098767b33b0315dad1d5@haskell.org> References: <051.6bddcecc381d098767b33b0315dad1d5@haskell.org> Message-ID: <066.7339b9065f79b94df8c9a67136e3dd8c@haskell.org> #11352: Allow applying type to label -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: isovector Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: ORF, Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11409 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by isovector): * owner: (none) => isovector -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 2 19:33:35 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 May 2018 19:33:35 -0000 Subject: [GHC] #15114: ghc 8.4.1 optimizes True to False Message-ID: <047.351fbc1cd8b1c2df5d061e65296d4b36@haskell.org> #15114: ghc 8.4.1 optimizes True to False -------------------------------------+------------------------------------- Reporter: elaforge | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- Ok, here's a short module: {{{#!hs import qualified Control.Exception as Exception main :: IO () main = do unserialize putStrLn "all is well" unserialize :: IO Char unserialize = if definitelyTrue then do return 'a' else do Exception.evaluate (error "wrong place") {-# NOINLINE definitelyTrue #-} definitelyTrue :: Bool definitelyTrue = True }}} When compiled with -O on 8.4.1, this should print "wrong place". Without -O, or with 8.4.2, or if True can be inlined, or without evaluate, all is well. I can reproduce this on OS X 10.13.4. This could be related to a known bug with Exception.evaluate in 8.4.1: #3930 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 2 19:40:00 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 May 2018 19:40:00 -0000 Subject: [GHC] #15112: ghc 8.4.2 on OS X: clang: warning: argument unused during compilation: '-nopie' In-Reply-To: <047.e2e05ed138c24fadcd4842fa8e08b91d@haskell.org> References: <047.e2e05ed138c24fadcd4842fa8e08b91d@haskell.org> Message-ID: <062.a3987e6dac4dbae4da47ea5f71a39f86@haskell.org> #15112: ghc 8.4.2 on OS X: clang: warning: argument unused during compilation: '-nopie' ---------------------------------+---------------------------------------- Reporter: elaforge | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by elaforge): Actually I see this with 8.4.1 too. This is probably related to the latest OS X update, not ghc version. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 2 19:44:45 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 May 2018 19:44:45 -0000 Subject: [GHC] #15114: ghc 8.4.1 optimizes True to False In-Reply-To: <047.351fbc1cd8b1c2df5d061e65296d4b36@haskell.org> References: <047.351fbc1cd8b1c2df5d061e65296d4b36@haskell.org> Message-ID: <062.3e850fdf270b78903ffbd80dd49e278a@haskell.org> #15114: ghc 8.4.1 optimizes True to False -------------------------------------+------------------------------------- Reporter: elaforge | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by adamse: Old description: > Ok, here's a short module: > > {{{#!hs > import qualified Control.Exception as Exception > > main :: IO () > main = do > unserialize > putStrLn "all is well" > > unserialize :: IO Char > unserialize = > if definitelyTrue > then do > return 'a' > else do > Exception.evaluate (error "wrong place") > > {-# NOINLINE definitelyTrue #-} > definitelyTrue :: Bool > definitelyTrue = True > }}} > > When compiled with -O on 8.4.1, this should print "wrong place". > Without -O, or with 8.4.2, or if True can be inlined, or without > evaluate, all is well. I can reproduce this on OS X 10.13.4. > > This could be related to a known bug with Exception.evaluate in 8.4.1: > #3930 New description: Ok, here's a short module: {{{#!hs import qualified Control.Exception as Exception main :: IO () main = do unserialize putStrLn "all is well" unserialize :: IO Char unserialize = if definitelyTrue then do return 'a' else do Exception.evaluate (error "wrong place") {-# NOINLINE definitelyTrue #-} definitelyTrue :: Bool definitelyTrue = True }}} When compiled with -O on 8.4.1, this should print "wrong place". Without -O, or with 8.4.2, or if True can be inlined, or without evaluate, all is well. I can reproduce this on OS X 10.13.4. This could be related to a known bug with Exception.evaluate in 8.4.1: #13930 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 2 20:02:09 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 May 2018 20:02:09 -0000 Subject: [GHC] #15114: ghc 8.4.1 optimizes True to False In-Reply-To: <047.351fbc1cd8b1c2df5d061e65296d4b36@haskell.org> References: <047.351fbc1cd8b1c2df5d061e65296d4b36@haskell.org> Message-ID: <062.d653eafddfcdf50ac0cfe61bffd3f2f2@haskell.org> #15114: ghc 8.4.1 optimizes True to False -------------------------------------+------------------------------------- Reporter: elaforge | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by diatchki): As another data point, I can reproduce this with 8.4.1 on Linux too with `-O`. However, it goes away if I compile with `-O2`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 2 20:09:35 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 May 2018 20:09:35 -0000 Subject: [GHC] #14973: Location in GHCi debugger prompt printed twice when default prompt is used In-Reply-To: <043.77b079247cf81e1c9a49efb3c90c1743@haskell.org> References: <043.77b079247cf81e1c9a49efb3c90c1743@haskell.org> Message-ID: <058.28e50212b8b9c4b8523eea41bd8d54c5@haskell.org> #14973: Location in GHCi debugger prompt printed twice when default prompt is used -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.5 Resolution: | Keywords: debugger Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4660 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D4660 * milestone: => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 2 20:16:02 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 May 2018 20:16:02 -0000 Subject: [GHC] #15112: ghc 8.4.2 on OS X: clang: warning: argument unused during compilation: '-nopie' In-Reply-To: <047.e2e05ed138c24fadcd4842fa8e08b91d@haskell.org> References: <047.e2e05ed138c24fadcd4842fa8e08b91d@haskell.org> Message-ID: <062.04683cfd2272540a261619f709690ee3@haskell.org> #15112: ghc 8.4.2 on OS X: clang: warning: argument unused during compilation: '-nopie' ---------------------------------+---------------------------------------- Reporter: elaforge | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by bgamari): Yes, it sounds like it. Does this occur with a fresh installation of GHC? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 2 20:31:26 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 May 2018 20:31:26 -0000 Subject: [GHC] #15112: ghc 8.4.2 on OS X: clang: warning: argument unused during compilation: '-nopie' In-Reply-To: <047.e2e05ed138c24fadcd4842fa8e08b91d@haskell.org> References: <047.e2e05ed138c24fadcd4842fa8e08b91d@haskell.org> Message-ID: <062.eeb1288f3ff1b5863153c4c8ede4e476@haskell.org> #15112: ghc 8.4.2 on OS X: clang: warning: argument unused during compilation: '-nopie' ---------------------------------+---------------------------------------- Reporter: elaforge | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by elaforge): By "fresh" do you mean HEAD? I haven't tried that yet. I do still see this when I run 8.4.2 as downloaded from https://www.haskell.org/ghc/download_ghc_8_4_2.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 2 21:01:13 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 May 2018 21:01:13 -0000 Subject: [GHC] #13793: Simple program trips checkNurserySanity() In-Reply-To: <046.a36b0da0c049dac7c618bbfdc92da5ef@haskell.org> References: <046.a36b0da0c049dac7c618bbfdc92da5ef@haskell.org> Message-ID: <061.d4588296b11b06d4cc069a1c5e6de6d3@haskell.org> #13793: Simple program trips checkNurserySanity() -------------------------------------+------------------------------------- Reporter: niteria | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4649 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * owner: niteria => simonmar * differential: => Phab:D4649 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 2 21:19:32 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 May 2018 21:19:32 -0000 Subject: [GHC] #15107: Testsuite failures on Windows In-Reply-To: <046.8e0cbe335a7ce09f5a7e747d4e07162e@haskell.org> References: <046.8e0cbe335a7ce09f5a7e747d4e07162e@haskell.org> Message-ID: <061.f6786f1d887453af9945e3eaede7c5d2@haskell.org> #15107: Testsuite failures on Windows -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Sure, I'll clean it up this weekend. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 2 21:28:46 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 May 2018 21:28:46 -0000 Subject: [GHC] #15114: ghc 8.4.1 optimizes True to False In-Reply-To: <047.351fbc1cd8b1c2df5d061e65296d4b36@haskell.org> References: <047.351fbc1cd8b1c2df5d061e65296d4b36@haskell.org> Message-ID: <062.32b72841e65ca146334468d3b698ff26@haskell.org> #15114: ghc 8.4.1 optimizes True to False -------------------------------------+------------------------------------- Reporter: elaforge | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): The title is misleading IMO: it's not that the `else` branch is taken instead of the `then` branch, but rather that the `evaluate` effect floats/leaks out of the inactive control flow path. I.e. the `a` branch is still taken; it's just that the `error` exception is triggered before we can reach it. Here's a modified example which better shows what I mean: {{{#!hs import qualified Control.Exception as Exception import Debug.Trace main :: IO () main = do c <- unserialize putStrLn "all is well" print c unserialize :: IO Char unserialize = if definitelyTrue then do putStrLn "HEY" return 'a' else do Exception.evaluate (traceShow "wrong place" 'b') {-# NOINLINE definitelyTrue #-} definitelyTrue :: Bool definitelyTrue = True }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 2 21:33:05 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 May 2018 21:33:05 -0000 Subject: [GHC] #15112: ghc 8.4.2 on OS X: clang: warning: argument unused during compilation: '-nopie' In-Reply-To: <047.e2e05ed138c24fadcd4842fa8e08b91d@haskell.org> References: <047.e2e05ed138c24fadcd4842fa8e08b91d@haskell.org> Message-ID: <062.0d6bd9327ea51d0595c98dbc4df28f44@haskell.org> #15112: ghc 8.4.2 on OS X: clang: warning: argument unused during compilation: '-nopie' ---------------------------------+---------------------------------------- Reporter: elaforge | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by bgamari): Hmm, I'm a bit surprised that `configure` doesn't realize that `-nopie` isn't a valid flag. Do you have any insight into why this might be? `config.log` would be interesting to see. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 2 21:40:08 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 May 2018 21:40:08 -0000 Subject: [GHC] #15112: ghc 8.4.2 on OS X: clang: warning: argument unused during compilation: '-nopie' In-Reply-To: <047.e2e05ed138c24fadcd4842fa8e08b91d@haskell.org> References: <047.e2e05ed138c24fadcd4842fa8e08b91d@haskell.org> Message-ID: <062.5059d09109d4edf7cde1912084624cb3@haskell.org> #15112: ghc 8.4.2 on OS X: clang: warning: argument unused during compilation: '-nopie' ---------------------------------+---------------------------------------- Reporter: elaforge | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by elaforge): I think it does, because I compiled from HEAD and I don't get the warning. Of course the existing 8.4.2 binary was compiled before the latest OS X version, so it won't have that. So maybe we just wait for this to go away in the next release? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 2 21:40:50 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 May 2018 21:40:50 -0000 Subject: [GHC] #15114: ghc 8.4.1 optimizes True to False In-Reply-To: <047.351fbc1cd8b1c2df5d061e65296d4b36@haskell.org> References: <047.351fbc1cd8b1c2df5d061e65296d4b36@haskell.org> Message-ID: <062.203368140544a75e90cd95effff17eb4@haskell.org> #15114: ghc 8.4.1 optimizes True to False -------------------------------------+------------------------------------- Reporter: elaforge | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I think the bug also does not manifest in GHC 8.2.2. It's probably already-fixed, but at least it's an excellent regression test. And I'd like to be sure that it really IS fixed, rather than merely concealed, in 8.4.2. Does anyone feel able to bisect to the commit that fixes it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 2 22:02:17 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 May 2018 22:02:17 -0000 Subject: [GHC] #13091: Build broken on amd64 solaris 11 In-Reply-To: <046.85badc94549c3efb365f57e429c5ca71@haskell.org> References: <046.85badc94549c3efb365f57e429c5ca71@haskell.org> Message-ID: <061.3ee5c93e4fd6d852144a3235268630ed@haskell.org> #13091: Build broken on amd64 solaris 11 -------------------------------------+------------------------------------- Reporter: kgardas | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Build System | Version: 8.0.2 Resolution: | Keywords: Operating System: Solaris | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: #15075 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ru0mad): * Attachment "cabal-install-build.sh" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 2 22:02:34 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 May 2018 22:02:34 -0000 Subject: [GHC] #13091: Build broken on amd64 solaris 11 In-Reply-To: <046.85badc94549c3efb365f57e429c5ca71@haskell.org> References: <046.85badc94549c3efb365f57e429c5ca71@haskell.org> Message-ID: <061.efd53159f4ef9ba530e8ee4924d3e8f7@haskell.org> #13091: Build broken on amd64 solaris 11 -------------------------------------+------------------------------------- Reporter: kgardas | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Build System | Version: 8.0.2 Resolution: | Keywords: Operating System: Solaris | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: #15075 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ru0mad): * Attachment "cabal-install-2.2.0.0.patch" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 2 22:02:51 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 May 2018 22:02:51 -0000 Subject: [GHC] #13091: Build broken on amd64 solaris 11 In-Reply-To: <046.85badc94549c3efb365f57e429c5ca71@haskell.org> References: <046.85badc94549c3efb365f57e429c5ca71@haskell.org> Message-ID: <061.29efd015a68375bbd895afdf151b51d5@haskell.org> #13091: Build broken on amd64 solaris 11 -------------------------------------+------------------------------------- Reporter: kgardas | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Build System | Version: 8.0.2 Resolution: | Keywords: Operating System: Solaris | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: #15075 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ru0mad): * Attachment "ghc-build.sh" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 2 22:03:05 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 May 2018 22:03:05 -0000 Subject: [GHC] #13091: Build broken on amd64 solaris 11 In-Reply-To: <046.85badc94549c3efb365f57e429c5ca71@haskell.org> References: <046.85badc94549c3efb365f57e429c5ca71@haskell.org> Message-ID: <061.86f6e616ae0a4ff832a2bd237cf66474@haskell.org> #13091: Build broken on amd64 solaris 11 -------------------------------------+------------------------------------- Reporter: kgardas | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Build System | Version: 8.0.2 Resolution: | Keywords: Operating System: Solaris | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: #15075 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ru0mad): * Attachment "ghc-8.4.2-solaris2.11.patch" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 2 22:03:22 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 May 2018 22:03:22 -0000 Subject: [GHC] #13091: Build broken on amd64 solaris 11 In-Reply-To: <046.85badc94549c3efb365f57e429c5ca71@haskell.org> References: <046.85badc94549c3efb365f57e429c5ca71@haskell.org> Message-ID: <061.3b162f8f288f95282dbff40e99dcf0c4@haskell.org> #13091: Build broken on amd64 solaris 11 -------------------------------------+------------------------------------- Reporter: kgardas | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Build System | Version: 8.0.2 Resolution: | Keywords: Operating System: Solaris | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: #15075 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ru0mad): * Attachment "stack-build.sh" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 2 22:03:38 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 May 2018 22:03:38 -0000 Subject: [GHC] #13091: Build broken on amd64 solaris 11 In-Reply-To: <046.85badc94549c3efb365f57e429c5ca71@haskell.org> References: <046.85badc94549c3efb365f57e429c5ca71@haskell.org> Message-ID: <061.3db10e4fa47813478174f349ccc96123@haskell.org> #13091: Build broken on amd64 solaris 11 -------------------------------------+------------------------------------- Reporter: kgardas | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Build System | Version: 8.0.2 Resolution: | Keywords: Operating System: Solaris | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: #15075 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ru0mad): * Attachment "filelock-0.1.1.2.patch" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 2 22:03:56 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 May 2018 22:03:56 -0000 Subject: [GHC] #13091: Build broken on amd64 solaris 11 In-Reply-To: <046.85badc94549c3efb365f57e429c5ca71@haskell.org> References: <046.85badc94549c3efb365f57e429c5ca71@haskell.org> Message-ID: <061.59b202381f999abe0403288f587f0d6c@haskell.org> #13091: Build broken on amd64 solaris 11 -------------------------------------+------------------------------------- Reporter: kgardas | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Build System | Version: 8.0.2 Resolution: | Keywords: Operating System: Solaris | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: #15075 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ru0mad): * Attachment "stack-1.7.1.patch" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 2 22:04:13 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 May 2018 22:04:13 -0000 Subject: [GHC] #14973: Location in GHCi debugger prompt printed twice when default prompt is used In-Reply-To: <043.77b079247cf81e1c9a49efb3c90c1743@haskell.org> References: <043.77b079247cf81e1c9a49efb3c90c1743@haskell.org> Message-ID: <058.a5a7f997ec6b5415f54fab6501c6dd56@haskell.org> #14973: Location in GHCi debugger prompt printed twice when default prompt is used -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.5 Resolution: | Keywords: debugger Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4661 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Nolan): * differential: Phab:D4660 => Phab:D4661 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 2 22:05:44 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 May 2018 22:05:44 -0000 Subject: [GHC] #13091: Build broken on amd64 solaris 11 In-Reply-To: <046.85badc94549c3efb365f57e429c5ca71@haskell.org> References: <046.85badc94549c3efb365f57e429c5ca71@haskell.org> Message-ID: <061.300cbcf63a4e1b453cffc5d2124b6f1f@haskell.org> #13091: Build broken on amd64 solaris 11 -------------------------------------+------------------------------------- Reporter: kgardas | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Build System | Version: 8.0.2 Resolution: | Keywords: Operating System: Solaris | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: #15075 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ru0mad): * Attachment "testsuite_summary.txt" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 2 22:07:07 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 May 2018 22:07:07 -0000 Subject: [GHC] #13091: Build broken on amd64 solaris 11 In-Reply-To: <046.85badc94549c3efb365f57e429c5ca71@haskell.org> References: <046.85badc94549c3efb365f57e429c5ca71@haskell.org> Message-ID: <061.9133f1efa4dd678784c3add667090276@haskell.org> #13091: Build broken on amd64 solaris 11 -------------------------------------+------------------------------------- Reporter: kgardas | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Build System | Version: 8.0.2 Resolution: | Keywords: Operating System: Solaris | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: #15075 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ru0mad): Hello, I managed somehow to build ghc-8.4.2 on solaris 11.4 (x86_64), along with cabal-install and finally stack. I had to apply some patches : - to workaround the file locking problem (flock() missing on solaris) : * in ghc to catch the FileLockingNotSupported exception raised on solaris by GHC.IO.Handle.Lock * similar in cabal-install (which clones more or less the GHC code) * patch in filelock (used by stack) to refer to the file locking from GHC base - to have a working building process (the -optl-optl problem + ) - to include in stack where needed (in unix/Terminal.hsc) As file locking is made a no-op, concurrent acces to package db should be broken, but so far I didn't have any problem on my standalone solaris box. Some tests are failing, but most of it seems quite innocuous (mostly differences in output) but some are more preoccupying, yet it sort of works (test summary attached). The patches and building scripts are attached (for ghc, cabal-install, stack). As I'm not very experimented in this, I would be very interested to know if the tweaks I applied still make a workable version or if it is totally borked. Bruno -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 2 22:30:18 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 May 2018 22:30:18 -0000 Subject: [GHC] #15114: ghc 8.4.1 optimizes True to False In-Reply-To: <047.351fbc1cd8b1c2df5d061e65296d4b36@haskell.org> References: <047.351fbc1cd8b1c2df5d061e65296d4b36@haskell.org> Message-ID: <062.94be430db28f54dc7ce0117455e9813e@haskell.org> #15114: ghc 8.4.1 optimizes True to False -------------------------------------+------------------------------------- Reporter: elaforge | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I've confirmed that the commit that fixed this was ac1ade1ad25f145ab27219c4fb8366e982658873 (`Fix seq# case of exprOkForSpeculation`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 2 23:47:30 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 May 2018 23:47:30 -0000 Subject: [GHC] #15114: ghc 8.4.1 lifts errors out of if then else (was: ghc 8.4.1 optimizes True to False) In-Reply-To: <047.351fbc1cd8b1c2df5d061e65296d4b36@haskell.org> References: <047.351fbc1cd8b1c2df5d061e65296d4b36@haskell.org> Message-ID: <062.29341a34910842f36e1754d0dd346aa3@haskell.org> #15114: ghc 8.4.1 lifts errors out of if then else -------------------------------------+------------------------------------- Reporter: elaforge | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by elaforge): Sounds like close as a duplicate then. Shall I submit as a regression test? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 07:20:39 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 07:20:39 -0000 Subject: [GHC] #15114: ghc 8.4.1 lifts errors out of if then else In-Reply-To: <047.351fbc1cd8b1c2df5d061e65296d4b36@haskell.org> References: <047.351fbc1cd8b1c2df5d061e65296d4b36@haskell.org> Message-ID: <062.f8a6bc8fdae1beca980bc1423035e36f@haskell.org> #15114: ghc 8.4.1 lifts errors out of if then else -------------------------------------+------------------------------------- Reporter: elaforge | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Thanks. That makes me sure it relates to #5129. Don't worry, I'll add it as a regression test myself, shortly. Thanks for boiling it down. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 07:43:35 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 07:43:35 -0000 Subject: [GHC] #13793: Simple program trips checkNurserySanity() In-Reply-To: <046.a36b0da0c049dac7c618bbfdc92da5ef@haskell.org> References: <046.a36b0da0c049dac7c618bbfdc92da5ef@haskell.org> Message-ID: <061.b7d711458d016794ad2b546c67579b69@haskell.org> #13793: Simple program trips checkNurserySanity() -------------------------------------+------------------------------------- Reporter: niteria | Owner: simonmar Type: bug | Status: merge Priority: normal | Milestone: 8.4.3 Component: Runtime System | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4649 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * status: new => merge * milestone: => 8.4.3 Comment: Fixed by 4cb5595e5e800818721a623a5419cad29a528000 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 07:51:44 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 07:51:44 -0000 Subject: [GHC] #15114: ghc 8.4.1 lifts errors out of if then else In-Reply-To: <047.351fbc1cd8b1c2df5d061e65296d4b36@haskell.org> References: <047.351fbc1cd8b1c2df5d061e65296d4b36@haskell.org> Message-ID: <062.1cd4373d441c5cafbf2ce081bdb83879@haskell.org> #15114: ghc 8.4.1 lifts errors out of if then else -------------------------------------+------------------------------------- Reporter: elaforge | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"6742ce2d8e0919dd75b5ecb0e2b5f891c442bdd3/ghc" 6742ce2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6742ce2d8e0919dd75b5ecb0e2b5f891c442bdd3" Test Trac #15114 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 07:52:41 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 07:52:41 -0000 Subject: [GHC] #15019: Fix performance regressions from #14737 In-Reply-To: <047.36d31dd41a03f5d1b4531d3b52b0f31a@haskell.org> References: <047.36d31dd41a03f5d1b4531d3b52b0f31a@haskell.org> Message-ID: <062.2132f492f3c982b883a6311d4bd5be20@haskell.org> #15019: Fix performance regressions from #14737 -------------------------------------+------------------------------------- Reporter: tdammers | Owner: tdammers Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #14737 | Differential Rev(s): phab:D4568 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): How did the patch in comment:13 work out? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 08:02:13 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 08:02:13 -0000 Subject: [GHC] #15090: Do more coercion optimisation on the fly In-Reply-To: <046.9667b6c209c395b52f77df698c889caa@haskell.org> References: <046.9667b6c209c395b52f77df698c889caa@haskell.org> Message-ID: <061.254a23deb47eb82c642fcb794f945e4c@haskell.org> #15090: Do more coercion optimisation on the fly -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Coercions 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 tdammers): I tried to figure out how to do this, but I'm a bit confused - `mkTransCo` takes two coercions and builds a `TransCo` from them, but IIUC, the optimisation we're talking about should detect suitable `NthCo`'s and turn them into `AppCo`s. So I don't quite understand why this needs to be done in `mkTransCo` rather than `mkNthCo`. Or should `mkTransCo` drill down into its arguments and perform the optimisation on those? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 08:54:06 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 08:54:06 -0000 Subject: [GHC] #15038: Memory Corruption (strange closure type) In-Reply-To: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> References: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> Message-ID: <064.824d4200aeb55a187b2c10a8072c3929@haskell.org> #15038: Memory Corruption (strange closure type) -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #9718 | Differential Rev(s): Phab:D4652 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Aha. Concerning other error-ids, like `patErrorId`, look at this, in `MkCore`: {{{ mkRuntimeErrorId name = mkVanillaGlobalWithInfo name runtimeErrorTy bottoming_info where bottoming_info = vanillaIdInfo `setStrictnessInfo` strict_sig `setArityInfo` 1 -- Make arity and strictness agree -- Do *not* mark them as NoCafRefs, because they can indeed have -- CAF refs. For example, pAT_ERROR_ID calls GHC.Err.untangle, -- which has some CAFs -- In due course we may arrange that these error-y things are -- regarded by the GC as permanently live, in which case we -- can give them NoCaf info. As it is, any function that calls -- any pc_bottoming_Id will itself have CafRefs, which bloats -- SRTs. }}} This came from a commit back in 2002! {{{ commit 33ce2a14d1220bd3b9f00e8d461b8f9ef31ee411 Author: simonpj Date: Fri Jun 28 14:06:54 2002 +0000 [project @ 2002-06-28 14:06:52 by simonpj] ----------------------------------- Fix the CAF info field of error Ids ----------------------------------- A bizarre bug. In MkId, we build the Id for various error-y Ids (like pAT_ERROR_ID) that we grab out of thin air in various places (like the desugarer). They were marked as not referring to any CAFs, but this was a lie! In fact, they refer to 'untangle' (see GHC.Err) and thence to a CAF. Result: GC crash under very obscure circumstances. (Rob's optimistic evaluator tickled it.) Solution: give them more conservative IdInfo. Two other better solutions to think about: * Don't grab them out of thin air; instead get them from an interface file. * Treat them as always-live (requires mod to garbage collector) so they don't need to be mentioned in SRTs at all }}} So even if we fixed #15113, that would not help with `patErrorId` etc, becuase they are wired-in Ids, built with `mkRuntimeErrorId`, and hence (conservatively) marked `MayHaveCafRefs`. What to do? I hate this special treatment of `aBSENT_ERROR_ID` etc. Let's instead: * Add `Note [The CAF-ness of error Ids]` explaining all this. * Make all the error ids (both `aBSENT_ERROR_ID` and `mkRuntimeErrorId` start with `errorIdInfo` * Define `errorIdInfo = noCafInfo`, pointing to `Note [The CAF-ness of error Ids]`, which says that we can mark them no-CAF because (and only because) we add them the to the Stable Pointer Table; see `Note [StableGcRoots]` in `RtsStartup.c`. * Add all the wired-in error-ids to the list in `RtsStartup.c`. And make sure that the `MkCore.errorIds` list also points to the Note. Now all the error Ids will be non-CAFy, we'll get smaller SRTs etc, which is good. And there will be no special treatment of the unboxed-sum business. (But you might want a Note in the unarise transform to explain that adding a reference to absent-error-id doesn't change CAFyness.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 08:56:57 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 08:56:57 -0000 Subject: [GHC] #15113: Do not make CAFs from literal strings In-Reply-To: <046.d042ad82da8658ea11bcd44bf2d86387@haskell.org> References: <046.d042ad82da8658ea11bcd44bf2d86387@haskell.org> Message-ID: <061.4760e62f581ee70cbd2d060184a0a263@haskell.org> #15113: Do not make CAFs from literal strings -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): See comment:33 on #15038 for why this ticket (useful though it may be) will not actually benefit `patError` and friends. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 09:11:20 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 09:11:20 -0000 Subject: [GHC] #15090: Do more coercion optimisation on the fly In-Reply-To: <046.9667b6c209c395b52f77df698c889caa@haskell.org> References: <046.9667b6c209c395b52f77df698c889caa@haskell.org> Message-ID: <061.4a134b328e3064985d3c5ccb71497454@haskell.org> #15090: Do more coercion optimisation on the fly -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Coercions 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: | -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > When studying #15019, I looked at `CoreOpt.pushCoValArg`. I saw lots of > attempted decompositions in `pushCoValArg`, > which were trying to do `decomposeFunCo` on > {{{ > C @g1 ; sym (C @g2) > where > axiom C a = a -> a > }}} > But the smart `mkNthCo` can't make progress on this, so we get > {{{ > Nth:2 (C @g1 ; sym (C @g2)) > }}} > and these things stack up if there is a chain of applications in > `Simplify.simplCast`. > > The coercion optimiser will optimise this coercion to > {{{ > (g1 ; sym g2) -> (g1 ; sym g2) > }}} > and now the smart `mkNthCo` in `decomposeFunCo` will succeed. > > Possible idea: make this optimization part of `mkTransCo` so that it > happens on the fly. New description: When studying #15019, I looked at `CoreOpt.pushCoValArg`. I saw lots of attempted decompositions in `pushCoValArg`, which were trying to do `decomposeFunCo` on {{{ C @g1 ; sym (C @g2) where axiom C a = a -> a }}} But the smart `mkNthCo` can't make progress on this, so we get {{{ Nth:2 (C @g1 ; sym (C @g2)) }}} and these things stack up if there is a chain of applications in `Simplify.simplCast`. The coercion optimiser will optimise this coercion to {{{ (g1 ; sym g2) -> (g1 ; sym g2) }}} and now the smart `mkNthCo` in `decomposeFunCo` will succeed. Possible idea: make this optimization part of `mkTransCo` so that it happens on the fly. (Annoyingly, I can't remember which of the three test cases mentioned in #15109 displayed this behaviour.) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 09:15:50 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 09:15:50 -0000 Subject: [GHC] #10393: Bogus warning with OverloadedLists In-Reply-To: <047.4f31e76bb02b814e66f057431b9409d9@haskell.org> References: <047.4f31e76bb02b814e66f057431b9409d9@haskell.org> Message-ID: <062.c7813ab4356ccca5fe354b6394da88e2@haskell.org> #10393: Bogus warning with OverloadedLists -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: duplicate | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #9951 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => PatternMatchWarnings -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 09:16:13 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 09:16:13 -0000 Subject: [GHC] #10116: Closed type families: Warn if it doesn't handle all cases In-Reply-To: <049.356115fff338ba416dd9590b8ce78129@haskell.org> References: <049.356115fff338ba416dd9590b8ce78129@haskell.org> Message-ID: <064.a022e605963a00900f807546877331fb@haskell.org> #10116: Closed type families: Warn if it doesn't handle all cases -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: TypeFamilies, | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: TypeFamilies => TypeFamilies, PatternMatchWarnings -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 09:16:25 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 09:16:25 -0000 Subject: [GHC] #9951: OverloadedLists breaks exhaustiveness check In-Reply-To: <048.8197b1daa9c7ccdc6beab4f061e20643@haskell.org> References: <048.8197b1daa9c7ccdc6beab4f061e20643@haskell.org> Message-ID: <063.a3f977d7266801475d0692b4ac43ab65@haskell.org> #9951: OverloadedLists breaks exhaustiveness check -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: duplicate | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => PatternMatchWarnings -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 09:16:37 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 09:16:37 -0000 Subject: [GHC] #595: Overhaul GHC's overlapping/non-exhaustive pattern checking In-Reply-To: <047.bea78f01cbb904765ad77c751bc8d3af@haskell.org> References: <047.bea78f01cbb904765ad77c751bc8d3af@haskell.org> Message-ID: <062.f04d4ff46bffe7044a5c6aa1e0cb7f8b@haskell.org> #595: Overhaul GHC's overlapping/non-exhaustive pattern checking -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: None Resolution: fixed | Keywords: warnings, | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: warnings => warnings, PatternMatchWarnings -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 09:16:50 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 09:16:50 -0000 Subject: [GHC] #5728: Warnings from -fwarn-incomplete-record-updates even with all constructors matched In-Reply-To: <042.3d8c83f19998d498d52985dfe7e74f1d@haskell.org> References: <042.3d8c83f19998d498d52985dfe7e74f1d@haskell.org> Message-ID: <057.6003ef147d84ff26840a314c62fb4887@haskell.org> #5728: Warnings from -fwarn-incomplete-record-updates even with all constructors matched -------------------------------------+------------------------------------- Reporter: mjo | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.4.1 Resolution: duplicate | Keywords: warnings, | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: warnings => warnings, PatternMatchWarnings -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 09:16:59 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 09:16:59 -0000 Subject: [GHC] #3927: Incomplete/overlapped pattern warnings + GADTs = inadequate In-Reply-To: <046.0473c92f4a34c84959f5237ada18226b@haskell.org> References: <046.0473c92f4a34c84959f5237ada18226b@haskell.org> Message-ID: <061.95fe6fc4267373d1bf8a0367fe1ea5db@haskell.org> #3927: Incomplete/overlapped pattern warnings + GADTs = inadequate -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 6.12.1 Resolution: duplicate | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4139 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => PatternMatchWarnings -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 09:17:08 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 09:17:08 -0000 Subject: [GHC] #5724: Confusing warning message for incomplete patterns In-Reply-To: <052.c4247f3fcd6acd7f8e305482ba8dc328@haskell.org> References: <052.c4247f3fcd6acd7f8e305482ba8dc328@haskell.org> Message-ID: <067.b18177c42333f272859eac85e0b3bfff@haskell.org> #5724: Confusing warning message for incomplete patterns -------------------------------------+------------------------------------- Reporter: AntoineLatter | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.3 Resolution: duplicate | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => PatternMatchWarnings -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 09:17:17 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 09:17:17 -0000 Subject: [GHC] #5762: GHC gives incorrect warnings with simple applications of the view patterns extension In-Reply-To: <042.987ba7199430a9648cbd820f720ad516@haskell.org> References: <042.987ba7199430a9648cbd820f720ad516@haskell.org> Message-ID: <057.0e14b09a4864623bf839e9e3c49bd523@haskell.org> #5762: GHC gives incorrect warnings with simple applications of the view patterns extension -------------------------------------+------------------------------------- Reporter: jmg | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.3 Resolution: duplicate | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => PatternMatchWarnings -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 09:17:27 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 09:17:27 -0000 Subject: [GHC] #4139: Spurious non-exhaustive pattern match warnings are given using GADTs In-Reply-To: <046.a84202da85a5f9cbf5e28e3e31df006a@haskell.org> References: <046.a84202da85a5f9cbf5e28e3e31df006a@haskell.org> Message-ID: <061.2fb9fcfd95f518f176c07792319469cd@haskell.org> #4139: Spurious non-exhaustive pattern match warnings are given using GADTs -------------------------------------+------------------------------------- Reporter: blarsen | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Resolution: duplicate | Keywords: GADTs, | warnings, pattern matching, | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #3927 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: GADTs, warnings, pattern matching => GADTs, warnings, pattern matching, PatternMatchWarnings -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 09:17:35 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 09:17:35 -0000 Subject: [GHC] #6124: Spurious non-exhaustive warning with GADT and newtypes In-Reply-To: <048.29c3c87c3da2ea322b4b765cc6053ba0@haskell.org> References: <048.29c3c87c3da2ea322b4b765cc6053ba0@haskell.org> Message-ID: <063.5781c3506bb3a9f88bee2b10fdbdb2ce@haskell.org> #6124: Spurious non-exhaustive warning with GADT and newtypes -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.4.1 checker) | Keywords: Resolution: duplicate | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => PatternMatchWarnings -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 09:17:51 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 09:17:51 -0000 Subject: [GHC] #322: fromInteger-related pattern match overlap warnings In-Reply-To: <047.ace5220e5df89abf8e6e92924cc2e86b@haskell.org> References: <047.ace5220e5df89abf8e6e92924cc2e86b@haskell.org> Message-ID: <062.0da0fcb568c09d40723b78b925567fce@haskell.org> #322: fromInteger-related pattern match overlap warnings -------------------------------------+------------------------------------- Reporter: ashley-y | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.4 Resolution: duplicate | Keywords: warnings | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: ds060 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: warnings => warnings PatternMatchWarnings -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 09:18:02 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 09:18:02 -0000 Subject: [GHC] #8016: case expression with mixed use of Num instances cause spurious overlap warning In-Reply-To: <047.b98435d81251f7bd5399b5421e501aba@haskell.org> References: <047.b98435d81251f7bd5399b5421e501aba@haskell.org> Message-ID: <062.248d77096071fd501411514e966396da@haskell.org> #8016: case expression with mixed use of Num instances cause spurious overlap warning -------------------------------------+------------------------------------- Reporter: bscarlet | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: duplicate | Keywords: case overlap, | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: case overlap => case overlap, PatternMatchWarnings -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 09:18:48 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 09:18:48 -0000 Subject: [GHC] #8494: Warn if a pattern guard obviates all others In-Reply-To: <050.b38ec9352f874d8f0bd116750e0ba6ca@haskell.org> References: <050.b38ec9352f874d8f0bd116750e0ba6ca@haskell.org> Message-ID: <065.3c34479fc9720db30a307d06ccdf9690@haskell.org> #8494: Warn if a pattern guard obviates all others -------------------------------------+------------------------------------- Reporter: JohnWiegley | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: duplicate | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => PatternMatchWarnings -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 09:18:55 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 09:18:55 -0000 Subject: [GHC] #8853: Surprising mention of unboxed integers in pattern exhaustiveness warning In-Reply-To: <054.e34ba59485cfdd347886b35308e8a5bc@haskell.org> References: <054.e34ba59485cfdd347886b35308e8a5bc@haskell.org> Message-ID: <069.465aadfda7ec89fc01164eb9a9c020d0@haskell.org> #8853: Surprising mention of unboxed integers in pattern exhaustiveness warning -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: duplicate | Keywords: | PatternMatchWarnings Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect | (amd64) warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => PatternMatchWarnings -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 09:19:01 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 09:19:01 -0000 Subject: [GHC] #8970: Non-exhaustive pattern match warning with DataKinds and TypeFamilies In-Reply-To: <046.dc47e7f5e7f289f268ba58d8b6a0f95e@haskell.org> References: <046.dc47e7f5e7f289f268ba58d8b6a0f95e@haskell.org> Message-ID: <061.9820ffeabdfe50e8e3ebcf29e38b9378@haskell.org> #8970: Non-exhaustive pattern match warning with DataKinds and TypeFamilies -------------------------------------+------------------------------------- Reporter: tensor5 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: duplicate | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #3927 #6124 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => PatternMatchWarnings -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 09:19:39 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 09:19:39 -0000 Subject: [GHC] #9113: Template Haskell should warn about non-exhaustive pattern matches In-Reply-To: <042.80c5d78608ff3c2a95ab5b9b46f7d317@haskell.org> References: <042.80c5d78608ff3c2a95ab5b9b46f7d317@haskell.org> Message-ID: <057.e9218d244e6afe68d2f4d0dec5499d9c@haskell.org> #9113: Template Haskell should warn about non-exhaustive pattern matches -------------------------------------+------------------------------------- Reporter: tvh | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.2 Resolution: duplicate | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => PatternMatchWarnings -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 09:20:01 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 09:20:01 -0000 Subject: [GHC] #2204: Improve 'patterns not matched' warnings In-Reply-To: <047.57470c7515f5d78414f8813f455c57a5@haskell.org> References: <047.57470c7515f5d78414f8813f455c57a5@haskell.org> Message-ID: <062.831d7babb1773bb06ecef66ef1ed5641@haskell.org> #2204: Improve 'patterns not matched' warnings -------------------------------------+------------------------------------- Reporter: Deewiant | Owner: (none) Type: feature request | Status: closed Priority: low | Milestone: ⊥ Component: Compiler | Version: 6.8.2 Resolution: duplicate | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => PatternMatchWarnings -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 09:25:26 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 09:25:26 -0000 Subject: [GHC] #15113: Do not make CAFs from literal strings In-Reply-To: <046.d042ad82da8658ea11bcd44bf2d86387@haskell.org> References: <046.d042ad82da8658ea11bcd44bf2d86387@haskell.org> Message-ID: <061.5c30bb7f68326d84f7015e23f7dc68bc@haskell.org> #15113: Do not make CAFs from literal strings -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: CAFs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => CAFs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 09:26:07 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 09:26:07 -0000 Subject: [GHC] #9718: Avoid TidyPgm predicting what CorePrep will do In-Reply-To: <046.5eef205a104808a079ad54238c650906@haskell.org> References: <046.5eef205a104808a079ad54238c650906@haskell.org> Message-ID: <061.99d14b3b709c19cf3332ce65439eb7ce@haskell.org> #9718: Avoid TidyPgm predicting what CorePrep will do -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: CodeGen, CAFs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: CodeGen => CodeGen, CAFs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 09:26:31 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 09:26:31 -0000 Subject: [GHC] #4121: Refactor the plumbing of CafInfo to make it more robust In-Reply-To: <045.e33af6968458760182e141457b350018@haskell.org> References: <045.e33af6968458760182e141457b350018@haskell.org> Message-ID: <060.f8c97f563ecbb3f1c66a98e845276793@haskell.org> #4121: Refactor the plumbing of CafInfo to make it more robust -------------------------------------+------------------------------------- Reporter: dterei | Owner: (none) Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 6.12.2 Resolution: | Keywords: CodeGen, CAFs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: CodeGen => CodeGen, CAFs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 09:32:34 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 09:32:34 -0000 Subject: [GHC] #14759: ListSetOps WARNING causes tests to fail In-Reply-To: <045.a3d44c4c76e1fc42f26bbcbe8a0b0377@haskell.org> References: <045.a3d44c4c76e1fc42f26bbcbe8a0b0377@haskell.org> Message-ID: <060.99529cf5cf1bf87c4bb2f3ba95b5c4ba@haskell.org> #14759: ListSetOps WARNING causes tests to fail -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4628 Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): Replying to [comment:16 simonpj]: > Interesting idea. Do you feel inclined to work on it? Possibly, but I can't commit to anything as I'm moving countries this month. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 09:38:22 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 09:38:22 -0000 Subject: [GHC] #14759: ListSetOps WARNING causes tests to fail In-Reply-To: <045.a3d44c4c76e1fc42f26bbcbe8a0b0377@haskell.org> References: <045.a3d44c4c76e1fc42f26bbcbe8a0b0377@haskell.org> Message-ID: <060.bf65c65df5b7098bb49d313c983a4baa@haskell.org> #14759: ListSetOps WARNING causes tests to fail -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4628 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK, well * The right fix is described in the thread above; but needs someone willing to do it. * I'm reluctant to lose the warning by following Phab:D4628. It fixes a symptom, not a cause; and we have no idea (currently) about whether it makes perf better or worse. * Maybe we should mark the failures that arise from the `imp_finsts` stuff as expect-broken, queued on this ticket? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 09:54:31 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 09:54:31 -0000 Subject: [GHC] #15115: `Numeric.showEFloat` does not honor precision with 0 digits Message-ID: <045.cd71602cfa60bbc0128fc78c2d018224@haskell.org> #15115: `Numeric.showEFloat` does not honor precision with 0 digits -------------------------------------+------------------------------------- Reporter: guibou | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: | Version: 8.4.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: -------------------------------------+------------------------------------- Hello, `Numeric.showEFloat` should display a number of digit after the dot depending on the `Maybe Int` argument. It works for values > 0: {{{#!haskell Prelude Numeric> Numeric.showEFloat (Just 5) pi "" "3.14159e0" Prelude Numeric> Numeric.showEFloat (Just 1) pi "" "3.1e0" }}} But for `0` it shows the same result as with `1`: {{{#!haskell Prelude Numeric> Numeric.showEFloat (Just 0) pi "" "3.1e0" }}} I was expecting `3e0` or `3e0`. As a matter of comparison, here is the behavior with `Numeric.showFFloat`: {{{#!haskell Prelude Numeric> Numeric.showFFloat (Just 5) pi "" "3.14159" Prelude Numeric> Numeric.showFFloat (Just 1) pi "" "3.1" Prelude Numeric> Numeric.showFFloat (Just 0) pi "" "3" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 12:32:34 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 12:32:34 -0000 Subject: [GHC] #15114: ghc 8.4.1 lifts errors out of if then else In-Reply-To: <047.351fbc1cd8b1c2df5d061e65296d4b36@haskell.org> References: <047.351fbc1cd8b1c2df5d061e65296d4b36@haskell.org> Message-ID: <062.950b6e7934b1a992ed999fa1f32f5e81@haskell.org> #15114: ghc 8.4.1 lifts errors out of if then else -------------------------------------+------------------------------------- Reporter: elaforge | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | simplCore/should_run/T15114 Blocked By: | Blocking: Related Tickets: #5129 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * testcase: => simplCore/should_run/T15114 * resolution: => fixed * related: => #5129 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 13:51:04 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 13:51:04 -0000 Subject: [GHC] #14904: Compiler panic (piResultTy) In-Reply-To: <047.da803a71fb92b792256c7a85e0a6a6bc@haskell.org> References: <047.da803a71fb92b792256c7a85e0a6a6bc@haskell.org> Message-ID: <062.d83c434d2023fc6367d8b44843f149d1@haskell.org> #14904: Compiler panic (piResultTy) -------------------------------------+------------------------------------- Reporter: kcsongor | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14873 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: 14873 => #14873 Comment: It looks like commit faec8d358985e5d0bf363bd96f23fe76c9e281f7 (`Track type variable scope more carefully.`) nabbed this one. After that commit, I get error messages instead of panics on each program in the ticket. For the first program: {{{#!hs {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind type family F (f :: forall a. g a) :: Type where F (f :: forall a. g a) = Int }}} {{{ $ ghc/inplace/bin/ghc-stage2 Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:8:1: error: You have written a *complete user-suppled kind signature*, but the following variable is undetermined: k0 :: * Perhaps add a kind signature. Inferred kinds of user-written variables: g :: k0 -> * f :: forall (a :: k0). g a | 8 | type family F (f :: forall a. g a) :: Type where | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} For the second program: {{{#!hs {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} module Bug2 where import Data.Kind type family F f :: Type where F ((f :: forall a. g a) :: forall a. g a) = Int }}} {{{ $ ghc/inplace/bin/ghc-stage2 Bug2.hs [1 of 1] Compiling Bug2 ( Bug2.hs, Bug2.o ) Bug2.hs:9:7: error: • Expected kind ‘forall (a :: k1). g a’, but ‘f’ has kind ‘k0’ • In the first argument of ‘F’, namely ‘((f :: forall a. g a) :: forall a. g a)’ In the type family declaration for ‘F’ | 9 | F ((f :: forall a. g a) :: forall a. g a) = Int | ^ }}} I'll add regression tests and close this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 13:59:11 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 13:59:11 -0000 Subject: [GHC] #14904: Compiler panic (piResultTy) In-Reply-To: <047.da803a71fb92b792256c7a85e0a6a6bc@haskell.org> References: <047.da803a71fb92b792256c7a85e0a6a6bc@haskell.org> Message-ID: <062.0f8387f1846bd34b63e0b0e301f7725c@haskell.org> #14904: Compiler panic (piResultTy) -------------------------------------+------------------------------------- Reporter: kcsongor | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14873 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by kcsongor): Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 14:17:30 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 14:17:30 -0000 Subject: [GHC] #14904: Compiler panic (piResultTy) In-Reply-To: <047.da803a71fb92b792256c7a85e0a6a6bc@haskell.org> References: <047.da803a71fb92b792256c7a85e0a6a6bc@haskell.org> Message-ID: <062.fa06378484f6f9156955f254d17af046@haskell.org> #14904: Compiler panic (piResultTy) -------------------------------------+------------------------------------- Reporter: kcsongor | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14873 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"5de0be8d7ee48eac0af42387eb40b5a5a9b08a35/ghc" 5de0be8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5de0be8d7ee48eac0af42387eb40b5a5a9b08a35" Add regression tests for #14904 Trac #14904 was fixed in commit faec8d358985e5d0bf363bd96f23fe76c9e281f7. Let's add some tests to ensure that it stays fixed. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 14:18:50 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 14:18:50 -0000 Subject: [GHC] #14904: Compiler panic (piResultTy) In-Reply-To: <047.da803a71fb92b792256c7a85e0a6a6bc@haskell.org> References: <047.da803a71fb92b792256c7a85e0a6a6bc@haskell.org> Message-ID: <062.d539140f8c7b741fcb95cd86a6294d7e@haskell.org> #14904: Compiler panic (piResultTy) -------------------------------------+------------------------------------- Reporter: kcsongor | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T14904a, | typecheck/should_fail/T14904b Blocked By: | Blocking: Related Tickets: #14873 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * testcase: => typecheck/should_fail/T14904a, typecheck/should_fail/T14904b * resolution: => fixed * milestone: => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 14:31:36 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 14:31:36 -0000 Subject: [GHC] #15079: GHC HEAD regression: cannot instantiate higher-rank kind In-Reply-To: <050.d29ab0a2c8c230faa38439fac305fb8f@haskell.org> References: <050.d29ab0a2c8c230faa38439fac305fb8f@haskell.org> Message-ID: <065.8fb6a93967ba5fbebec7635e4fa354e0@haskell.org> #15079: GHC HEAD regression: cannot instantiate higher-rank kind -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I too find it rather bizarre that the visibilities of each type variable binder have to line up when instantiating a higher-rank kind, since that isn't a requirement for higher-rank types: {{{#!hs {-# LANGUAGE RankNTypes #-} module Bug where id' x = x f :: (forall a. a -> a) -> b -> c -> (b, c) f g b c = (g b, g c) h :: b -> c -> (b, c) h = f id' }}} `h` typechecks, despite the fact that the type of `id'` is `forall {p}. p -> p` (i.e., with an inferred variable), and `f` is supposed to take an argument of type `forall a. a -> a` (i.e., with a specified variable). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 14:43:06 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 14:43:06 -0000 Subject: [GHC] #15079: GHC HEAD regression: cannot instantiate higher-rank kind In-Reply-To: <050.d29ab0a2c8c230faa38439fac305fb8f@haskell.org> References: <050.d29ab0a2c8c230faa38439fac305fb8f@haskell.org> Message-ID: <065.93781d1a4492d3ea41484ccb7aac2c41@haskell.org> #15079: GHC HEAD regression: cannot instantiate higher-rank kind -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Now that I have a better understanding of why this is failing, here's a simpler program which demonstrates the issue (this typechecks on GHC 8.4.2, but not HEAD): {{{#!hs {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind newtype Foo (f :: forall (a :: Type). a -> Type) = MkFoo (f Int) data InferredProxy a = MkInferredProxy foo :: Foo InferredProxy foo = MkFoo MkInferredProxy }}} {{{ $ ~/Software/ghc/inplace/bin/ghc-stage2 Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:11:13: error: • Kind mismatch: cannot unify (f0 :: forall a. a -> *) with: InferredProxy :: forall k. k -> * Their kinds differ. Expected type: f0 * Int Actual type: InferredProxy Int • In the first argument of ‘MkFoo’, namely ‘MkInferredProxy’ In the expression: MkFoo MkInferredProxy In an equation for ‘foo’: foo = MkFoo MkInferredProxy | 11 | foo = MkFoo MkInferredProxy | ^^^^^^^^^^^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 15:04:26 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 15:04:26 -0000 Subject: [GHC] #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) In-Reply-To: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> References: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> Message-ID: <057.c63e5c90c5f15b6d504f07509f0bbb47@haskell.org> #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 (CodeGen) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: T13658 at runtime | T14779a T14779b T14868 debug | parsing001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4654 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ömer Sinan Ağacan ): In [changeset:"358b508051333882d4099acca8f269e6fb2b7d65/ghc" 358b5080/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="358b508051333882d4099acca8f269e6fb2b7d65" Compute DW_FORM_block length correctly; also fixes #15068 Before this patch, the pprUnwindwExpr function computed the length of by the following assembly fragment: .uleb128 1f-.-1 1: That is, to compute the length, it takes the difference of the label 1 and the address of the .uleb128 directive, and subtracts 1. In #15068 it was reported that `as` from binutils 4.30 has trouble with evaluating the `.` part of the expression. However, there is actually a problem with the expression, if the length of the data ever becomes larger than 128: In that case, the .uleb128 directive will emit more than 1 byte, and the computed length will be wrong. The present patch changes the assembly fragment to use two labels, which fixes both these problems. .uleb128 2f-1f 1: 2: Test Plan: validate Reviewers: bgamari, osa1 Reviewed By: bgamari Subscribers: thomie, carter GHC Trac Issues: #15068 Differential Revision: https://phabricator.haskell.org/D4654 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 15:05:12 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 15:05:12 -0000 Subject: [GHC] #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) In-Reply-To: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> References: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> Message-ID: <057.2e543afb7d50eabc2a296025a0eaf6ec@haskell.org> #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 (CodeGen) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: T13658 at runtime | T14779a T14779b T14868 debug | parsing001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4654 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 15:08:52 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 15:08:52 -0000 Subject: [GHC] #15079: GHC HEAD regression: cannot instantiate higher-rank kind In-Reply-To: <050.d29ab0a2c8c230faa38439fac305fb8f@haskell.org> References: <050.d29ab0a2c8c230faa38439fac305fb8f@haskell.org> Message-ID: <065.04ca543c00debc38974d101fe3e10667@haskell.org> #15079: GHC HEAD regression: cannot instantiate higher-rank kind -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by simonpj): We await the Sage of Bryn-Mawr. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 15:20:14 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 15:20:14 -0000 Subject: [GHC] #14904: Compiler panic (piResultTy) In-Reply-To: <047.da803a71fb92b792256c7a85e0a6a6bc@haskell.org> References: <047.da803a71fb92b792256c7a85e0a6a6bc@haskell.org> Message-ID: <062.aeefb688dc424a818a2f9ad0f28ff459@haskell.org> #14904: Compiler panic (piResultTy) -------------------------------------+------------------------------------- Reporter: kcsongor | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T14904a, | typecheck/should_fail/T14904b Blocked By: | Blocking: Related Tickets: #14873 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Hooray for RyanGlScott! :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 16:06:42 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 16:06:42 -0000 Subject: [GHC] #15081: Finite list becomes infinite after maping fractional function for high numbers In-Reply-To: <044.f762bf620383822c5337aa8807210278@haskell.org> References: <044.f762bf620383822c5337aa8807210278@haskell.org> Message-ID: <059.027d8af580ad3268685d137d48890a66@haskell.org> #15081: Finite list becomes infinite after maping fractional function for high numbers -------------------------------------+------------------------------------- Reporter: Onsed | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | libraries/base/tests/enumNumeric Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4650 Wiki Page: | -------------------------------------+------------------------------------- Comment (by sighingnow): This ticket should be fixed by Phab:D4650, by using an increment accumulator to get the next enumerated number rather than adding 1 to previous number at every run. For more related discussion about the implementation and the result the benchmark, see Phab:D4650, and `Note [Numeric Stability of Enumerating Floating Numbers]` in base/GHC/Real.hs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 16:48:08 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 16:48:08 -0000 Subject: [GHC] #15019: Fix performance regressions from #14737 In-Reply-To: <047.36d31dd41a03f5d1b4531d3b52b0f31a@haskell.org> References: <047.36d31dd41a03f5d1b4531d3b52b0f31a@haskell.org> Message-ID: <062.08b226b1f89f6caadd6633ca80ae391e@haskell.org> #15019: Fix performance regressions from #14737 -------------------------------------+------------------------------------- Reporter: tdammers | Owner: tdammers Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #14737 | Differential Rev(s): phab:D4568 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Replying to [comment:14 simonpj]: > How did the patch in comment:13 work out? Absolutely gorgeous. Phab:D4635 shows improvement on all 3 tests that previously failed, they now even perform about 10% better than pre-#14737. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 16:52:16 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 16:52:16 -0000 Subject: [GHC] #15116: GHC internal error when GADT return type mentions its own constructor name Message-ID: <050.dc668ea98cda5bfcd872cc4585004dde@haskell.org> #15116: GHC internal error when GADT return type mentions its own constructor name -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 (Type checker) | Keywords: GADTs, | Operating System: Unknown/Multiple TypeInType | Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Take the following program: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeInType #-} module Bug where data A (a :: k) where MkA :: A MkA }}} On GHC 8.4.2, this is rejected with a sensible error message: {{{ $ /opt/ghc/8.4.2/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:6:12: error: • Data constructor ‘MkA’ cannot be used here (it is defined and used in the same recursive group) • In the first argument of ‘A’, namely ‘MkA’ In the type ‘A MkA’ In the definition of data constructor ‘MkA’ | 6 | MkA :: A MkA | ^^^ }}} On GHC HEAD, however, this causes a GHC internal error: {{{ $ ghc2/inplace/bin/ghc-stage2 Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:6:12: error: • GHC internal error: ‘MkA’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [asv :-> Type variable ‘k’ = k :: *, asw :-> Type variable ‘a’ = a :: k, rqs :-> ATcTyCon A :: forall k. k -> *] • In the first argument of ‘A’, namely ‘MkA’ In the type ‘A MkA’ In the definition of data constructor ‘MkA’ | 6 | MkA :: A MkA | ^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 17:34:41 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 17:34:41 -0000 Subject: [GHC] #15116: GHC internal error when GADT return type mentions its own constructor name In-Reply-To: <050.dc668ea98cda5bfcd872cc4585004dde@haskell.org> References: <050.dc668ea98cda5bfcd872cc4585004dde@haskell.org> Message-ID: <065.88ae3bf52e2016d6149025638f9856cd@haskell.org> #15116: GHC internal error when GADT return type mentions its own constructor name -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: GADTs, Resolution: | TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: goldfire (added) Comment: Commit faec8d358985e5d0bf363bd96f23fe76c9e281f7 (`Track type variable scope more carefully.`) caused this, although it's not obvious to me from a quick glance why this would be the case... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 18:42:22 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 18:42:22 -0000 Subject: [GHC] #15116: GHC internal error when GADT return type mentions its own constructor name In-Reply-To: <050.dc668ea98cda5bfcd872cc4585004dde@haskell.org> References: <050.dc668ea98cda5bfcd872cc4585004dde@haskell.org> Message-ID: <065.8cc91398f0fdf0b649a501bcc670b834@haskell.org> #15116: GHC internal error when GADT return type mentions its own constructor name -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: GADTs, Resolution: | TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Ah, I see what is going on. This is due to the following change in `kcLTyClDecl`: {{{#!diff kcLTyClDecl :: LTyClDecl GhcRn -> TcM () -- See Note [Kind checking for type and class decls] kcLTyClDecl (L loc decl) + | hsDeclHasCusk decl + = traceTc "kcTyClDecl skipped due to cusk" (ppr tc_name) + | otherwise = setSrcSpan loc $ tcAddDeclCtxt decl $ - do { traceTc "kcTyClDecl {" (ppr (tyClDeclLName decl)) + do { traceTc "kcTyClDecl {" (ppr tc_name) ; kcTyClDecl decl - ; traceTc "kcTyClDecl done }" (ppr (tyClDeclLName decl)) } + ; traceTc "kcTyClDecl done }" (ppr tc_name) } + where + tc_name = tyClDeclLName decl }}} Now, if the declaration has a CUSK, then `kcTyClDecl` is skipped entirely. As a consequence, subsequent checks for each data constructor (`kcConDecl`) are also skipped. But `kcConDecl` was what was throwing the error message for the original program, so skipping it leads to pandemonium later down the line. How should we fix this? I can think of at least a couple of possibilities: 1. Never skip `kcTyClDecl` if the declaration has constructors. 2. Do the `kcConDecl` checks separately from `kcTyClDecl`. Thoughts? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 19:01:47 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 19:01:47 -0000 Subject: [GHC] #15093: Testsuite should output JUnit XML for better CircleCI support In-Reply-To: <049.900d127190549a522493fcc24922ad0e@haskell.org> References: <049.900d127190549a522493fcc24922ad0e@haskell.org> Message-ID: <064.4c5cf5963f6b70d2302dfedb5760d537@haskell.org> #15093: Testsuite should output JUnit XML for better CircleCI support -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: CI Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"107d2cb7cc1e9c6d2226c3965e83a1b59d89ed04/ghc" 107d2cb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="107d2cb7cc1e9c6d2226c3965e83a1b59d89ed04" Don't shadow "result" in JUnit driver Reviewers: bgamari Reviewed By: bgamari Subscribers: thomie, carter GHC Trac Issues: #15093 Differential Revision: https://phabricator.haskell.org/D4645 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 19:02:02 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 19:02:02 -0000 Subject: [GHC] #15093: Testsuite should output JUnit XML for better CircleCI support In-Reply-To: <049.900d127190549a522493fcc24922ad0e@haskell.org> References: <049.900d127190549a522493fcc24922ad0e@haskell.org> Message-ID: <064.725963c432d2d36c1a597a9d4b1a5f98@haskell.org> #15093: Testsuite should output JUnit XML for better CircleCI support -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: CI Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"1ad0277e4e7fb0e742cbf9b78e1ed41174864b22/ghc" 1ad0277/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1ad0277e4e7fb0e742cbf9b78e1ed41174864b22" CircleCI: Save test results as JUnit XML Reviewers: mrkkrp, bgamari Reviewed By: mrkkrp, bgamari Subscribers: thomie, carter GHC Trac Issues: #15093 Differential Revision: https://phabricator.haskell.org/D4646 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 19:02:16 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 19:02:16 -0000 Subject: [GHC] #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) In-Reply-To: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> References: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> Message-ID: <057.0640f88aaf382560b31829c939503044@haskell.org> #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 (CodeGen) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: T13658 at runtime | T14779a T14779b T14868 debug | parsing001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4654 Wiki Page: | -------------------------------------+------------------------------------- Comment (by jrp): That seems to have sorted it! {{{ SUMMARY for test run started at Thu May 3 19:41:34 2018 BST 0:09:13 spent to go through 6355 total tests, which gave rise to 23662 test cases, of which 16961 were skipped 40 had missing libraries 6506 expected passes 155 expected failures }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 19:02:21 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 19:02:21 -0000 Subject: [GHC] #15049: NUMA not detected on Win10 with AMD Ryzen Threadripper In-Reply-To: <045.edd70e3debcebcfd2e64106f3d450d7f@haskell.org> References: <045.edd70e3debcebcfd2e64106f3d450d7f@haskell.org> Message-ID: <060.71ee9aa3ed0939cae2707631a439f80e@haskell.org> #15049: NUMA not detected on Win10 with AMD Ryzen Threadripper -----------------------------------+-------------------------------------- Reporter: kanetw | Owner: kanetw Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4607 Wiki Page: | -----------------------------------+-------------------------------------- Comment (by Ben Gamari ): In [changeset:"75361b119c609f0ab98f3d12a15690aae4ce42a1/ghc" 75361b1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="75361b119c609f0ab98f3d12a15690aae4ce42a1" Fix NUMA support on Windows (#15049) * osNumaNodes now returns the right number of nodes * thread affinity is now correctly set TODO: no noticeable performance improvement. does windows already distribute threads in a NUMA-aware fashion? Test Plan: * validate * local tests on a NUMA machine Reviewers: bgamari, erikd, simonmar Reviewed By: bgamari, simonmar Subscribers: thomie, carter Differential Revision: https://phabricator.haskell.org/D4607 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 19:02:37 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 19:02:37 -0000 Subject: [GHC] #14999: unwinding info for stg_catch_frame is wrong In-Reply-To: <046.c494a9ab46975a6daa3e5202496c7b13@haskell.org> References: <046.c494a9ab46975a6daa3e5202496c7b13@haskell.org> Message-ID: <061.f28e2aef2bb6595df8a2a6f817468f4c@haskell.org> #14999: unwinding info for stg_catch_frame is wrong -------------------------------------+------------------------------------- Reporter: niteria | Owner: niteria Type: bug | Status: patch Priority: normal | Milestone: 8.4.3 Component: Compiler | Version: Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Debugging | (amd64) information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D4606 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"6132d7c5e6404936ef281a6f3be333fea780906e/ghc" 6132d7c5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6132d7c5e6404936ef281a6f3be333fea780906e" Correctly add unwinding info in manifestSp and makeFixupBlocks In `manifestSp` the unwind info was before the relevant instruction, not after. I added some notes to establish semantics. Also removes redundant annotation in stg_catch_frame. For `makeFixupBlocks` it looks like we were off by `wORD_SIZE dflags`. I'm not sure why, but it lines up with `manifestSp`. In fact it lines up so well so that I can consolidate the Sp unwind logic in `maybeAddUnwind`. I detected the problems with `makeFixupBlocks` by running T14779b after patching D4559. Test Plan: added a new test Reviewers: bgamari, scpmw, simonmar, erikd Reviewed By: bgamari Subscribers: thomie, carter GHC Trac Issues: #14999 Differential Revision: https://phabricator.haskell.org/D4606 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 19:21:31 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 19:21:31 -0000 Subject: [GHC] #13896: Use response file to invoke hsc2hs In-Reply-To: <046.8d005e1593e32147d596c190fbabb716@haskell.org> References: <046.8d005e1593e32147d596c190fbabb716@haskell.org> Message-ID: <061.857886e8005dcd920f93cb1e5c5d3a9c@haskell.org> #13896: Use response file to invoke hsc2hs ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: ckoparkar Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: hsc2hs | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4612 Wiki Page: | ---------------------------------+---------------------------------------- Comment (by Ben Gamari ): In [changeset:"866525a1765715b8b9902e1bd53b9af1c7a93a30/ghc" 866525a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="866525a1765715b8b9902e1bd53b9af1c7a93a30" Move the ResponseFile module from haddock into base GHC and the build tools use "response files" to work around the limit on the length of command line arguments on Windows. Haddock's implementation of parsing response files (i.e escaping/unescaping the appropriate characters) seems complete, is well tested, and also closely matches the GCC version. This patch moves the relevant bits into `base` so that it's easier for other libraries to reuse it. Test Plan: make test TEST=T13896 Reviewers: bgamari, RyanGlScott, 23Skidoo, hvr Reviewed By: RyanGlScott Subscribers: thomie, carter GHC Trac Issues: #13896 Differential Revision: https://phabricator.haskell.org/D4612 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 19:21:47 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 19:21:47 -0000 Subject: [GHC] #15055: ghci - improve error on hidden package In-Reply-To: <043.0e347aaf83f899bb699c91fa0da78884@haskell.org> References: <043.0e347aaf83f899bb699c91fa0da78884@haskell.org> Message-ID: <058.a505b40ced398a627bcc04006f04d135@haskell.org> #15055: ghci - improve error on hidden package -------------------------------------+------------------------------------- Reporter: akfp | Owner: ckoparkar Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4621 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"721e82644b49da59e84c409562a63e7df75068bb/ghc" 721e8264/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="721e82644b49da59e84c409562a63e7df75068bb" GHCi: Improve the error message for hidden packages Test Plan: make test TEST=T15055 Reviewers: bgamari, RyanGlScott, osa1, Iceland_jack Reviewed By: osa1 Subscribers: ulysses4ever, thomie, carter GHC Trac Issues: #15055 Differential Revision: https://phabricator.haskell.org/D4621 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 19:22:03 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 19:22:03 -0000 Subject: [GHC] #14956: NUMA not detected on Aarch64 NUMA machine In-Reply-To: <045.7cfcebfe74212ddac33eec03cf3c48a1@haskell.org> References: <045.7cfcebfe74212ddac33eec03cf3c48a1@haskell.org> Message-ID: <060.689c1633ba859b278dc6ea964e518da5@haskell.org> #14956: NUMA not detected on Aarch64 NUMA machine -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 8.4.1 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4556, Wiki Page: | Phab:D4617 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"6462d90d01bcb07b8bff63689e8f2c8c20044952/ghc" 6462d90/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6462d90d01bcb07b8bff63689e8f2c8c20044952" rts: Throw better error if --numa is used without libnuma support Test Plan: Validate, run program with `+RTS --numa` without libnuma support compiled in Reviewers: erikd, simonmar Subscribers: thomie, carter GHC Trac Issues: #14956 Differential Revision: https://phabricator.haskell.org/D4556 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 19:23:57 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 19:23:57 -0000 Subject: [GHC] #15117: Add linting checks for DWARF unwind information Message-ID: <046.99e1d9bddf61dd7d8326fcca5a52c63d@haskell.org> #15117: Add linting checks for DWARF unwind information -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- DWARF unwind information is rather subtle and needs to be manually specified in some cases. Having at least some basic sanity checks would hep prevent against things like #14999. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 19:24:12 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 19:24:12 -0000 Subject: [GHC] #14999: unwinding info for stg_catch_frame is wrong In-Reply-To: <046.c494a9ab46975a6daa3e5202496c7b13@haskell.org> References: <046.c494a9ab46975a6daa3e5202496c7b13@haskell.org> Message-ID: <061.76b5fcd59b897fbc839bb0ddd6974097@haskell.org> #14999: unwinding info for stg_catch_frame is wrong -------------------------------------+------------------------------------- Reporter: niteria | Owner: niteria Type: bug | Status: closed Priority: normal | Milestone: 8.4.3 Component: Compiler | Version: 8.4.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Debugging | (amd64) information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D4606 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * version: => 8.4.2 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 19:24:33 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 19:24:33 -0000 Subject: [GHC] #15117: Add linting checks for DWARF unwind information In-Reply-To: <046.99e1d9bddf61dd7d8326fcca5a52c63d@haskell.org> References: <046.99e1d9bddf61dd7d8326fcca5a52c63d@haskell.org> Message-ID: <061.7ceb8d71231aaaf424d1b02fceb8639b@haskell.org> #15117: Add linting checks for DWARF unwind information -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * type: bug => task -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 19:24:41 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 19:24:41 -0000 Subject: [GHC] #14999: unwinding info for stg_catch_frame is wrong In-Reply-To: <046.c494a9ab46975a6daa3e5202496c7b13@haskell.org> References: <046.c494a9ab46975a6daa3e5202496c7b13@haskell.org> Message-ID: <061.925e442ccdfd061776c0452be4e323cb@haskell.org> #14999: unwinding info for stg_catch_frame is wrong -------------------------------------+------------------------------------- Reporter: niteria | Owner: niteria Type: bug | Status: closed Priority: normal | Milestone: 8.4.3 Component: Compiler | Version: 8.4.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Debugging | (amd64) information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D4606 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I've opened #15117 to track the addition of DWARF linters. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 19:25:15 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 19:25:15 -0000 Subject: [GHC] #15117: Add linting checks for DWARF unwind information In-Reply-To: <046.99e1d9bddf61dd7d8326fcca5a52c63d@haskell.org> References: <046.99e1d9bddf61dd7d8326fcca5a52c63d@haskell.org> Message-ID: <061.fb86755d89e620821ac8dcbcde28eb22@haskell.org> #15117: Add linting checks for DWARF unwind information -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4559 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D4559 Comment: Phab:D4559 starts this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 19:26:23 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 19:26:23 -0000 Subject: [GHC] #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) In-Reply-To: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> References: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> Message-ID: <057.b1f747eb96c14dba761b8d552ec822d3@haskell.org> #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 (CodeGen) | Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: T13658 at runtime | T14779a T14779b T14868 debug | parsing001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4654 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: I doubt we'll have another 8.4 release so closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 19:26:33 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 19:26:33 -0000 Subject: [GHC] #15049: NUMA not detected on Win10 with AMD Ryzen Threadripper In-Reply-To: <045.edd70e3debcebcfd2e64106f3d450d7f@haskell.org> References: <045.edd70e3debcebcfd2e64106f3d450d7f@haskell.org> Message-ID: <060.a30a84541b8bad89b9580cb71bff15c2@haskell.org> #15049: NUMA not detected on Win10 with AMD Ryzen Threadripper -----------------------------------+-------------------------------------- Reporter: kanetw | Owner: kanetw Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4607 Wiki Page: | -----------------------------------+-------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 19:27:23 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 19:27:23 -0000 Subject: [GHC] #15093: Testsuite should output JUnit XML for better CircleCI support In-Reply-To: <049.900d127190549a522493fcc24922ad0e@haskell.org> References: <049.900d127190549a522493fcc24922ad0e@haskell.org> Message-ID: <064.73e16fab2c6de3908f26f63e19f2f80a@haskell.org> #15093: Testsuite should output JUnit XML for better CircleCI support -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: CI Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: Thanks mpickering! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 19:28:47 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 19:28:47 -0000 Subject: [GHC] #15055: ghci - improve error on hidden package In-Reply-To: <043.0e347aaf83f899bb699c91fa0da78884@haskell.org> References: <043.0e347aaf83f899bb699c91fa0da78884@haskell.org> Message-ID: <058.80e61029c19c8438bc527733806aff48@haskell.org> #15055: ghci - improve error on hidden package -------------------------------------+------------------------------------- Reporter: akfp | Owner: ckoparkar Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.2 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4621 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 19:43:24 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 19:43:24 -0000 Subject: [GHC] #15115: `Numeric.showEFloat` does not honor precision with 0 digits In-Reply-To: <045.cd71602cfa60bbc0128fc78c2d018224@haskell.org> References: <045.cd71602cfa60bbc0128fc78c2d018224@haskell.org> Message-ID: <060.dd14b17ec71c16695bb66ad614bca340@haskell.org> #15115: `Numeric.showEFloat` does not honor precision with 0 digits -------------------------------------+------------------------------------- Reporter: guibou | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: libraries/base | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | libraries/base/tests/Numeric/num008 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4665 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * testcase: => libraries/base/tests/Numeric/num008 * differential: => Phab:D4665 Comment: Indeed this looks like a bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 19:43:34 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 19:43:34 -0000 Subject: [GHC] #15115: `Numeric.showEFloat` does not honor precision with 0 digits In-Reply-To: <045.cd71602cfa60bbc0128fc78c2d018224@haskell.org> References: <045.cd71602cfa60bbc0128fc78c2d018224@haskell.org> Message-ID: <060.480ceef2febe246ba4f143adda617bd7@haskell.org> #15115: `Numeric.showEFloat` does not honor precision with 0 digits -------------------------------------+------------------------------------- Reporter: guibou | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: libraries/base | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | libraries/base/tests/Numeric/num008 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4665 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 19:45:48 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 19:45:48 -0000 Subject: [GHC] #15109: T12425 is failing on CI since 3d38e8284b73 In-Reply-To: <043.96a8c019ca8d67abbdeb868f82e51005@haskell.org> References: <043.96a8c019ca8d67abbdeb868f82e51005@haskell.org> Message-ID: <058.4b40f8b67d148c6867dc8733cbedaf53@haskell.org> #15109: T12425 is failing on CI since 3d38e8284b73 -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: I bumped the numbers in 6212d01542e77b4f8855437280c641854fcd962b. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 21:12:55 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 21:12:55 -0000 Subject: [GHC] #15019: Fix performance regressions from #14737 In-Reply-To: <047.36d31dd41a03f5d1b4531d3b52b0f31a@haskell.org> References: <047.36d31dd41a03f5d1b4531d3b52b0f31a@haskell.org> Message-ID: <062.4af2475680b76892f4350b5394e5c64b@haskell.org> #15019: Fix performance regressions from #14737 -------------------------------------+------------------------------------- Reporter: tdammers | Owner: tdammers Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #14737 | Differential Rev(s): phab:D4568 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Great. Just add the data here (and/or in the commit message), commit, close, and move on! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 23:32:10 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 23:32:10 -0000 Subject: [GHC] #15118: Printing non-ASCII characters to console on Windows Message-ID: <045.f31d54520da23ecaf2ceb47ba029dea1@haskell.org> #15118: Printing non-ASCII characters to console on Windows -------------------------------------+------------------------------------- Reporter: lehins | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- As part of an initiative of getting stack to work properly on Windows for users with international names (https://github.com/commercialhaskell/stack/issues/3988) and working on trying to find a fix for {{{ghc-pkg}}} - #15021 I discovered a weird behavior that have been known for a while and does affect other languages, not only Haskell. First of all here is the default behavior on Windows with Locale that isn't Cyrillic for this program: {{{ main :: IO () main = putStrLn "Алексей Кулешевич" }}} {{{ PS C:\phab\windows-console> stack exec -- console console.EXE: : commitBuffer: invalid argument (invalid character) }}} Now consider this program: {{{ main :: IO () main = do hSetEncoding stdout utf8 putStrLn "Алексей Кулешевич" }}} Compiling and running it on Windows 7 with English locale results in: {{{ PS C:\phab\windows-console> stack exec -- console ╨É╨╗╨╡╨║╤ü╨╡╨╣ ╨Ü╤â╨╗╨╡╤ê╨╡╨▓╨╕╤ç PS C:\phab\windows-console> chcp 65001 Active code page: 65001 PS C:\phab\windows-console> stack exec -- console Алексей Кулешевич лешевич �ич }}} No knowledge of Russian is necessary in order to see that after the code page is set to {{{65001}}} there are characters printed to the console that don't belong there. That seems to be bug in Windows handling of unicode characters, since it's the exactly same result is `cmd` as well as Powershell and has been reported with other languages like Perl and Java. Worth noting that this also directly affects `ghc`, whenever {{{GHC_CHARENC}}} environment variable is set to {{{"UTF-8"}}}. Besides the bug being described above it is sad that we need to rely on both the code page and the handle encoding to be set correctly in order to even see the semi-correct output without a total program crash. The fix being proposed here is to use {{{WriteConsoleW}}} API call instead of writing to a handle, but only when the handle is actually a console and not pipe. This allows us to print unicode characters correctly without changing or relying on the setting of the current code page. Here is a sample output with my recent experiments: {{{ PS C:\phab\windows-console> chcp Active code page: 437 PS C:\phab\windows-console> stack exec -- console Алексей Кулешевич }}} I'll add some code examples of proposed solution in the upcoming days. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 3 23:47:15 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 May 2018 23:47:15 -0000 Subject: [GHC] #15021: ghc-pkg list crashes on Windows when unicode character is in the path In-Reply-To: <042.26589a8b8ccb1785877bd8d707d56c92@haskell.org> References: <042.26589a8b8ccb1785877bd8d707d56c92@haskell.org> Message-ID: <057.ed444e7155f092c903f18aacdb6bcac3@haskell.org> #15021: ghc-pkg list crashes on Windows when unicode character is in the path -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: ghc-pkg | Version: 8.2.2 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: GHC doesn't work | Unknown/Multiple at all | Test Case: Blocked By: | Blocking: Related Tickets: #10762, #15096 | Differential Rev(s): Phab:D4642 Wiki Page: | -------------------------------------+------------------------------------- Comment (by lehins): @bgamari, I was thinking it would be appropriate to simply change the code page of the console together with encoding on `stdout` handle, like I did in the example above, but doing a bit more research on this issue lead me to the conclusion that it would not be a valid way to go about it. Mutating global console state that can affect other processes is just not cool. I would like to say that your approach is the correct way to deal with this issue at the moment as it allows for ghc-pkg to function without errors, so I think you can disregard my previous comment. At the same time, while trying to figure this issue out I realized there is a bigger problem at hand and it is directly related to this ticket, but considering that it has much bigger impact and the solution would affect all Windows users I opened a separate ticket for it: #15118 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 4 07:32:06 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 May 2018 07:32:06 -0000 Subject: [GHC] #15118: Printing non-ASCII characters to console on Windows In-Reply-To: <045.f31d54520da23ecaf2ceb47ba029dea1@haskell.org> References: <045.f31d54520da23ecaf2ceb47ba029dea1@haskell.org> Message-ID: <060.a19593486116387d737b0146a656e1e7@haskell.org> #15118: Printing non-ASCII characters to console on Windows -------------------------------------+------------------------------------- Reporter: lehins | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4471 #11394 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => closed * resolution: => duplicate * related: => #4471 #11394 Comment: This is a duplicate of a number of tickets. We already know about the issue and the solution and have been working on it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 4 07:32:33 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 May 2018 07:32:33 -0000 Subject: [GHC] #15118: Printing non-ASCII characters to console on Windows In-Reply-To: <045.f31d54520da23ecaf2ceb47ba029dea1@haskell.org> References: <045.f31d54520da23ecaf2ceb47ba029dea1@haskell.org> Message-ID: <060.2c346a2273fd94d405e5970385dfd6cf@haskell.org> #15118: Printing non-ASCII characters to console on Windows ---------------------------------+---------------------------------------- Reporter: lehins | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: duplicate | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4471 #11394 | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by Phyx-): * os: Unknown/Multiple => Windows -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 4 07:35:12 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 May 2018 07:35:12 -0000 Subject: [GHC] #11394: Base should use native Win32 IO on Windows In-Reply-To: <046.3c711b381d30e89343445554e3990623@haskell.org> References: <046.3c711b381d30e89343445554e3990623@haskell.org> Message-ID: <061.af82fe6d07fa4080a843dd8ee09a8038@haskell.org> #11394: Base should use native Win32 IO on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 7.10.3 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Console part is implemented, file I/O is a bit more challenging to integrate as MIO isn't set up for asynchronous read/writes. It's taking a bit of time to iron out the correct interactions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 4 07:35:59 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 May 2018 07:35:59 -0000 Subject: [GHC] #11394: Base should use native Win32 IO on Windows In-Reply-To: <046.3c711b381d30e89343445554e3990623@haskell.org> References: <046.3c711b381d30e89343445554e3990623@haskell.org> Message-ID: <061.848759fe3e20d5d7d28e19c2132c4597@haskell.org> #11394: Base should use native Win32 IO on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Phyx- Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 7.10.3 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: (none) => Phyx- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 4 10:45:54 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 May 2018 10:45:54 -0000 Subject: [GHC] #15119: Program involving existentials and type class constraint gets rejected Message-ID: <044.70a5ab30fb88c05846a14a0a9a8ba5b5@haskell.org> #15119: Program involving existentials and type class constraint gets rejected -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 (Type checker) | Keywords: | 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: -------------------------------------+------------------------------------- The following example from https://stackoverflow.com/a/50160423/388010 demonstrates some code involving type classes and existentials that I'd love for it to pass the type checker: {{{#!hs {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeApplications #-} module Foo where class C a where getInt :: Int instance C Char where getInt = 42 f :: (forall a. C a => Int) -> Bool f x = even (x @ Char) g :: (forall a. C a => Int) -> Bool g = f -- fails -- g h = f h -- fails -- g h = f getInt -- fails -- g _ = f 42 -- OK }}} This complains with the following error: {{{ test.hs:17:5: error: • Could not deduce (C a0) from the context: C a bound by a type expected by the context: forall a. C a => Int at test.hs:17:5 The type variable ‘a0’ is ambiguous These potential instance exist: instance C Char -- Defined at test.hs:10:10 • In the expression: f In an equation for ‘g’: g = f | 17 | g = f -- fails | ^ }}} Is this expected behavior or a bug? I understand why the program leads to that particular error, but isn't there a way for the compiler to accept this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 4 11:13:34 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 May 2018 11:13:34 -0000 Subject: [GHC] #15116: GHC internal error when GADT return type mentions its own constructor name In-Reply-To: <050.dc668ea98cda5bfcd872cc4585004dde@haskell.org> References: <050.dc668ea98cda5bfcd872cc4585004dde@haskell.org> Message-ID: <065.18e16395ca6d4a2fcfe9c8a74cd24a4e@haskell.org> #15116: GHC internal error when GADT return type mentions its own constructor name -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: GADTs, Resolution: | TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 4 11:45:37 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 May 2018 11:45:37 -0000 Subject: [GHC] #15120: Default methods don't pass implicit kind parameters properly Message-ID: <047.099d2ac07bc80be9a0c2b1537006547c@haskell.org> #15120: Default methods don't pass implicit kind parameters properly -------------------------------------+------------------------------------- Reporter: mbieleck | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: PolyKinds, | Operating System: Unknown/Multiple DefaultSignatures | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When compiling the following module: {{{#!hs {-# LANGUAGE PolyKinds #-} {-# LANGUAGE DefaultSignatures #-} module TestCase where import Data.Proxy class Describe a where describe :: Proxy a -> String default describe :: Proxy a -> String describe _ = "" data Foo = Foo instance Describe Foo }}} I get the following error (on GHC 8.0.2 and 8.2.2, with `-fprint-explicit- kinds`): {{{ TestCase.hs:15:10: error: • Couldn't match type ‘*’ with ‘Foo’ Expected type: Proxy * Foo -> String Actual type: Proxy Foo Foo -> String • In the expression: TestCase.$dmdescribe @Foo In an equation for ‘describe’: describe = TestCase.$dmdescribe @Foo In the instance declaration for ‘Describe * Foo’ | 15 | instance Describe Foo | ^^^^^^^^^^^^ }}} The Core generated for `$dmdescribe` has the following type signature: {{{ TestCase.$dmdescribe :: forall k (a :: k). Describe k a => Proxy k a -> String }}} I believe the failure results from the fact that the type application `TestCase.$dmdescribe @Foo` passes `Foo` as the `k` parameter instead of `a`. Seems related to https://ghc.haskell.org/trac/ghc/ticket/13998 . -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 4 11:59:13 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 May 2018 11:59:13 -0000 Subject: [GHC] #15120: Default methods don't pass implicit kind parameters properly In-Reply-To: <047.099d2ac07bc80be9a0c2b1537006547c@haskell.org> References: <047.099d2ac07bc80be9a0c2b1537006547c@haskell.org> Message-ID: <062.f5a9faf0e0327adf53521355b7764144@haskell.org> #15120: Default methods don't pass implicit kind parameters properly -------------------------------------+------------------------------------- Reporter: mbieleck | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: duplicate | Keywords: PolyKinds, | DefaultSignatures Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #13998 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #13998 Comment: Indeed, this is a proper duplicate of #13998, as this program compiles on GHC 8.4 and later (the first release to debut the fix for #13998). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 4 12:08:28 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 May 2018 12:08:28 -0000 Subject: [GHC] #15119: Program involving existentials and type class constraint gets rejected In-Reply-To: <044.70a5ab30fb88c05846a14a0a9a8ba5b5@haskell.org> References: <044.70a5ab30fb88c05846a14a0a9a8ba5b5@haskell.org> Message-ID: <059.12777a9c91404a5b6e1c1f7b954a0afc@haskell.org> #15119: Program involving existentials and type class constraint gets rejected -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: 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: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): This is indeed expected. `a` is completely ambiguous in your program. The only type it ever appears in is `C a`, which is to the left of `=>`, and such types are always resolved through instance lookup, so GHC has trouble figuring out which particular instance you meant. The only type to the right of `=>`, `Int`, does not determine `a` either, so GHC throws up its hands and gives up. One way to make this program compile is to introduce an additional argument which determines `a`, such as in: {{{#!hs {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} module Foo where import Data.Proxy class C a where getInt :: Int instance C Char where getInt = 42 f :: (forall a. C a => Proxy a -> Int) -> Bool f x = even $ x $ Proxy @Char g :: (forall a. C a => Proxy a -> Int) -> Bool g = f }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 4 12:26:48 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 May 2018 12:26:48 -0000 Subject: [GHC] #15119: Program involving existentials and type class constraint gets rejected In-Reply-To: <044.70a5ab30fb88c05846a14a0a9a8ba5b5@haskell.org> References: <044.70a5ab30fb88c05846a14a0a9a8ba5b5@haskell.org> Message-ID: <059.b421d443aeaf198d4991b381220efe87@haskell.org> #15119: Program involving existentials and type class constraint gets rejected -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: 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: | -------------------------------------+------------------------------------- Comment (by sgraf): > `Proxy` Well, that's what I tried to avoid in this example. There's probably no way to get what I want using only `-XTypeApplications`, right? I was the one asking the SO question which boils down to asking for a System Fw style Big lambda. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 4 12:37:11 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 May 2018 12:37:11 -0000 Subject: [GHC] #15119: Program involving existentials and type class constraint gets rejected In-Reply-To: <044.70a5ab30fb88c05846a14a0a9a8ba5b5@haskell.org> References: <044.70a5ab30fb88c05846a14a0a9a8ba5b5@haskell.org> Message-ID: <059.48f108eba0e21b49cbe913bb613d1cb0@haskell.org> #15119: Program involving existentials and type class constraint gets rejected -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: 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: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Right, you're going to need //something// which determines `a`, be it `Proxy`, `Tagged`, or something else. There may come a day in which you can write: {{{#!hs forall a -> C a => Int }}} That is, where one can make `a` a visible argument (i.e., a "big lambda", as you've put it). But until then, you'll have to resort to baser tricks to accomplish what you seek. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 4 12:41:54 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 May 2018 12:41:54 -0000 Subject: [GHC] #15119: Program involving existentials and type class constraint gets rejected In-Reply-To: <044.70a5ab30fb88c05846a14a0a9a8ba5b5@haskell.org> References: <044.70a5ab30fb88c05846a14a0a9a8ba5b5@haskell.org> Message-ID: <059.ccb53532e3963c6a4787b5c77beb83c0@haskell.org> #15119: Program involving existentials and type class constraint gets rejected -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: wontfix | Keywords: 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: | -------------------------------------+------------------------------------- Changes (by sgraf): * status: new => closed * type: bug => feature request * resolution: => wontfix Comment: Let's hope that day isn't too far in the future :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 4 13:25:20 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 May 2018 13:25:20 -0000 Subject: [GHC] #15121: make install fails in 8.5 Message-ID: <047.a047a69bfc800da88b15bbad0cd4ce11@haskell.org> #15121: make install fails in 8.5 -------------------------------------+------------------------------------- Reporter: aspiwack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Build System | Version: 8.5 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: -------------------------------------+------------------------------------- On a fresh clone of GHC's master [ 79c4f10e4928c37bf4bbad974be0bd693df2d2b9 ]. The following steps {{{ ./boot ./configure make -j6 make install }}} Fail at the install phase with {{{ "inplace/bin/ghc-cabal" copy libraries/ghc-prim dist-install "strip" '' '/usr/local' '/usr/local/lib/ghc-8.5.20180503' '/usr/local/share/doc/ghc-8.5.20180503/html/libraries' 'v p dyn' Installing library in /usr/local/lib/ghc-8.5.20180503/ghc-prim-0.5.2.0 dist-install/build/HSghc-prim-0.5.2.0.o: copyFile: does not exist (No such file or directory) ghc.mk:996: recipe for target 'install_packages' failed make[1]: *** [install_packages] Error 1 }}} No `HSghc-prim-0.5.2.0.o` has been built, indeed, but a `libHSghc- prim-0.5.2.0.a` exists. I don't know if it's relevant. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 4 13:41:46 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 May 2018 13:41:46 -0000 Subject: [GHC] #15122: Compiling a library problem with a local 8.5 build Message-ID: <046.6b6ee0b02b0ede932ee344925ca869d9@haskell.org> #15122: Compiling a library problem with a local 8.5 build -------------------------------------+------------------------------------- Reporter: fmixing | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: GHC rejects (amd64) | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I’ve discovered that one library throws type checking exception when I try to compile it with my version of ghc compiler (I build it using `cabal new-build --with-compiler=/usr/local/bin/ghc-8.5.20180504`, the compiler was built from the master with 56974323ed427988059b5153bb43c694358cbb9b as the last commit), but it builds with 8.4.2 compiler (cabal new-build --with-compiler=/usr/local/bin/ghc-8.4.2). It’s really strange, so I tried to `make` the local version of 8.4.2 in the branch ghc-8.4.2-release, and found out that it cannot be built because there are missing some files that are necessary for build. So maybe I’m doing something wrong? And can it be that this library doesn’t type check with 8.5 because it’s built from source files? The exception can be seen here: https://gist.github.com/fmixing/93d140dc7dbe25199af28616c6a143da -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 4 13:42:43 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 May 2018 13:42:43 -0000 Subject: [GHC] #15122: Compiling a library problem with a local 8.5 build In-Reply-To: <046.6b6ee0b02b0ede932ee344925ca869d9@haskell.org> References: <046.6b6ee0b02b0ede932ee344925ca869d9@haskell.org> Message-ID: <061.c20ea402981eecc910745f01b0fc7b4e@haskell.org> #15122: Compiling a library problem with a local 8.5 build -------------------------------------+------------------------------------- Reporter: fmixing | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by fmixing: Old description: > I’ve discovered that one library throws type checking exception when I > try to compile it with my version of ghc compiler (I build it using > `cabal new-build --with-compiler=/usr/local/bin/ghc-8.5.20180504`, the > compiler was built from the master with > 56974323ed427988059b5153bb43c694358cbb9b as the last commit), but it > builds with 8.4.2 compiler (cabal new-build --with- > compiler=/usr/local/bin/ghc-8.4.2). It’s really strange, so I tried to > `make` the local version of 8.4.2 in the branch ghc-8.4.2-release, and > found out that it cannot be built because there are missing some files > that are necessary for build. So maybe I’m doing something wrong? And > can it be that this library doesn’t type check with 8.5 because it’s > built from source files? > > The exception can be seen here: > https://gist.github.com/fmixing/93d140dc7dbe25199af28616c6a143da New description: I’ve discovered that one library throws type checking exception when I try to compile it with my version of ghc compiler (I build it using `cabal new-build --with-compiler=/usr/local/bin/ghc-8.5.20180504`, the compiler was built from the master with 56974323ed427988059b5153bb43c694358cbb9b as the last commit), but it builds with 8.4.2 compiler (`cabal new-build --with-compiler=/usr/local/bin/ghc-8.4.2`). It’s really strange, so I tried to `make` the local version of 8.4.2 in the branch ghc-8.4.2-release, and found out that it cannot be built because there are missing some files that are necessary for build. So maybe I’m doing something wrong? And can it be that this library doesn’t type check with 8.5 because it’s built from source files? The exception can be seen here: https://gist.github.com/fmixing/93d140dc7dbe25199af28616c6a143da -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 4 13:53:27 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 May 2018 13:53:27 -0000 Subject: [GHC] #15122: Compiling a library problem with a local 8.5 build In-Reply-To: <046.6b6ee0b02b0ede932ee344925ca869d9@haskell.org> References: <046.6b6ee0b02b0ede932ee344925ca869d9@haskell.org> Message-ID: <061.5371ec471683ef8e74727a640368fecf@haskell.org> #15122: Compiling a library problem with a local 8.5 build -------------------------------------+------------------------------------- Reporter: fmixing | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): You may have found a bug but it's impossible to say without knowing what you are trying to compile. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 4 13:56:21 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 May 2018 13:56:21 -0000 Subject: [GHC] #15121: make install fails in 8.5 In-Reply-To: <047.a047a69bfc800da88b15bbad0cd4ce11@haskell.org> References: <047.a047a69bfc800da88b15bbad0cd4ce11@haskell.org> Message-ID: <062.2d8c7f416e0cc1c9a1960a6f28e93802@haskell.org> #15121: make install fails in 8.5 -------------------------------------+------------------------------------- Reporter: aspiwack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Build System | Version: 8.5 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by aspiwack): * status: new => closed * resolution: => invalid Comment: Never mind. There was a typo in my build command. Which made the process sort of work, but not completely. Which I realised after writing this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 4 13:58:25 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 May 2018 13:58:25 -0000 Subject: [GHC] #15019: Fix performance regressions from #14737 In-Reply-To: <047.36d31dd41a03f5d1b4531d3b52b0f31a@haskell.org> References: <047.36d31dd41a03f5d1b4531d3b52b0f31a@haskell.org> Message-ID: <062.bf7fad8a7ce82b4b7d17f3bfc3fe8123@haskell.org> #15019: Fix performance regressions from #14737 -------------------------------------+------------------------------------- Reporter: tdammers | Owner: tdammers Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #14737 | Differential Rev(s): phab:D4568 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Improvements should be evident from the changes in the tests, but here they are: - T5321FD: - Before: 415136648 - After: 367567168 (down 11.5%) - T9020: - Before: 423163832 - #14737: 562206104 (up 32.9%) - After: 392559256 (down 7.2% from Before) - T12425: - Before: 134780272 - #14737: 141952368 (up 5.3%) - After: 130646336 (down 3.1% from Before) None of the other test cases show any regressions, including the test added for #14737. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 4 14:02:18 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 May 2018 14:02:18 -0000 Subject: [GHC] #15019: Fix performance regressions from #14737 In-Reply-To: <047.36d31dd41a03f5d1b4531d3b52b0f31a@haskell.org> References: <047.36d31dd41a03f5d1b4531d3b52b0f31a@haskell.org> Message-ID: <062.e0b07dfad74ae4535c7b7c406248ca88@haskell.org> #15019: Fix performance regressions from #14737 -------------------------------------+------------------------------------- Reporter: tdammers | Owner: tdammers Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #14737 | Differential Rev(s): phab:D4568 Wiki Page: | -------------------------------------+------------------------------------- Changes (by tdammers): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 4 14:08:16 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 May 2018 14:08:16 -0000 Subject: [GHC] #15122: Compiling a library problem with a local 8.5 build In-Reply-To: <046.6b6ee0b02b0ede932ee344925ca869d9@haskell.org> References: <046.6b6ee0b02b0ede932ee344925ca869d9@haskell.org> Message-ID: <061.f8866e139190840df0bddb42143c24b9@haskell.org> #15122: Compiling a library problem with a local 8.5 build -------------------------------------+------------------------------------- Reporter: fmixing | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by fmixing): Replying to [comment:2 mpickering]: > You may have found a bug but it's impossible to say without knowing what you are trying to compile. type-level-sets library from https://github.com/dorchard/type-level-sets. It cannot be installed by `cabal install` because it is lacking of `TypeInType` extension in `Data.Type.Set`, so I downloaded it, added extension, imported `import GHC.Types`, `*` replaced with `GHC.Types.*`. So the current `Data.Type.Set` looks like https://gist.github.com/fmixing/695d46c6c5cc97398c3c44e05f23d764 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 4 14:31:35 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 May 2018 14:31:35 -0000 Subject: [GHC] #15107: Testsuite failures on Windows In-Reply-To: <046.8e0cbe335a7ce09f5a7e747d4e07162e@haskell.org> References: <046.8e0cbe335a7ce09f5a7e747d4e07162e@haskell.org> Message-ID: <061.6ab3c038573464971d6cb1af8d21ffdb@haskell.org> #15107: Testsuite failures on Windows -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4668 Wiki Page: | Phab:D4667 -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => patch * differential: => Phab:D4668 Phab:D4667 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 4 14:33:50 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 May 2018 14:33:50 -0000 Subject: [GHC] #8095: TypeFamilies painfully slow In-Reply-To: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> References: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> Message-ID: <065.8b1e175e1014e768042f21622da2ada1@haskell.org> #8095: TypeFamilies painfully slow -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5321, #11598, | Differential Rev(s): Phab:D3752 #12506, #13386 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by kcsongor): * cc: kcsongor (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 4 14:44:29 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 May 2018 14:44:29 -0000 Subject: [GHC] #15122: GHC HEAD typechecker regression involving overlapping instances (was: Compiling a library problem with a local 8.5 build) In-Reply-To: <046.6b6ee0b02b0ede932ee344925ca869d9@haskell.org> References: <046.6b6ee0b02b0ede932ee344925ca869d9@haskell.org> Message-ID: <061.1e706b2aa98b54e3db5e089c4c282e78@haskell.org> #15122: GHC HEAD typechecker regression involving overlapping instances -------------------------------------+------------------------------------- Reporter: fmixing | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * priority: normal => highest * os: MacOS X => Unknown/Multiple * component: Compiler => Compiler (Type checker) * architecture: x86_64 (amd64) => Unknown/Multiple Comment: Here is a slightly more minimal example: {{{#!hs {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} module Bug where data Proxy (p :: k) = Proxy data Set (n :: [k]) where Empty :: Set '[] Ext :: e -> Set s -> Set (e ': s) type family (m :: [k]) :\ (x :: k) :: [k] where '[] :\ x = '[] (x ': xs) :\ x = xs (y ': xs) :\ x = y ': (xs :\ x) class Remove s t where remove :: Set s -> Proxy t -> Set (s :\ t) instance Remove '[] t where remove Empty Proxy = Empty instance {-# OVERLAPS #-} Remove (x ': xs) x where remove (Ext _ xs) Proxy = xs instance {-# OVERLAPPABLE #-} (((y : xs) :\ x) ~ (y : (xs :\ x)), Remove xs x) => Remove (y ': xs) x where remove (Ext y xs) (x at Proxy) = Ext y (remove xs x) }}} In GHC 8.4.2, this typechecks, but in GHC HEAD, it fails with: {{{ $ /opt/ghc/head/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:31:33: error: • Could not deduce: ((e : s) :\ x) ~ (e : (s :\ x)) from the context: (((y : xs) :\ x) ~ (y : (xs :\ x)), Remove xs x) bound by the instance declaration at Bug.hs:(29,31)-(30,27) or from: (k ~ *, (y : xs :: [k]) ~~ (e : s :: [*])) bound by a pattern with constructor: Ext :: forall e (s :: [*]). e -> Set s -> Set (e : s), in an equation for ‘remove’ at Bug.hs:31:11-18 Expected type: Set ((y : xs) :\ x) Actual type: Set (e : (s :\ x)) • In the expression: Ext y (remove xs x) In an equation for ‘remove’: remove (Ext y xs) (x at Proxy) = Ext y (remove xs x) In the instance declaration for ‘Remove (y : xs) x’ • Relevant bindings include x :: Proxy x (bound at Bug.hs:31:22) xs :: Set s (bound at Bug.hs:31:17) y :: e (bound at Bug.hs:31:15) remove :: Set (y : xs) -> Proxy x -> Set ((y : xs) :\ x) (bound at Bug.hs:31:3) | 31 | remove (Ext y xs) (x at Proxy) = Ext y (remove xs x) | ^^^^^^^^^^^^^^^^^^^ }}} I'm unclear on what the exact culprit is here, so feel free to change the title further if overlapping instances turn out not to be the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 4 15:18:53 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 May 2018 15:18:53 -0000 Subject: [GHC] #14547: Wrong warning by -Wincomplete-patterns In-Reply-To: <052.21a9ad8704f084ec9db31f385a693f01@haskell.org> References: <052.21a9ad8704f084ec9db31f385a693f01@haskell.org> Message-ID: <067.94bf65b7f9a89d9e1bf7967c884e8e65@haskell.org> #14547: Wrong warning by -Wincomplete-patterns -------------------------------------+------------------------------------- Reporter: YoshikuniJujo | Owner: (none) Type: bug | Status: patch Priority: low | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: incomplete- | patterns OverloadedLists, | PatternMatchWarnings TypeFamilies Operating System: Linux | Architecture: x86 Type of failure: Incorrect | Test Case: error/warning at compile-time | deSugar/should_compile/T14547 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4624 Wiki Page: | -------------------------------------+------------------------------------- Comment (by sighingnow): Replying to [comment:10 simonpj]: I misread your previous comment, my bad. > Bottom line: check for `NoRebindableSyntax`! I have revised the Phab:D4624. Now when `RebindableSyntax` is enabled we treat the overloaded list pattern as ordinary view pattern. I have added some comments about this problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 4 15:29:25 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 May 2018 15:29:25 -0000 Subject: [GHC] #10572: Type signatures are not implicitly quantified over TH type variables In-Reply-To: <045.ba132a89df5c5be9ce7705320ad52764@haskell.org> References: <045.ba132a89df5c5be9ce7705320ad52764@haskell.org> Message-ID: <060.8c9a41961f6210659c76e3a54362d752@haskell.org> #10572: Type signatures are not implicitly quantified over TH type variables -------------------------------------+------------------------------------- Reporter: spinda | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sighingnow): * status: patch => new * testcase: tests/th/T10572a, tests/th/T10572a => * differential: Phab:D4641 => Comment: I have realized that my previous patch couldn't remedy the situation. I have mark my previous patch as abandoned. For > f :: $(g 'a) -> a This patch doesn't work. Sorry for the noise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 4 15:40:35 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 May 2018 15:40:35 -0000 Subject: [GHC] #15122: GHC HEAD typechecker regression involving overlapping instances In-Reply-To: <046.6b6ee0b02b0ede932ee344925ca869d9@haskell.org> References: <046.6b6ee0b02b0ede932ee344925ca869d9@haskell.org> Message-ID: <061.703ecd6807f14ac7a59f91e42a28fe79@haskell.org> #15122: GHC HEAD typechecker regression involving overlapping instances -------------------------------------+------------------------------------- Reporter: fmixing | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: goldfire (added) Comment: This regression was introduced in commit e3dbb44f53b2f9403d20d84e27f187062755a089 (Fix #12919 by making the flattener homegeneous.). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 4 15:42:21 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 May 2018 15:42:21 -0000 Subject: [GHC] #15122: GHC HEAD typechecker regression involving overlapping instances In-Reply-To: <046.6b6ee0b02b0ede932ee344925ca869d9@haskell.org> References: <046.6b6ee0b02b0ede932ee344925ca869d9@haskell.org> Message-ID: <061.4d03370622857d855a2c9c4ff0ef51f3@haskell.org> #15122: GHC HEAD typechecker regression involving overlapping instances -------------------------------------+------------------------------------- Reporter: fmixing | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: 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: | -------------------------------------+------------------------------------- Description changed by RyanGlScott: Old description: > I’ve discovered that one library throws type checking exception when I > try to compile it with my version of ghc compiler (I build it using > `cabal new-build --with-compiler=/usr/local/bin/ghc-8.5.20180504`, the > compiler was built from the master with > 56974323ed427988059b5153bb43c694358cbb9b as the last commit), but it > builds with 8.4.2 compiler (`cabal new-build --with- > compiler=/usr/local/bin/ghc-8.4.2`). It’s really strange, so I tried to > `make` the local version of 8.4.2 in the branch ghc-8.4.2-release, and > found out that it cannot be built because there are missing some files > that are necessary for build. So maybe I’m doing something wrong? And > can it be that this library doesn’t type check with 8.5 because it’s > built from source files? > > The exception can be seen here: > https://gist.github.com/fmixing/93d140dc7dbe25199af28616c6a143da New description: This code, distilled from the `type-level-sets` library: {{{#!hs {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} module Bug where data Proxy (p :: k) = Proxy data Set (n :: [k]) where Empty :: Set '[] Ext :: e -> Set s -> Set (e ': s) type family (m :: [k]) :\ (x :: k) :: [k] where '[] :\ x = '[] (x ': xs) :\ x = xs (y ': xs) :\ x = y ': (xs :\ x) class Remove s t where remove :: Set s -> Proxy t -> Set (s :\ t) instance Remove '[] t where remove Empty Proxy = Empty instance {-# OVERLAPS #-} Remove (x ': xs) x where remove (Ext _ xs) Proxy = xs instance {-# OVERLAPPABLE #-} (((y : xs) :\ x) ~ (y : (xs :\ x)), Remove xs x) => Remove (y ': xs) x where remove (Ext y xs) (x at Proxy) = Ext y (remove xs x) }}} Typechecks in GHC 8.4.2, but not in GHC HEAD: {{{ $ /opt/ghc/head/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:31:33: error: • Could not deduce: ((e : s) :\ x) ~ (e : (s :\ x)) from the context: (((y : xs) :\ x) ~ (y : (xs :\ x)), Remove xs x) bound by the instance declaration at Bug.hs:(29,31)-(30,27) or from: (k ~ *, (y : xs :: [k]) ~~ (e : s :: [*])) bound by a pattern with constructor: Ext :: forall e (s :: [*]). e -> Set s -> Set (e : s), in an equation for ‘remove’ at Bug.hs:31:11-18 Expected type: Set ((y : xs) :\ x) Actual type: Set (e : (s :\ x)) • In the expression: Ext y (remove xs x) In an equation for ‘remove’: remove (Ext y xs) (x at Proxy) = Ext y (remove xs x) In the instance declaration for ‘Remove (y : xs) x’ • Relevant bindings include x :: Proxy x (bound at Bug.hs:31:22) xs :: Set s (bound at Bug.hs:31:17) y :: e (bound at Bug.hs:31:15) remove :: Set (y : xs) -> Proxy x -> Set ((y : xs) :\ x) (bound at Bug.hs:31:3) | 31 | remove (Ext y xs) (x at Proxy) = Ext y (remove xs x) | ^^^^^^^^^^^^^^^^^^^ }}} This regression was introduced in commit e3dbb44f53b2f9403d20d84e27f187062755a089 (Fix #12919 by making the flattener homegeneous.). -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 4 16:08:07 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 May 2018 16:08:07 -0000 Subject: [GHC] #15123: mg_arg_tys in MatchGroup should be a PostTc field Message-ID: <049.b73ba786288414e65d50b5c03357a2a6@haskell.org> #15123: mg_arg_tys in MatchGroup should be a PostTc field -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: newcomer | 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 appears that `mg_arg_tys` is only populated after typechecking but the type does not indicate this. Instead of {{{ mg_arg_tys :: [PostTc p Type] }}} the type should be {{{ mg_arg_tys :: PostTc p [Type] }}} All that needs doing is modifying this type in compiler/HsSyn/HsExpr.hs and then fixing the resulting compiler errors. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 4 17:58:34 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 May 2018 17:58:34 -0000 Subject: [GHC] #15116: GHC internal error when GADT return type mentions its own constructor name In-Reply-To: <050.dc668ea98cda5bfcd872cc4585004dde@haskell.org> References: <050.dc668ea98cda5bfcd872cc4585004dde@haskell.org> Message-ID: <065.b6b1e761f9dcecbac93f7b1c5adae8cb@haskell.org> #15116: GHC internal error when GADT return type mentions its own constructor name -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: GADTs, Resolution: | TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Written before Simon's "I'm on this", but I thought it worthy of posting anyway: I like: 3. Add the right `APromotionErr` entries into the env't for `tcConDecl`. `kcTyClGroup` calls `getInitialKinds`, which returns a `NameEnv TcTyThing`, mapping names to `TcTyThing`s. Note how `TcTyThing` includes the `APromotionErr` constructor (see its definition in `TcRnTypes`). ``getInitialKinds` not only maps tycon names to `TcTyCon`s (stored in `ATcTyCon`) but it also maps datacons to `APromotionErr`s. This is done in `getInitialKinds`'s call to `mkPromotionErrorEnv`. So, when we look up a datacon in `kcTyClDecl`, we get a `APromotionErr`, just as we should. Compare to the env't in place for `tcTyClDecls`, which is built with `zipRecTyClss`. This env't does ''not'' have the `APromotionErr`s. (See comment above the call to `zipRecTyClss`.) The solution is to extend the env't used in type checking to have the `APromotionErr` entries -- but only for the datacons, not for the tycons (which are no longer errors!). So you'd This is gnarly code, but this aspect of it isn't as complicated as others. It would make for a good exercise for someone (cough cough) who is working toward becoming an Official Type Checker Grease Monkey. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 4 18:30:10 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 May 2018 18:30:10 -0000 Subject: [GHC] #15086: hT profiling option In-Reply-To: <047.6ebe77afde6007a7c0d9af0949915a5b@haskell.org> References: <047.6ebe77afde6007a7c0d9af0949915a5b@haskell.org> Message-ID: <062.7a80d619148e2f85d646a567a7ef9c14@haskell.org> #15086: hT profiling option -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4643 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Fixed by enabling use of `-hT` in the profiled RTS (b7b6617a90824303daf555c817f538cd9c792671). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 5 10:07:10 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 May 2018 10:07:10 -0000 Subject: [GHC] #5910: Holes with other constraints In-Reply-To: <045.7ce17b393921f6c85549a3e0d688b66c@haskell.org> References: <045.7ce17b393921f6c85549a3e0d688b66c@haskell.org> Message-ID: <060.77ecb59f88aa7a7aad1d6c81a7755431@haskell.org> #5910: Holes with other constraints -------------------------------------+------------------------------------- Reporter: xnyhps | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.5 checker) | Resolution: | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mentheta): * cc: mentheta (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 5 16:24:07 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 May 2018 16:24:07 -0000 Subject: [GHC] #8995: When generalising, use levels rather than global tyvars In-Reply-To: <046.9987efe4c8232a1075e003930ca5ea84@haskell.org> References: <046.9987efe4c8232a1075e003930ca5ea84@haskell.org> Message-ID: <061.243463c946da445a502d0eacb971afdb@haskell.org> #8995: When generalising, use levels rather than global tyvars -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nfrisby): * cc: nfrisby (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 5 16:49:55 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 May 2018 16:49:55 -0000 Subject: [GHC] #15055: ghci - improve error on hidden package In-Reply-To: <043.0e347aaf83f899bb699c91fa0da78884@haskell.org> References: <043.0e347aaf83f899bb699c91fa0da78884@haskell.org> Message-ID: <058.f13f34ed589defb823d260afe028366a@haskell.org> #15055: ghci - improve error on hidden package -------------------------------------+------------------------------------- Reporter: akfp | Owner: ckoparkar Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.2 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4621, Wiki Page: | Phab:D4669 -------------------------------------+------------------------------------- Changes (by ckoparkar): * differential: Phab:D4621 => Phab:D4621, Phab:D4669 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 5 17:26:35 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 May 2018 17:26:35 -0000 Subject: [GHC] #15086: hT profiling option In-Reply-To: <047.6ebe77afde6007a7c0d9af0949915a5b@haskell.org> References: <047.6ebe77afde6007a7c0d9af0949915a5b@haskell.org> Message-ID: <062.6b95d6f5eca305c1666b5357a00dad2a@haskell.org> #15086: hT profiling option -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4643 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"49f594307d0615e6b32d054d39364d85d2d6317e/ghc" 49f59430/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="49f594307d0615e6b32d054d39364d85d2d6317e" rel-notes: Note that -hT is now allowed See #15086. [skip-ci] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 5 17:26:50 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 May 2018 17:26:50 -0000 Subject: [GHC] #15082: Split the TrieMap module into a generic and core specific part. In-Reply-To: <047.d3ab51f1d4f146ab4b3c2692005482ff@haskell.org> References: <047.d3ab51f1d4f146ab4b3c2692005482ff@haskell.org> Message-ID: <062.afe5d68a8844dbe7180409989825896a@haskell.org> #15082: Split the TrieMap module into a generic and core specific part. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: task | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4618 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"426ae98852be498fa87d10e4c88ba8d726d6b320/ghc" 426ae988/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="426ae98852be498fa87d10e4c88ba8d726d6b320" Split TrieMap into a general (TrieMap) and core specific (CoreTrieMap) module. Splitting TrieMap into a general and core specific part allows us to define instances for TrieMap without creating a transitive dependency on CoreSyn. Test Plan: ci Reviewers: goldfire, bgamari, simonmar, simonpj Reviewed By: bgamari, simonpj Subscribers: simonpj, nomeata, thomie, carter GHC Trac Issues: #15082 Differential Revision: https://phabricator.haskell.org/D4618 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 5 17:27:06 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 May 2018 17:27:06 -0000 Subject: [GHC] #14547: Wrong warning by -Wincomplete-patterns In-Reply-To: <052.21a9ad8704f084ec9db31f385a693f01@haskell.org> References: <052.21a9ad8704f084ec9db31f385a693f01@haskell.org> Message-ID: <067.cf583d02cf39b3a8f0a69596d9e889b0@haskell.org> #14547: Wrong warning by -Wincomplete-patterns -------------------------------------+------------------------------------- Reporter: YoshikuniJujo | Owner: (none) Type: bug | Status: patch Priority: low | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: incomplete- | patterns OverloadedLists, | PatternMatchWarnings TypeFamilies Operating System: Linux | Architecture: x86 Type of failure: Incorrect | Test Case: error/warning at compile-time | deSugar/should_compile/T14547 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4624 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"361d23a8ebb44f5df5167306d7b98d8bd1724e06/ghc" 361d23a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="361d23a8ebb44f5df5167306d7b98d8bd1724e06" Normalize the element type of ListPat, fix #14547 The element type of `List` maybe a type family instacen, rather than a trivial type. For example in Trac #14547, ``` {-# LANGUAGE TypeFamilies, OverloadedLists #-} class Foo f where type It f foo :: [It f] -> f data List a = Empty | a :! List a deriving Show instance Foo (List a) where type It (List a) = a foo [] = Empty foo (x : xs) = x :! foo xs ``` Here the element type of `[]` is `It (List a)`, we should also normalize it as `a`. Test Plan: make test TEST="T14547" Reviewers: bgamari Reviewed By: bgamari Subscribers: thomie, carter GHC Trac Issues: #14547 Differential Revision: https://phabricator.haskell.org/D4624 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 5 17:27:21 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 May 2018 17:27:21 -0000 Subject: [GHC] #15067: When Typeable and unboxed sums collide, GHC panics In-Reply-To: <050.61b6b35d8587a28e0de8c6a6604fc205@haskell.org> References: <050.61b6b35d8587a28e0de8c6a6604fc205@haskell.org> Message-ID: <065.155ac1aa932d406e928f10ca48fcf949@haskell.org> #15067: When Typeable and unboxed sums collide, GHC panics -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.1 checker) | Keywords: Typeable, Resolution: | UnboxedSums Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13276 | Differential Rev(s): Phab:D4622, Wiki Page: | Phab:D4623 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"0f046aae5c9552771e489dac8531744034f37cde/ghc" 0f046aa/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0f046aae5c9552771e489dac8531744034f37cde" testsuite: Add test for #15067 Subscribers: thomie, carter, RyanGlScott GHC Trac Issues: #15067 Differential Revision: https://phabricator.haskell.org/D4622 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 5 17:27:37 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 May 2018 17:27:37 -0000 Subject: [GHC] #14982: LLVM default -mcpu setting inhibits customization In-Reply-To: <044.53df70951b1c182c6fcc3c10dbfa5883@haskell.org> References: <044.53df70951b1c182c6fcc3c10dbfa5883@haskell.org> Message-ID: <059.7d458a21f9a25cf8e9bb53bc24a7384f@haskell.org> #14982: LLVM default -mcpu setting inhibits customization -------------------------------------+------------------------------------- Reporter: tommd | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.2 Component: Compiler (LLVM) | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D4548 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"cb1ee7e10e50b11b4a24e56b425e8f3485d298d5/ghc" cb1ee7e1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="cb1ee7e10e50b11b4a24e56b425e8f3485d298d5" Do not supply `-mcpu` if `-optlc` provides `-mcpu` already. Reviewers: bgamari Subscribers: thomie, carter GHC Trac Issues: #14982 Differential Revision: https://phabricator.haskell.org/D4548 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 5 17:28:42 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 May 2018 17:28:42 -0000 Subject: [GHC] #14547: Wrong warning by -Wincomplete-patterns In-Reply-To: <052.21a9ad8704f084ec9db31f385a693f01@haskell.org> References: <052.21a9ad8704f084ec9db31f385a693f01@haskell.org> Message-ID: <067.8240b5bb1552d05686704dd358ae4816@haskell.org> #14547: Wrong warning by -Wincomplete-patterns -------------------------------------+------------------------------------- Reporter: YoshikuniJujo | Owner: (none) Type: bug | Status: closed Priority: low | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: incomplete- | patterns OverloadedLists, | PatternMatchWarnings TypeFamilies Operating System: Linux | Architecture: x86 Type of failure: Incorrect | Test Case: error/warning at compile-time | deSugar/should_compile/T14547 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4624 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 5 17:28:50 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 May 2018 17:28:50 -0000 Subject: [GHC] #15082: Split the TrieMap module into a generic and core specific part. In-Reply-To: <047.d3ab51f1d4f146ab4b3c2692005482ff@haskell.org> References: <047.d3ab51f1d4f146ab4b3c2692005482ff@haskell.org> Message-ID: <062.6125c15a09431c11311f016e9c1220fd@haskell.org> #15082: Split the TrieMap module into a generic and core specific part. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: task | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4618 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 5 19:13:09 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 May 2018 19:13:09 -0000 Subject: [GHC] #15124: Improve block layout for the NCG Message-ID: <047.b2a760b384d29a2bc137285a934c2d79@haskell.org> #15124: Improve block layout for the NCG -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 (NCG) | Keywords: CodeGen | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The current codegen tries to place two blocks A and B next to each other if they are "close". = Drawbacks of the current algorithm Blocks are only considered close if one jumps to the other via a unconditional jump instructions. This is a fast and reasonable approximation. But we might be able to do better. == Calls are not considered even if they always return to the same block. For example it's clear that if foo == bar we jump to C here: {{{ A: movq $block_C_info,-16(%rbp) cmp foo,bar jne D B: jmp *(%rbx) #Returns to C ... .align 8 .infotable block_C_info: C: doThings }}} == Conditional jumps are never considered. The following block either jumps directly to c3mQ or returns there from a call. Yet that is completely ignored by the current algorithm. {{{ _c3mG: movq $block_c3mQ_info,-8(%rbp) ... jne _c3mQ jmp *(%rbx) #returns to c3mQ }}} == Likelyhood of branches is not considered. We track information about branches which are rarely taken at the cmm level. However this information is currently lost during the Cmm -> Asm transformation which happens before we do code layout. This means for Cmm code where one branch is never executed the branch that's never executed might be the only one considered relevant. This happens for example for this stack check: {{{ if ((Sp + -40) >= SpLim) (likely: True) goto c5PS; else goto c5Q3; }}} = Potential gains If nothing else this would allow some Cmm optimizations which are made useless by the current code layout algorithm. I have hit cases where the block layout algorithm turned optimizations into pessimizations of 2-5% by pulling obvious loops apart. Given that the scenario that leads to loops being pulled apart doesn't seem that unlikely I assume some loops are also pulled apart like this in HEAD. Cleaning this up ideally would also make it possible to move blocks which are not part of loops out of them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 5 19:52:29 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 May 2018 19:52:29 -0000 Subject: [GHC] #15123: mg_arg_tys in MatchGroup should be a PostTc field In-Reply-To: <049.b73ba786288414e65d50b5c03357a2a6@haskell.org> References: <049.b73ba786288414e65d50b5c03357a2a6@haskell.org> Message-ID: <064.dd349391302297333041e1f8eedf0dbb@haskell.org> #15123: mg_arg_tys in MatchGroup should be a PostTc field -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => fixed Comment: This was done in c3823cba2147c74b2c727b5458b9e95350496988. The definition of `MatchGroup` is [http://git.haskell.org/ghc.git/blob/cb1ee7e10e50b11b4a24e56b425e8f3485d298d5:/compiler/hsSyn/HsExpr.hs#l1577 now]: {{{#!hs data MatchGroup p body = MG { mg_ext :: XMG p body , mg_alts :: Located [LMatch p body] , mg_origin :: Origin } | XMatchGroup (XXMatchGroup p body) data MatchGroupTc = MatchGroupTc { mg_arg_tys :: [Type] , mg_res_ty :: Type } deriving Data type instance XMG GhcPs b = NoExt type instance XMG GhcRn b = NoExt type instance XMG GhcTc b = MatchGroupTc }}} In particular, the extension point is no longer awkwardly nested underneath the `[]` type constructor. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 5 23:29:31 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 May 2018 23:29:31 -0000 Subject: [GHC] #11764: ghc internal error building llvm-general-3.5.1.2 In-Reply-To: <049.1e7850c7fbe53a08db3314e9a97a33fc@haskell.org> References: <049.1e7850c7fbe53a08db3314e9a97a33fc@haskell.org> Message-ID: <064.66967136418b0f47d920a1541ba5d4a8@haskell.org> #11764: ghc internal error building llvm-general-3.5.1.2 -------------------------------------+------------------------------------- Reporter: andrew.wja | Owner: dfeuer Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: cabal install | llvm-general Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: (none) => dfeuer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 6 00:32:27 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 May 2018 00:32:27 -0000 Subject: [GHC] #14927: Hyperbolic area sine is unstable for (even moderately) big negative arguments. In-Reply-To: <054.a86ea93f3c5474927cb76817167bc36f@haskell.org> References: <054.a86ea93f3c5474927cb76817167bc36f@haskell.org> Message-ID: <069.775388d91a3d1ef1a7b5ec371e0a537a@haskell.org> #14927: Hyperbolic area sine is unstable for (even moderately) big negative arguments. -------------------------------------+------------------------------------- Reporter: leftaroundabout | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 8.2.1 Resolution: | Keywords: Floating | IEEE754 trigonometric Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4672, Wiki Page: | Phab:D4671, Phab:D4670 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D4672, Phab:D4671, Phab:D4670 Comment: Thanks leftaroundabout! I've pushed the patches on this branch to Phab:D4672, Phab:D4671, and Phab:D4670. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 6 01:46:10 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 May 2018 01:46:10 -0000 Subject: [GHC] #14927: Hyperbolic area sine is unstable for (even moderately) big negative arguments. In-Reply-To: <054.a86ea93f3c5474927cb76817167bc36f@haskell.org> References: <054.a86ea93f3c5474927cb76817167bc36f@haskell.org> Message-ID: <069.c1a667cacc569e6a8dd8e65a700e6f47@haskell.org> #14927: Hyperbolic area sine is unstable for (even moderately) big negative arguments. -------------------------------------+------------------------------------- Reporter: leftaroundabout | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 8.2.1 Resolution: fixed | Keywords: Floating | IEEE754 trigonometric Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4672, Wiki Page: | Phab:D4671, Phab:D4670 -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Pushed as 3ea33411d7cbf32c20940cc72ca07df6830eeed7. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 6 01:48:51 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 May 2018 01:48:51 -0000 Subject: [GHC] #14927: Hyperbolic area sine is unstable for (even moderately) big negative arguments. In-Reply-To: <054.a86ea93f3c5474927cb76817167bc36f@haskell.org> References: <054.a86ea93f3c5474927cb76817167bc36f@haskell.org> Message-ID: <069.afb7c3b9f2ecbf7eecf90e2a2860f5c7@haskell.org> #14927: Hyperbolic area sine is unstable for (even moderately) big negative arguments. -------------------------------------+------------------------------------- Reporter: leftaroundabout | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 8.2.1 Resolution: fixed | Keywords: Floating | IEEE754 trigonometric Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4672, Wiki Page: | Phab:D4671, Phab:D4670 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"46548ed1ee3ddac665c188b65d573fbf104407ea/ghc" 46548ed1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="46548ed1ee3ddac665c188b65d573fbf104407ea" base/changelog: Note stabilization of asinh (#14927) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 6 09:57:45 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 May 2018 09:57:45 -0000 Subject: [GHC] #15125: Typeclass instance selection depends on the optimisation level Message-ID: <046.a1eae0b46fb82f39391c9ac78a55a0fc@haskell.org> #15125: Typeclass instance selection depends on the optimisation level -------------------------------------+------------------------------------- Reporter: nicuveo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- (See the attached files for a minimal case.) A file A defines a typeclass, and gives an incoherent instance for all types a, and exports a function relying on said typeclass. A file B defines some data types, makes them specific instances of that class. Which instance ends up being picked depends on the optimisation level they're compiled with. //A.hs// {{{#!hs class A a where someValue :: a -> Maybe Int instance {-# INCOHERENT #-} A a where someValue = const Nothing getInt :: A a => a -> Int getInt x = fromMaybe 0 $ someValue x }}} //B.hs// {{{#!hs data B = B Int instance A B where someValue (B x) = Just x getBInt :: Int getBInt = getInt $ B 42 }}} //Main.hs// {{{#!hs main = print getBInt }}} **Upon compiling with -O0, this prints 42; upon compiling with -O2, this print 0.** (Interestingly, if the redundant class constraint is removed from getInt, then it always prints 0.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 6 10:02:23 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 May 2018 10:02:23 -0000 Subject: [GHC] #15125: Typeclass instance selection depends on the optimisation level In-Reply-To: <046.a1eae0b46fb82f39391c9ac78a55a0fc@haskell.org> References: <046.a1eae0b46fb82f39391c9ac78a55a0fc@haskell.org> Message-ID: <061.746828a9e1f10ac3e7e874a272294313@haskell.org> #15125: Typeclass instance selection depends on the optimisation level -------------------------------------+------------------------------------- Reporter: nicuveo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nicuveo): * Attachment "poc.tar.bz2" added. A small proof of concept, with a script showing how to replicate the issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 6 10:24:52 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 May 2018 10:24:52 -0000 Subject: [GHC] #15125: Typeclass instance selection depends on the optimisation level In-Reply-To: <046.a1eae0b46fb82f39391c9ac78a55a0fc@haskell.org> References: <046.a1eae0b46fb82f39391c9ac78a55a0fc@haskell.org> Message-ID: <061.8c0a60a51b1d5a4995330ce3c1044247@haskell.org> #15125: Typeclass instance selection depends on the optimisation level -------------------------------------+------------------------------------- Reporter: nicuveo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by nicuveo: Old description: > (See the attached files for a minimal case.) > > A file A defines a typeclass, and gives an incoherent instance for all > types a, and exports a function relying on said typeclass. A file B > defines some data types, makes them specific instances of that class. > Which instance ends up being picked depends on the optimisation level > they're compiled with. > > //A.hs// > {{{#!hs > class A a where > someValue :: a -> Maybe Int > > instance {-# INCOHERENT #-} A a where > someValue = const Nothing > > getInt :: A a => a -> Int > getInt x = fromMaybe 0 $ someValue x > }}} > > //B.hs// > {{{#!hs > data B = B Int > > instance A B where > someValue (B x) = Just x > > getBInt :: Int > getBInt = getInt $ B 42 > }}} > > //Main.hs// > {{{#!hs > main = print getBInt > }}} > > **Upon compiling with -O0, this prints 42; upon compiling with -O2, this > print 0.** > > (Interestingly, if the redundant class constraint is removed from getInt, > then it always prints 0.) New description: (See the attached files for a minimal case.) A file A defines a typeclass, and gives an incoherent instance for all types a, and exports a function relying on said typeclass. A file B defines some data types, makes them specific instances of that class, and uses the function defined in A. Which instance ends up being picked for B depends on the optimisation level those files are compiled with. //A.hs// {{{#!hs class A a where someValue :: a -> Maybe Int instance {-# INCOHERENT #-} A a where someValue = const Nothing getInt :: A a => a -> Int getInt x = fromMaybe 0 $ someValue x }}} //B.hs// {{{#!hs data B = B Int instance A B where someValue (B x) = Just x getBInt :: Int getBInt = getInt $ B 42 }}} //Main.hs// {{{#!hs main = print getBInt }}} **Upon compiling with -O0, this prints 42; upon compiling with -O2, this prints 0.** (Interestingly, if the redundant class constraint is removed from getInt, then it always prints 0.) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 6 11:56:24 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 May 2018 11:56:24 -0000 Subject: [GHC] #15125: Typeclass instance selection depends on the optimisation level In-Reply-To: <046.a1eae0b46fb82f39391c9ac78a55a0fc@haskell.org> References: <046.a1eae0b46fb82f39391c9ac78a55a0fc@haskell.org> Message-ID: <061.574ae112e8da6bd8a7c6c3b2336947d1@haskell.org> #15125: Typeclass instance selection depends on the optimisation level -------------------------------------+------------------------------------- Reporter: nicuveo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nicuveo): I tested with 8.4.2: it prints 0 in both cases. This seems inconsistent with the [http://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html #extension-IncoherentInstances documented behaviour of incoherent instances]? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 6 15:32:39 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 May 2018 15:32:39 -0000 Subject: [GHC] #13896: Use response file to invoke hsc2hs In-Reply-To: <046.8d005e1593e32147d596c190fbabb716@haskell.org> References: <046.8d005e1593e32147d596c190fbabb716@haskell.org> Message-ID: <061.a7935f880d104ea3c19aa7c1a0146d1d@haskell.org> #13896: Use response file to invoke hsc2hs ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: ckoparkar Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: hsc2hs | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4612 Wiki Page: | ---------------------------------+---------------------------------------- Comment (by ckoparkar): Step 2.1: https://github.com/haskell/hsc2hs/pull/9 (I have a patch ready that removes the relevant bits from `haddock`, but I haven't been able to build the haddock `ghc-head` or `wip/ghc-head` branches with GHC-HEAD yet. I noticed that the Travis builds are failing with similar errors. I'm trying to fix that first.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 6 16:12:19 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 May 2018 16:12:19 -0000 Subject: [GHC] #11953: Export Word32#, Word64# on all architectures In-Reply-To: <046.593317f13858c2d1c5dc11a464cab3d1@haskell.org> References: <046.593317f13858c2d1c5dc11a464cab3d1@haskell.org> Message-ID: <061.a923d9fc54b7a633be89705619e5fa49@haskell.org> #11953: Export Word32#, Word64# on all architectures -------------------------------------+------------------------------------- Reporter: bgamari | Owner: michalt Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by michalt): * owner: (none) => michalt Comment: @carter I've sent out the first diff/RFC for `Int8#`/`Word8#` some time ago [1], but didn't have time to make more progress since then (travelling, etc.). I should have some more time now :) I can have a look at this issue as well (as part of [2]) [1] https://phabricator.haskell.org/D4475 [2] https://github.com/ghc-proposals/ghc-proposals/pull/74 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 6 18:30:49 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 May 2018 18:30:49 -0000 Subject: [GHC] #15126: Opportunity to compress common info table representation. Message-ID: <047.6c1989d395bea7068f3a9a80b2222326@haskell.org> #15126: Opportunity to compress common info table representation. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: CodeGen | 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've looked at a lot of GHC produced assembly recently and noticed that most info tables describing stacks have the form: {{{ .align 8 .long SDjR_srt-(block_cHmk_info)+296 .long 0 .quad 6151 .quad 4294967326 }}} I haven't managed to dig fully into the description however some observations: * I noticed that the second .long directive almost always ends up being zero. * When figuring out what is what I realized the first quad (describing the pointers) is almost never fully used. * The last entrie (closure type + ?), here `4294967326` also seems quite repetitive given the size reserved. So I looked in detail at spectral/simple: * There are 2012 info tables of this sort with all of them having a zero in the second long. * We also reserve 8 byte for the stack layout. However only a single of these tables requires more than 4 byte. The compiled module has a size of 276384 Bytes, with 16092 being redundant: * 4 bytes for 0 * 4 bytes unused stack description * times 2012 info tables. That is an overhead of 5,8% which seems like quite a lot to me. The questions where to put that information is a different one. But only looking at the data and not how it is used tagging the pointer to the SRT table seems like a possibility. The info table description `4294967326` also appeared over 1k times. Maybe it's possible to come up with a more efficient encoding there as well. I didn't give it much thought yet since I don't have the time to do anything about it in the near future. But putting it here in case anyone is interested or looks into this in the future. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 6 20:06:43 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 May 2018 20:06:43 -0000 Subject: [GHC] #15124: Improve block layout for the NCG In-Reply-To: <047.b2a760b384d29a2bc137285a934c2d79@haskell.org> References: <047.b2a760b384d29a2bc137285a934c2d79@haskell.org> Message-ID: <062.e67a6bcfaa2c6cb64883e1d5d855a49f@haskell.org> #15124: Improve block layout for the NCG -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (NCG) | Version: 8.2.2 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AndreasK): Besides the usual (Aigner Guides, Intel Optimization Manuals) here are a few more references which should make a good starting point to explore this space: [1] Thomas Ball, James R. Larus. Branch Prediction for Free (https://do i.org/10.1145/173262.155119) [2] Hans Wennborg. The recent switch lowering improvements. (http://llv m.org/devmtg/2015-10/slides/Wennborg-SwitchLowering.pdf) See also: http s://www.youtube.com/watch?v=gMqSinyL8uk [3] James E. Smith. A study of branch prediction strategies (https://dl .acm.org/citation.cfm?id=801871) [4] http://llvm.org/doxygen/MachineBlockPlacement_8cpp_source.html [5] Karl Pettis, Robert C. Hansen. Profile guided code positioning. (ht tps://doi.org/10.1145/93542.93550) [6] Hashemi et al. Efficient procedure mapping using cache line coloring (https://doi.org/10.1145/258915.258931) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 6 22:43:18 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 May 2018 22:43:18 -0000 Subject: [GHC] #15125: Typeclass instance selection depends on the optimisation level In-Reply-To: <046.a1eae0b46fb82f39391c9ac78a55a0fc@haskell.org> References: <046.a1eae0b46fb82f39391c9ac78a55a0fc@haskell.org> Message-ID: <061.5edcdd8e0032615d7691c8420367003c@haskell.org> #15125: Typeclass instance selection depends on the optimisation level -------------------------------------+------------------------------------- Reporter: nicuveo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): > This seems inconsistent with the ​documented behaviour of incoherent instances? The naming is deliberate: only use `INCOHERENT` to diagnose behaviour you don't understand; never rely on ghc consistently picking an instance. The behaviour you're seeing in 8.4.2 is following the documentation. The critical part of that doco is >> Eliminate any candidate **IX** for which ''both'' of the following hold: The second sub-bullet doesn't hold, because neither instance is marked ''overlapping''/''overlappable''. So I'd expect to always pick the more general instance, marked `INCOHERENT`. Then I agree the optimisation level shouldn't influence instance selection. I guess that in optimising for module B, ghc forces the instance selection. Never the less, just don't use `INCOHERENT`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 6 22:58:26 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 May 2018 22:58:26 -0000 Subject: [GHC] #15125: Typeclass instance selection depends on the optimisation level In-Reply-To: <046.a1eae0b46fb82f39391c9ac78a55a0fc@haskell.org> References: <046.a1eae0b46fb82f39391c9ac78a55a0fc@haskell.org> Message-ID: <061.1ffd78d2007c17b833e19f484fe7a1b1@haskell.org> #15125: Typeclass instance selection depends on the optimisation level -------------------------------------+------------------------------------- Reporter: nicuveo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nicuveo): I do agree with you on never relying on INCOHERENT! I beg to disagree on the interpretation of the documentation, however. Sure, the INCOHERENT instance does not get eliminated, but the very next bullet point reads: > //If exactly one non-incoherent candidate remains, select it. If all remaining candidates are incoherent, select an arbitrary one. Otherwise the search fails (i.e. when more than one surviving candidate is not incoherent).// Since, out of the two candidates that remain, only one is not incoherent, the compiler should only pick that one. My understanding is therefore that this code should //always// print 42? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 7 01:47:38 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 May 2018 01:47:38 -0000 Subject: [GHC] #15009: Float equalities past local equalities In-Reply-To: <047.0a49c3ac676b2b3bc6f93c4594762c08@haskell.org> References: <047.0a49c3ac676b2b3bc6f93c4594762c08@haskell.org> Message-ID: <062.120d5acaf431ddf69b9110179bcdec54@haskell.org> #15009: Float equalities past local equalities -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.3 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): So I suppose I'm precisely after `Note [Let-bound skolems]`. But it doesn't seem to be working in the cases above (I haven't yet explored why, but I will). You're right that my (%) is wrong. Of course a purely local equality (as defined above) should not affect floating, but also a let-bind-like equality should, too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 7 02:25:19 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 May 2018 02:25:19 -0000 Subject: [GHC] #15127: Unbox around runRW# Message-ID: <045.fd34327d751bad75e01da7c62c0c3479@haskell.org> #15127: Unbox around runRW# -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.8.1 Component: Compiler | Version: 8.4.2 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: -------------------------------------+------------------------------------- Because `runRW#` inlines so late, we don't end up unboxing around it. For example, suppose we write {{{#!hs f x = runST $ do mar <- newArray 100 x unsafeFreeze mar }}} This will compile to something like {{{#!hs f x = case runRW# (\s -> case newArray# 100# x s of { (# s', mar #) -> case unsafeFreezeArray# mar s' of { (# s'', ar# #) -> (# s'', Array ar# #) }}) of (# _, ar #) -> ar }}} We generally want to pull the constructor application out of the `runRW#` argument: {{{#!hs f x = case runRW# (\s -> case newArray# 100# x s of { (# s', mar #) -> unsafeFreezeArray# mar s' }) of (# _, ar# #) -> Array ar# }}} This exposes the `Array` constructor to case-of-case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 7 04:37:15 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 May 2018 04:37:15 -0000 Subject: [GHC] #15128: emitPrimOp: can't translate PrimOp Message-ID: <049.3c584bb9102092d760d7bec8a3884851@haskell.org> #15128: emitPrimOp: can't translate PrimOp -------------------------------------+------------------------------------- Reporter: tianxiaogu | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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: -------------------------------------+------------------------------------- Affected HEAD (GHC version 8.5.20180506) Reproduce: {{{ ghc -O bug.hs }}} Log: {{{ [1 of 1] Compiling Main ( bug.hs, bug.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.5.20180506 for x86_64-unknown-linux): emitPrimOp: can't translate PrimOp byteArrayContents# Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1162:37 in ghc:Outputable pprPanic, called at compiler/codeGen/StgCmmPrim.hs:943:12 in ghc:StgCmmPrim Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 7 04:37:28 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 May 2018 04:37:28 -0000 Subject: [GHC] #15128: emitPrimOp: can't translate PrimOp In-Reply-To: <049.3c584bb9102092d760d7bec8a3884851@haskell.org> References: <049.3c584bb9102092d760d7bec8a3884851@haskell.org> Message-ID: <064.15aeda1c7afee26f74097da842e42a6a@haskell.org> #15128: emitPrimOp: can't translate PrimOp -------------------------------------+------------------------------------- Reporter: tianxiaogu | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by tianxiaogu): * Attachment "bug.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 7 05:50:47 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 May 2018 05:50:47 -0000 Subject: [GHC] #15009: Float equalities past local equalities In-Reply-To: <047.0a49c3ac676b2b3bc6f93c4594762c08@haskell.org> References: <047.0a49c3ac676b2b3bc6f93c4594762c08@haskell.org> Message-ID: <062.9e337aa3fcb3929ba128efa6d28714b7@haskell.org> #15009: Float equalities past local equalities -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.3 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nfrisby): * cc: nfrisby (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 7 06:38:24 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 May 2018 06:38:24 -0000 Subject: [GHC] #7411: Exceptions are optimized away in certain situations In-Reply-To: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> References: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> Message-ID: <065.58893d2854315f34271208cfd15d3839@haskell.org> #7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Compiling on GHC HEAD reproduces the problem: `../ghc/HEAD/_build/stage1/bin/ghc example.hs -fforce-recomp -O` produces a program that runs without error, while `../ghc/HEAD/_build/stage1/bin/ghc example.hs -fforce-recomp` behaves as it should. Comparing simplified Core shows that with `-O`, `deepseq` no longer appears in the output, so it seems that inlining `deepseq` is part of the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 7 07:16:24 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 May 2018 07:16:24 -0000 Subject: [GHC] #7411: Exceptions are optimized away in certain situations In-Reply-To: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> References: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> Message-ID: <065.6dee2fdcbb5162711bd5d1b2fd3306da@haskell.org> #7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): The relevant Core for the unoptimized run: {{{ main = evaluate (deepseq ($fNFData[] $fNFDataChar) (: (C# 'a'#) (undefined ((pushCallStack (unpackCString# "undefined"#, SrcLoc (unpackCString# "main"#) (unpackCString# "Main"#) (unpackCString# "example.hs"#) (I# 4#) (I# 25#) (I# 4#) (I# 34#)) emptyCallStack) `cast` ))) (return $fMonadIO ())) }}} As expected, `deepseq` is retained. However, in the optimized version, we get this: {{{ Rec { main_go main_go = \ ds_a2Nc -> case ds_a2Nc of { [] -> (); : x_a2Ng xs_a2Nh -> case x_a2Ng of { C# ipv_s2Np -> main_go xs_a2Nh } } end Rec } main2 main2 = undefined (lvl10_r4dT `cast` ) lvl11_r4dU lvl11_r4dU = C# 'a'# lvl12_r4dV lvl12_r4dV = : lvl11_r4dU main2 lvl13_r4dW lvl13_r4dW = \ eta_B1 -> case main_go lvl12_r4dV of { () -> (# eta_B1, () #) } main1 main1 = \ s_a2Nw -> (# s_a2Nw, lvl13_r4dW `cast` #) }}} (boilerplate stripped for clarity) Which, IIUC, does not respect the spirit of `deepseq` - specifically, the list construction in `lvl12_r4dV` isn't strict, so the `undefined` that `main2` produces isn't being forced. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 7 07:17:39 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 May 2018 07:17:39 -0000 Subject: [GHC] #15128: emitPrimOp: can't translate PrimOp In-Reply-To: <049.3c584bb9102092d760d7bec8a3884851@haskell.org> References: <049.3c584bb9102092d760d7bec8a3884851@haskell.org> Message-ID: <064.a6613db9e8b82ff87df433b51eaf062a@haskell.org> #15128: emitPrimOp: can't translate PrimOp -------------------------------------+------------------------------------- Reporter: tianxiaogu | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Smaller reproducer: {{{#!haskell {-# LANGUAGE MagicHash #-} {-# LANGUAGE UnboxedTuples #-} module Lib where import GHC.Exts (Int (..), MutableByteArray#, byteArrayContents#, newPinnedByteArray#, unsafeCoerce#) import GHC.Ptr (Ptr (..)) import GHC.ST (ST (..)) data MByteArray s = MByteArray { unMBA :: MutableByteArray# s } newPinnedByteArray :: Int -> ST s (Ptr a, MByteArray s) newPinnedByteArray (I# n#) = ST $ \s# -> case newPinnedByteArray# n# s# of (# s2#, marr# #) -> (# s2#, ( Ptr (byteArrayContents# (unsafeCoerce# s#)), MByteArray marr# ) #) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 7 07:37:08 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 May 2018 07:37:08 -0000 Subject: [GHC] #7411: Exceptions are optimized away in certain situations In-Reply-To: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> References: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> Message-ID: <065.6e0fa1d8ea35c9cb514aadea45f3855d@haskell.org> #7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by tdammers): * owner: (none) => tdammers -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 7 10:51:02 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 May 2018 10:51:02 -0000 Subject: [GHC] #15124: Improve block layout for the NCG In-Reply-To: <047.b2a760b384d29a2bc137285a934c2d79@haskell.org> References: <047.b2a760b384d29a2bc137285a934c2d79@haskell.org> Message-ID: <062.fb5cba7d30b5abf556f10164eefbb8fd@haskell.org> #15124: Improve block layout for the NCG -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (NCG) | Version: 8.2.2 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8082 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jstolarek): * related: => #8082 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 7 10:51:53 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 May 2018 10:51:53 -0000 Subject: [GHC] #11080: Open data kinds In-Reply-To: <047.64e06093644ddd3cb76b94e28bef420a@haskell.org> References: <047.64e06093644ddd3cb76b94e28bef420a@haskell.org> Message-ID: <062.f40dc2f2039f3914d7bb26e482a28af5@haskell.org> #11080: Open data kinds -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #6024 | Differential Rev(s): Phab:D1778 Wiki Page: | GhcKinds/KindsWithoutData | -------------------------------------+------------------------------------- Changes (by jstolarek): * owner: jstolarek => (none) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 7 10:52:03 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 May 2018 10:52:03 -0000 Subject: [GHC] #10832: Generalize injective type families In-Reply-To: <048.1487f224b00112fe37d31a1812a748a4@haskell.org> References: <048.1487f224b00112fe37d31a1812a748a4@haskell.org> Message-ID: <063.3be7e200144388a812eb2f196d1b4773@haskell.org> #10832: Generalize injective type families -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: TypeFamilies, Resolution: | InjectiveFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #6018 | Differential Rev(s): Phab:D1287 Wiki Page: | -------------------------------------+------------------------------------- Changes (by jstolarek): * owner: jstolarek => (none) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 7 11:33:34 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 May 2018 11:33:34 -0000 Subject: [GHC] #7411: Exceptions are optimized away in certain situations In-Reply-To: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> References: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> Message-ID: <065.84dde52d5a32af6cb79d8722049350a9@haskell.org> #7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Interestingly, the patch from #5129 does *not* fix this one too, so it's not just due to incorrectly optimizing `seq` away; there is more happening here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 7 11:35:28 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 May 2018 11:35:28 -0000 Subject: [GHC] #10346: Cross-module SpecConstr In-Reply-To: <046.b576f13f2450fed85380ce289fdfae5b@haskell.org> References: <046.b576f13f2450fed85380ce289fdfae5b@haskell.org> Message-ID: <061.4aab006868d4b44284305c059d8770d9@haskell.org> #10346: Cross-module SpecConstr -------------------------------------+------------------------------------- Reporter: simonpj | Owner: ckoparkar Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: SpecConstr, | newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13016 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ckoparkar): * owner: (none) => ckoparkar Comment: I'd like to work on this. The updated example is what helped me understand what the expected Core output should be. Thanks for that! (I'm relatively new to GHC hacking.) So far, I've read the `SpecConstr` paper, and am reading the source code now. My hunch is that we need to change the `Propagation` phase somehow to include the proper rewrite rules across modules. Is this correct ? Other than that, I don't have any specific questions at the moment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 7 12:49:20 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 May 2018 12:49:20 -0000 Subject: [GHC] #10346: Cross-module SpecConstr In-Reply-To: <046.b576f13f2450fed85380ce289fdfae5b@haskell.org> References: <046.b576f13f2450fed85380ce289fdfae5b@haskell.org> Message-ID: <061.2f8183bcc2479ed99ade327fb95f80c0@haskell.org> #10346: Cross-module SpecConstr -------------------------------------+------------------------------------- Reporter: simonpj | Owner: ckoparkar Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: SpecConstr, | newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13016 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Are you starting from my patch https://phabricator.haskell.org/D3566 ? I understand how this is meant to work better now so can help you if you have any questions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 7 13:39:46 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 May 2018 13:39:46 -0000 Subject: [GHC] #7411: Exceptions are optimized away in certain situations In-Reply-To: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> References: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> Message-ID: <065.1078955ad0abe903b7879b010e708283@haskell.org> #7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Another data point: this only happens with lists, not with tuples - e.g., the following works as expected: {{{ import Control.Exception import Control.DeepSeq main = evaluate (('a', undefined :: [Char]) `deepseq` return () :: IO ()) }}} Which is baffling in that the `NFData` instances for tuples and lists are strikingly similar and *should* do the same thing. It gets even more baffling when I implement a custom (but isomorphic) drop-in replacement for `[]`, like so: {{{ import Control.Exception import Control.DeepSeq data List a = Nil | Cons a (List a) instance NFData a => NFData (List a) where rnf v = case v of Nil -> () (Cons x (Cons y xs)) -> rnf x `seq` rnf y `seq` rnf xs main = evaluate ((Cons 'a' $ Cons undefined $ Nil) `deepseq` return () :: IO ()) }}} This example reproduces the problem; however, changing the instance like this behaves: {{{ instance NFData a => NFData (List a) where rnf v = case v of Nil -> () (Cons x (Cons y xs)) -> rnf x `seq` rnf y }}} In other words, if the `NFData` instance says *not* to look beyond the second list element, then the failure occurs, but if does look beyond, then it gets optimized away. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 7 14:01:50 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 May 2018 14:01:50 -0000 Subject: [GHC] #10346: Cross-module SpecConstr In-Reply-To: <046.b576f13f2450fed85380ce289fdfae5b@haskell.org> References: <046.b576f13f2450fed85380ce289fdfae5b@haskell.org> Message-ID: <061.9d66520fb4173ae6c2bc538ce46654a2@haskell.org> #10346: Cross-module SpecConstr -------------------------------------+------------------------------------- Reporter: simonpj | Owner: ckoparkar Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: SpecConstr, | newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13016 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ckoparkar): I did use that patch. However, I couldn't get it to do what we want. Not sure if I did something wrong. I'm using the example given in the description: {{{ module M where {-# INLINABLE foo #-} foo True y = y foo False (a,b) = foo True (a+b,b) baz = foo False (1,2) ----------------------------------- module X where import M bar = foo False (3,4) }}} and compiling it with `ghc-stage2 -fforce-recomp -ddump-spec -ddump-rules -O X.hs`. Relevant Core output: {{{ baz :: (Integer, Integer) [LclIdX, Unf=Unf{Src=, TopLvl=True, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 240 0}] baz = foo_aZc GHC.Types.False (1, 2) }}} where `foo_aZc` is the specialized version of `foo`. On the other hand, `bar` still uses the regular `foo`. {{{ bar :: (Integer, Integer) [LclIdX, Unf=Unf{Src=, TopLvl=True, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 250 0}] bar = foo @ Integer GHC.Num.$fNumInteger GHC.Types.False (3, 4) }}} I'm going to use that patch as a starting point though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 7 14:03:42 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 May 2018 14:03:42 -0000 Subject: [GHC] #10346: Cross-module SpecConstr In-Reply-To: <046.b576f13f2450fed85380ce289fdfae5b@haskell.org> References: <046.b576f13f2450fed85380ce289fdfae5b@haskell.org> Message-ID: <061.329f460aa4ad2f960c7dd2a63f32ac09@haskell.org> #10346: Cross-module SpecConstr -------------------------------------+------------------------------------- Reporter: simonpj | Owner: ckoparkar Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: SpecConstr, | newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13016 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ckoparkar): > I understand how this is meant to work better now so can help you if you have any questions. Thanks! I'll keep posting any updates or questions as I make some progress on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 7 14:45:01 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 May 2018 14:45:01 -0000 Subject: [GHC] #7411: Exceptions are optimized away in certain situations In-Reply-To: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> References: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> Message-ID: <065.439f7b613fa10ac0caba802de6ce39c6@haskell.org> #7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): OK, boiled it down to a simpler test case that doesn't even involve `deepseq`: {{{ import Control.Exception dslist :: [a] -> b -> b dslist xs b = go xs `seq` b where go [] = () go (x:xs) = x `seq` go xs -- the following variation also reproduces the problem: -- go (x:xs) = go (x `seq` xs) main = evaluate (('a':undefined) `dslist` return () :: IO ()) }}} This is essentially what `deepseq` does on lists, with all the typeclass instances and type variables manually unrolled. Note that in order to trigger the bug, we actually do need the `go` function; if instead we pass the `b` around and recurse directly, the problem goes away, like so: {{{ import Control.Exception dslist :: [a] -> b -> b dslist xs b = go xs `seq` b where dslist [] a = a dslist (x:xs) a = x `seq` dslist xs a main = evaluate (('a':undefined) `dslist` return () :: IO ()) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 7 15:37:57 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 May 2018 15:37:57 -0000 Subject: [GHC] #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) In-Reply-To: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> References: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> Message-ID: <057.3f5e982d4aea4b550be53ad4270b7083@haskell.org> #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 (CodeGen) | Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: T13658 at runtime | T14779a T14779b T14868 debug | parsing001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4654 Wiki Page: | -------------------------------------+------------------------------------- Comment (by recursion-ninja): This defect has completely broken my build on Ubuntu 18.04. I'm sure I'm not the only one experiencing this, and as the new OS version gets more adoption the problem will propagate as bgamari mentioned. Can we prioritize a GHC-8.4.3 release? I really can't wait months for GHC-8.6 to resolve this defect. I'm guessing there are others can't wait that long either. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 7 17:00:36 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 May 2018 17:00:36 -0000 Subject: [GHC] #10346: Cross-module SpecConstr In-Reply-To: <046.b576f13f2450fed85380ce289fdfae5b@haskell.org> References: <046.b576f13f2450fed85380ce289fdfae5b@haskell.org> Message-ID: <061.8bc4a6c38be7327f0bede4aca4b9f620@haskell.org> #10346: Cross-module SpecConstr -------------------------------------+------------------------------------- Reporter: simonpj | Owner: ckoparkar Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: SpecConstr, | newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13016 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I never claimed that it worked but that it was at least somewhere to start! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 7 18:21:42 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 May 2018 18:21:42 -0000 Subject: [GHC] #1600: Optimisation: CPR the results of IO In-Reply-To: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> References: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> Message-ID: <062.39b7b0dd05568f1f8c3196ab8892e502@haskell.org> #1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8598 | Differential Rev(s): Phab:D4244 Wiki Page: | -------------------------------------+------------------------------------- Changes (by michalt): * cc: michalt (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 7 23:09:43 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 May 2018 23:09:43 -0000 Subject: [GHC] #15129: Expose ghc-pkg internals as a library Message-ID: <048.44dad1aa8857500b8ed822ef3502d9dd@haskell.org> #15129: Expose ghc-pkg internals as a library -------------------------------------+------------------------------------- Reporter: ryanreich | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Core | Version: 8.2.2 Libraries | 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: -------------------------------------+------------------------------------- The module [https://downloads.haskell.org/~ghc/latest/docs/html/libraries /ghc-boot-8.4.1/GHC-PackageDb.html GHC.PackageDb], which is in the `ghc- boot` package and therefore shipped alongside `base`, and which exposes the crucial data type `InstalledPackageInfo a b c d e f g` and functions `readPackageDbForGhc`, `readPackageDbForGhcPkg`, and `writePackageDb`, is nonetheless crippled outside of GHC: - The first function requires instances of the `BinaryStringRep` and `DbUnitIdModuleRep` classes, which do not have any in any public package - The second one uses a polymorphic parameter that, in order to run without error, actually needs to be [https://downloads.haskell.org/~ghc/latest/docs/html/libraries/Cabal-2.2.0.0 /Distribution-InstalledPackageInfo.html Distribution.InstalledPackageInfo], defined in the completely different `Cabal` package neither mentioning nor mentioned by `ghc-boot` - The third one takes two arguments of which the first (a list of `InstalledPackageInfo a b c d e f g`) is redundant because it can be constructed from the second, but no conversion function is defined. While it is possible to write both the instances and conversion function by hand, it is extremely awkward and I worry that it is also fragile, given the internal nature of this entire module. The full functionality of this package is only available within the [https://github.com/ghc/ghc/blob/master/utils/ghc-pkg/Main.hs Main] module of `ghc-pkg`, which is highly monolithic despite containing such [https://github.com/ghc/ghc/blob/master/utils/ghc-pkg/Main.hs#L1226-L1307 generally useful code] as the above instances and conversion function. Since `GHC.PackageDb` provides so much of `ghc-pkg`'s essential functionality as a library, it seems reasonable to request that this code be brought out of the opaque `Main` module and into a public library. I understand from the comments that `ghc-boot` is not the place for this, but perhaps one of the following is: a. `Cabal`, because it already has the `InstalledPackageInfo` (no parameters) type used by `ghc-pkg`; however, `Cabal` seems committed to calling `ghc-pkg` as an executable, not providing linkage to its internals. b. a separate `ghc-pkg` library containing, possibly, a more carefully chosen selection of that executable's code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 8 08:18:54 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 May 2018 08:18:54 -0000 Subject: [GHC] #15126: Opportunity to compress common info table representation. In-Reply-To: <047.6c1989d395bea7068f3a9a80b2222326@haskell.org> References: <047.6c1989d395bea7068f3a9a80b2222326@haskell.org> Message-ID: <062.024eda4a812ba93c15d2fbc60b98e470@haskell.org> #15126: Opportunity to compress common info table representation. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Compressing info tables looks like a good plan. But be careful about imposing a slow-down in the fast path, if extra instructions are need to decode the info table. With a bit of luck, we could have zero overhead for the fast path. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 8 08:40:38 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 May 2018 08:40:38 -0000 Subject: [GHC] #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) In-Reply-To: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> References: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> Message-ID: <057.ed8b28d96224d41d03537aed14551171@haskell.org> #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 (CodeGen) | Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: T13658 at runtime | T14779a T14779b T14868 debug | parsing001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4654 Wiki Page: | -------------------------------------+------------------------------------- Comment (by 4e6): I would also like to see this fix in GHC-8.4. Just bumped into this issue on Arch Linux (probably after upgrading to gcc-8.1.0) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 8 09:36:08 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 May 2018 09:36:08 -0000 Subject: [GHC] #13958: Ghc linking failure for 8.2.1 rc3 on Alpine Linux In-Reply-To: <046.191e3f9d3befb75a63fa258bf0a5943b@haskell.org> References: <046.191e3f9d3befb75a63fa258bf0a5943b@haskell.org> Message-ID: <061.a03f3cc2c2babb298d2bd44c23aa14c7@haskell.org> #13958: Ghc linking failure for 8.2.1 rc3 on Alpine Linux -------------------------------------+------------------------------------- Reporter: mitchty | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc3 (Linking) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by domenkozar): This one is easy to reproduce using Nix: {{{ git clone https://github.com/NixOS/nixpkgs.git cd nixpkgs git checkout e71c44160ba7d2b73c668a53f5600dbc1901cbc2 nix-build -A ghc --arg localSystem '{config="x86_64-unknown-linux-musl";}' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 8 10:36:21 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 May 2018 10:36:21 -0000 Subject: [GHC] #11066: Inacessible branch should be warning - otherwise breaks type soundness? In-Reply-To: <047.0785946e31f05741dc32414264d84d16@haskell.org> References: <047.0785946e31f05741dc32414264d84d16@haskell.org> Message-ID: <062.121e292c2f445ab6954378b78bb3ea47@haskell.org> #11066: Inacessible branch should be warning - otherwise breaks type soundness? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #8128, #8740 | Differential Rev(s): Phab:D1454 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): I've been looking at this for a little while, and AFAICT, we have two actionable points at hand here: 1. "Inaccessible code" is currently an error, but it would be more reasonable to make it a warning. 2. Programs exist that the type checker currently rejects, even though we would like them to be accepted. It seems that there is no consensus on the exact conditions for this though. I believe that #1 is easy to solve, and would produce immediate benefit, while #2 needs better understanding of the actual problem. So I would suggest we tackle #1 now, and continue the discussion on #2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 8 11:45:53 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 May 2018 11:45:53 -0000 Subject: [GHC] #13104: runRW# ruins join points In-Reply-To: <049.de62ded7b05ef8af28dbfe5dd7c43ff2@haskell.org> References: <049.de62ded7b05ef8af28dbfe5dd7c43ff2@haskell.org> Message-ID: <064.4056ac7c803913ccb3e8a3f08f766019@haskell.org> #13104: runRW# ruins join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints 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: | -------------------------------------+------------------------------------- Comment (by simonpj): See Trac #15127. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 8 12:04:57 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 May 2018 12:04:57 -0000 Subject: [GHC] #11786: Need -fno-print-explicit-runtime-reps to work on IfaceType, else RuntimeRep leaks In-Reply-To: <046.943657e3f9ed3d83fd8aca1ffc9a9fa0@haskell.org> References: <046.943657e3f9ed3d83fd8aca1ffc9a9fa0@haskell.org> Message-ID: <061.5efcd26b1db6a3f6bfbd2d9f01e614af@haskell.org> #11786: Need -fno-print-explicit-runtime-reps to work on IfaceType, else RuntimeRep leaks -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sighingnow): This bug still exists in ghc-HEAD. With or without `:set -fprint-explicit-runtime-reps`, we both have {{{#!hs Prelude> :t ($) ($) :: (a -> b) -> a -> b Prelude> :i ($) ($) :: forall (r :: GHC.Types.RuntimeRep) a (b :: TYPE r). (a -> b) -> a -> b -- Defined in ‘GHC.Base’ infixr 0 $ }}} This behavior is inconsistent with the description in user guide: https://downloads.haskell.org/~ghc/master/users-guide/using.html#ghc-flag --fprint-explicit-runtime-reps -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 8 14:45:39 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 May 2018 14:45:39 -0000 Subject: [GHC] #14152: Float exit paths out of recursive functions In-Reply-To: <046.dc062d85b02b871348583b82e3b8d72a@haskell.org> References: <046.dc062d85b02b871348583b82e3b8d72a@haskell.org> Message-ID: <061.80c301bb8e532cc1f6f42bf6ea0abeaf@haskell.org> #14152: Float exit paths out of recursive functions -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14137 #10918 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"61b245a0c8abd365dcaa69b3190cf950603a1960/ghc" 61b245a0/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="61b245a0c8abd365dcaa69b3190cf950603a1960" Small refactoring in Exitify This refactoring was provoked by our conversation on Trac #14152. No change in behaviour. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 8 14:45:39 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 May 2018 14:45:39 -0000 Subject: [GHC] #15116: GHC internal error when GADT return type mentions its own constructor name In-Reply-To: <050.dc668ea98cda5bfcd872cc4585004dde@haskell.org> References: <050.dc668ea98cda5bfcd872cc4585004dde@haskell.org> Message-ID: <065.94c5b9f4d9ad77e8e8c96b01cf262df8@haskell.org> #15116: GHC internal error when GADT return type mentions its own constructor name -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: GADTs, Resolution: | TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"aa03ad885373f82c008ae7d75206f5305c395b61/ghc" aa03ad88/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="aa03ad885373f82c008ae7d75206f5305c395b61" Simplify the kind checking for type/class decls This patch deletes quite a bit of code, AND fixes Trac #15116. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 8 14:51:09 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 May 2018 14:51:09 -0000 Subject: [GHC] #14547: Wrong warning by -Wincomplete-patterns In-Reply-To: <052.21a9ad8704f084ec9db31f385a693f01@haskell.org> References: <052.21a9ad8704f084ec9db31f385a693f01@haskell.org> Message-ID: <067.73e2e071f1fbfd45e5d760c6e0d92772@haskell.org> #14547: Wrong warning by -Wincomplete-patterns -------------------------------------+------------------------------------- Reporter: YoshikuniJujo | Owner: (none) Type: bug | Status: closed Priority: low | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: incomplete- | patterns OverloadedLists, | PatternMatchWarnings TypeFamilies Operating System: Linux | Architecture: x86 Type of failure: Incorrect | Test Case: error/warning at compile-time | deSugar/should_compile/T14547 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4624 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"280de0c19682fb1b0941cad94f9219b513a6d3e2/ghc" 280de0c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="280de0c19682fb1b0941cad94f9219b513a6d3e2" Revert "Normalize the element type of ListPat, fix #14547" This reverts commit 361d23a8ebb44f5df5167306d7b98d8bd1724e06. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 8 14:51:24 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 May 2018 14:51:24 -0000 Subject: [GHC] #14547: Wrong warning by -Wincomplete-patterns In-Reply-To: <052.21a9ad8704f084ec9db31f385a693f01@haskell.org> References: <052.21a9ad8704f084ec9db31f385a693f01@haskell.org> Message-ID: <067.de11037932e85a3ca053fb68c2329a60@haskell.org> #14547: Wrong warning by -Wincomplete-patterns -------------------------------------+------------------------------------- Reporter: YoshikuniJujo | Owner: (none) Type: bug | Status: closed Priority: low | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: incomplete- | patterns OverloadedLists, | PatternMatchWarnings TypeFamilies Operating System: Linux | Architecture: x86 Type of failure: Incorrect | Test Case: error/warning at compile-time | deSugar/should_compile/T14547 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4624 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"981bf4718de7daef7817a363ccc14030c2688632/ghc" 981bf47/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="981bf4718de7daef7817a363ccc14030c2688632" Normalize the element type of ListPat, fix #14547 The element type of `List` maybe a type family instacen, rather than a trivial type. For example in Trac #14547, ``` {-# LANGUAGE TypeFamilies, OverloadedLists #-} class Foo f where type It f foo :: [It f] -> f data List a = Empty | a :! List a deriving Show instance Foo (List a) where type It (List a) = a foo [] = Empty foo (x : xs) = x :! foo xs ``` Here the element type of `[]` is `It (List a)`, we should also normalize it as `a`. Test Plan: make test TEST="T14547" Reviewers: bgamari Reviewed By: bgamari Subscribers: thomie, carter GHC Trac Issues: #14547 Differential Revision: https://phabricator.haskell.org/D4624 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 8 14:55:42 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 May 2018 14:55:42 -0000 Subject: [GHC] #13104: runRW# ruins join points In-Reply-To: <049.de62ded7b05ef8af28dbfe5dd7c43ff2@haskell.org> References: <049.de62ded7b05ef8af28dbfe5dd7c43ff2@haskell.org> Message-ID: <064.626643c2cae7c54830f0a63fcfe9ecab@haskell.org> #13104: runRW# ruins join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints 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: | -------------------------------------+------------------------------------- Comment (by simonpj): Thinking about #13104 and #15127, I am gradually being driven to the conclusion that we should treat `runRW#` specially in the simplifier. And perhaps a few other primops (like `maskAsyncExceptions#` too). I just can't see a better way to deal with it. Here's my brain-dump: * Require that the argument of `runRW#` is always eta-expanded, with a one-shot lambda. Similar to the RHS of a join point. This would be an invariant of Core, and checked by Core Lint. * Make `Simplify` push the continuation into the body of the `runRW`, just as it does with join points. So, for example: {{{ case (runRW# (\s.e)) of blah ==> runRW# (\s. case e of blah) }}} * I think that `FloatIn` will do the right thing automatically, provided the lambda is marked one-shot. * Maybe, instead of doing mysterious inlining things in `CorePrep` (as we do now), we could just make the code generator do the Right Thing directly? Just as join bindings look like let-bindings, and in most ways behave like them, but have additional invariants that are checked by Core Lint, so similarly with `runRW# (\s.e)`. I have not yet thought through which other primops should particpate in this party. Certainly the `maskAsyncExceptions#` and unmask families. Probably not `catch#` becuase we have to be so careful about moving code into our out of the scope of an exception handler. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 8 14:56:03 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 May 2018 14:56:03 -0000 Subject: [GHC] #15130: Hadrian doesn't rebuild changed `CoreUtils.hs` Message-ID: <047.f868c2b92f1e49a78a6523a178230534@haskell.org> #15130: Hadrian doesn't rebuild changed `CoreUtils.hs` --------------------------------------+--------------------------- Reporter: tdammers | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Build System | Version: 8.4.2 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------- When compiling stage2 with Hadrian, freezing stage1 causes changes to `CoreUtils.hs` to be ignored, and `CoreUtils.hs` not being recompiled. The following steps should reproduce the problem: 1. Make a debug build with Hadrian: `./hadrian/build.sh --flavour=Devel2` 2. Rebuild with freeze1: `./hadrian/build.sh --flavour=Devel2 --freeze1` 3. Edit `compiler/coreSyn/CoreUtils.hs`, adding some change that is easily detected in the output 4. Rebuild with freeze1: `./hadrian/build.sh --flavour=Devel2 --freeze1` 5. Observe how `CoreUtils` does not appear in the list of modules Hadrian is compiling, and how changes to that file do not end up in the stage2 compiler. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 8 14:57:17 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 May 2018 14:57:17 -0000 Subject: [GHC] #15116: GHC internal error when GADT return type mentions its own constructor name In-Reply-To: <050.dc668ea98cda5bfcd872cc4585004dde@haskell.org> References: <050.dc668ea98cda5bfcd872cc4585004dde@haskell.org> Message-ID: <065.aaeb90832aa3c187aee2da4656689c12@haskell.org> #15116: GHC internal error when GADT return type mentions its own constructor name -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: GADTs, Resolution: fixed | TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | polykinds/T15116, T15116a Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => polykinds/T15116, T15116a * resolution: => fixed Comment: Excellent bug report, and provocation to improve. Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 8 14:59:46 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 May 2018 14:59:46 -0000 Subject: [GHC] #11066: Inacessible branch should be warning - otherwise breaks type soundness? In-Reply-To: <047.0785946e31f05741dc32414264d84d16@haskell.org> References: <047.0785946e31f05741dc32414264d84d16@haskell.org> Message-ID: <062.ea2cffccb97b5b6d229da0e413956e09@haskell.org> #11066: Inacessible branch should be warning - otherwise breaks type soundness? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #8128, #8740 | Differential Rev(s): Phab:D1454 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > So I would suggest we tackle #1 now, and continue the discussion on #2# Makes sense to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 8 15:01:37 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 May 2018 15:01:37 -0000 Subject: [GHC] #15128: emitPrimOp: can't translate PrimOp In-Reply-To: <049.3c584bb9102092d760d7bec8a3884851@haskell.org> References: <049.3c584bb9102092d760d7bec8a3884851@haskell.org> Message-ID: <064.09e1b9231407e0c8f31ce8960c7a02fd@haskell.org> #15128: emitPrimOp: can't translate PrimOp -------------------------------------+------------------------------------- Reporter: tianxiaogu | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > You're trying to coerce a state token to ByteArray#. Which is certainly a bad thing to do. I wonder if we can produce a more civilised error, from Core Lint, perhaps? We should not unsafely coerce between types with different representations, and that might not be too hard to spot. Just by looking at the kind of the two types. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 8 15:07:56 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 May 2018 15:07:56 -0000 Subject: [GHC] #15128: emitPrimOp: can't translate PrimOp In-Reply-To: <049.3c584bb9102092d760d7bec8a3884851@haskell.org> References: <049.3c584bb9102092d760d7bec8a3884851@haskell.org> Message-ID: <064.3c8b4d051a62b164740c4e5fddb6a0c6@haskell.org> #15128: emitPrimOp: can't translate PrimOp -------------------------------------+------------------------------------- Reporter: tianxiaogu | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Core Lint already catches this: {{{ From: State# s_a143 To: ByteArray# *** Core Lint warnings : in result of Simplifier *** : warning: In the expression: byteArrayContents# (s#_a13D `cast` (UnsafeCo representational (State# s_a143) ByteArray# :: (State# s_a143 :: TYPE ('TupleRep '[])) ~R# (ByteArray# :: TYPE 'UnliftedRep))) Unsafe coercion: between values with different # of reps From: State# s_a143 To: ByteArray# *** Core Lint warnings : in result of Simplifier *** : warning: In the expression: byteArrayContents# (eta_B1 `cast` (UnsafeCo representational (State# s_a143) ByteArray# :: (State# s_a143 :: TYPE ('TupleRep '[])) ~R# (ByteArray# :: TYPE 'UnliftedRep))) Unsafe coercion: between values with different # of reps From: State# s_a143 To: ByteArray# *** Core Lint warnings : in result of Simplifier *** : warning: In the expression: byteArrayContents# (eta_B1 `cast` (UnsafeCo representational (State# s_a143) ByteArray# :: (State# s_a143 :: TYPE ('TupleRep '[])) ~R# (ByteArray# :: TYPE 'UnliftedRep))) Unsafe coercion: between values with different # of reps From: State# s_a143 To: ByteArray# *** Core Lint warnings : in result of Tidy Core *** : warning: In the expression: byteArrayContents# (eta_B1 `cast` (UnsafeCo representational (State# s_a143) ByteArray# :: (State# s_a143 :: TYPE ('TupleRep '[])) ~R# (ByteArray# :: TYPE 'UnliftedRep))) Unsafe coercion: between values with different # of reps From: State# s_a143 To: ByteArray# *** Core Lint warnings : in result of CorePrep *** : warning: In the expression: byteArrayContents# (eta_s1gf `cast` (UnsafeCo representational (State# s_a143) ByteArray# :: (State# s_a143 :: TYPE ('TupleRep '[])) ~R# (ByteArray# :: TYPE 'UnliftedRep))) Unsafe coercion: between values with different # of reps From: State# s_a143 To: ByteArray# ghc: panic! (the 'impossible' happened) (GHC version 8.4.2 for x86_64-unknown-linux): emitPrimOp: can't translate PrimOp byteArrayContents# Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/codeGen/StgCmmPrim.hs:882:12 in ghc:StgCmmPrim Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} So perhaps we can close this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 8 15:09:59 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 May 2018 15:09:59 -0000 Subject: [GHC] #7411: Exceptions are optimized away in certain situations In-Reply-To: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> References: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> Message-ID: <065.93a5f2acb3f6729c554b88285c9d026d@haskell.org> #7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Replying to [comment:20 tdammers]: > Interestingly, the patch from #5129 does *not* fix this one too, so it's not just due to incorrectly optimizing `seq` away; there is more happening here. Following the #5129 lead, I added some trace logging to the code touched in #5129; specifically I trapped this case: {{{ | SeqOp <- op -> all (expr_ok primop_ok) args }}} ...which is what caught the `seq#` instances that were inappropriately optimized away previously. However, for the offending examples, this trap doesn't fire, which means we're not hitting the `SeqOp` case at all. So apparently the `seq` call gets optimized away at an earlier stage. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 8 15:23:33 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 May 2018 15:23:33 -0000 Subject: [GHC] #15128: emitPrimOp: can't translate PrimOp In-Reply-To: <049.3c584bb9102092d760d7bec8a3884851@haskell.org> References: <049.3c584bb9102092d760d7bec8a3884851@haskell.org> Message-ID: <064.08e9f2a624147c2aeeca1d5a87d70fbe@haskell.org> #15128: emitPrimOp: can't translate PrimOp -------------------------------------+------------------------------------- Reporter: tianxiaogu | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Core Lint already catches this: Fine. That seems great. Yes, let's close as invalid. Mind you, complaining about `different # of reps` s a bit obscure. Perhaps `different runtime representations`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 8 15:26:20 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 May 2018 15:26:20 -0000 Subject: [GHC] #15122: GHC HEAD typechecker regression (was: GHC HEAD typechecker regression involving overlapping instances) In-Reply-To: <046.6b6ee0b02b0ede932ee344925ca869d9@haskell.org> References: <046.6b6ee0b02b0ede932ee344925ca869d9@haskell.org> Message-ID: <061.3c128d0d689d4688fbd540d90a850299@haskell.org> #15122: GHC HEAD typechecker regression -------------------------------------+------------------------------------- Reporter: fmixing | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => TypeInType Comment: Never mind, I don't think this has anything to do with overlapping instances (or even type classes in particular), since the following also typechecks on GHC 8.4 but not on HEAD: {{{#!hs {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} module Bug where import Data.Proxy data Set (n :: [k]) where Empty :: Set '[] Ext :: e -> Set s -> Set (e ': s) type family (m :: [k]) :\ (x :: k) :: [k] where '[] :\ x = '[] (x ': xs) :\ x = xs (y ': xs) :\ x = y ': (xs :\ x) remove :: forall x y xs. ((y : xs) :\ x) ~ (y : (xs :\ x)) => Set (y ': xs) -> Proxy x -> Set ((y ': xs) :\ x) remove (Ext y xs) x = Ext y (remove' xs x (Proxy :: Proxy xs)) remove' :: Set s -> Proxy x -> Proxy xs -> Set (xs :\ x) remove' = undefined }}} Here's the error message on HEAD if you compile with `-fprint-explicit- kinds`: {{{ $ /opt/ghc/head/bin/ghc -fprint-explicit-kinds Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:24:23: error: • Could not deduce: ((:\) * ((':) * e s) x :: [*]) ~~ ((':) * e ((:\) * s x) :: [*]) from the context: (:\) k ((':) k y xs) x ~ (':) k y ((:\) k xs x) bound by the type signature for: remove :: forall k (x :: k) (y :: k) (xs :: [k]). ((:\) k ((':) k y xs) x ~ (':) k y ((:\) k xs x)) => Set k ((':) k y xs) -> Proxy k x -> Set k ((:\) k ((':) k y xs) x) at Bug.hs:(21,1)-(23,58) or from: ((k :: *) ~~ (* :: *), ((':) k y xs :: [k]) ~~ ((':) * e s :: [*])) bound by a pattern with constructor: Ext :: forall e (s :: [*]). e -> Set * s -> Set * ((':) * e s), in an equation for ‘remove’ at Bug.hs:24:9-16 Expected type: Set k ((:\) k ((':) k y xs) x) Actual type: Set * ((':) * e ((:\) * s x)) • In the expression: Ext y (remove' xs x (Proxy :: Proxy xs)) In an equation for ‘remove’: remove (Ext y xs) x = Ext y (remove' xs x (Proxy :: Proxy xs)) • Relevant bindings include x :: Proxy k x (bound at Bug.hs:24:19) xs :: Set * s (bound at Bug.hs:24:15) y :: e (bound at Bug.hs:24:13) remove :: Set k ((':) k y xs) -> Proxy k x -> Set k ((:\) k ((':) k y xs) x) (bound at Bug.hs:24:1) | 24 | remove (Ext y xs) x = Ext y (remove' xs x (Proxy :: Proxy xs)) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 8 15:31:27 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 May 2018 15:31:27 -0000 Subject: [GHC] #7411: Exceptions are optimized away in certain situations In-Reply-To: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> References: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> Message-ID: <065.8bce2752c72e09aa4646c9d2c69c7b20@haskell.org> #7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 8 15:35:13 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 May 2018 15:35:13 -0000 Subject: [GHC] #15122: GHC HEAD typechecker regression In-Reply-To: <046.6b6ee0b02b0ede932ee344925ca869d9@haskell.org> References: <046.6b6ee0b02b0ede932ee344925ca869d9@haskell.org> Message-ID: <061.326ea8ca16bf856d1bc05e7cac8eba9a@haskell.org> #15122: GHC HEAD typechecker regression -------------------------------------+------------------------------------- Reporter: fmixing | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): OK, even smaller now: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind import Data.Proxy data IsStar (a :: k) where IsStar :: IsStar (a :: *) type family F (a :: k) :: k foo :: (F a ~ F b) => IsStar a -> Proxy b -> Proxy (F a) -> Proxy (F b) foo IsStar _ p = p }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 8 15:40:02 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 May 2018 15:40:02 -0000 Subject: [GHC] #15019: Fix performance regressions from #14737 In-Reply-To: <047.36d31dd41a03f5d1b4531d3b52b0f31a@haskell.org> References: <047.36d31dd41a03f5d1b4531d3b52b0f31a@haskell.org> Message-ID: <062.d29f9c8e15a7398ce5726b241b6ca83b@haskell.org> #15019: Fix performance regressions from #14737 -------------------------------------+------------------------------------- Reporter: tdammers | Owner: tdammers Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #14737 | Differential Rev(s): phab:D4568 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): {{{ Remove unnecessary check in simplCast The coercion optimizer will take care of it anyway, and the check is prohibitively expensive. See Trac Trac #14737. Reviewers: bgamari Subscribers: simonpj, thomie, carter Differential Revision: https://phabricator.haskell.org/D4568 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 8 15:41:44 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 May 2018 15:41:44 -0000 Subject: [GHC] #15128: emitPrimOp: can't translate PrimOp In-Reply-To: <049.3c584bb9102092d760d7bec8a3884851@haskell.org> References: <049.3c584bb9102092d760d7bec8a3884851@haskell.org> Message-ID: <064.13ebec1875f598236ea7406d0f732495@haskell.org> #15128: emitPrimOp: can't translate PrimOp -------------------------------------+------------------------------------- Reporter: tianxiaogu | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 8 15:41:55 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 May 2018 15:41:55 -0000 Subject: [GHC] #15122: GHC HEAD typechecker regression In-Reply-To: <046.6b6ee0b02b0ede932ee344925ca869d9@haskell.org> References: <046.6b6ee0b02b0ede932ee344925ca869d9@haskell.org> Message-ID: <061.d9932128e7eec64162346e1c4f41873d@haskell.org> #15122: GHC HEAD typechecker regression -------------------------------------+------------------------------------- Reporter: fmixing | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by goldfire): I see this and will take a stab when I can. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 8 15:45:03 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 May 2018 15:45:03 -0000 Subject: [GHC] #14482: GHC -M mode fails to ensure that boot files are built before source files In-Reply-To: <046.f887b8665019281d6519a59f53c32782@haskell.org> References: <046.f887b8665019281d6519a59f53c32782@haskell.org> Message-ID: <061.e7da198053604af2afe0d602d09f7eae@haskell.org> #14482: GHC -M mode fails to ensure that boot files are built before source files -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14481 | Differential Rev(s): Phab:D4208 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): The original problem (which isn't clearly stated above): * `A.hs-boot` must be compiled before `A.hs`. Otherwise there is no check that `A.hs-boot` correctly reflects `A.hs`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 8 16:55:34 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 May 2018 16:55:34 -0000 Subject: [GHC] #15124: Improve block layout for the NCG In-Reply-To: <047.b2a760b384d29a2bc137285a934c2d79@haskell.org> References: <047.b2a760b384d29a2bc137285a934c2d79@haskell.org> Message-ID: <062.b5db2b36555707a4c6e34a677230f1e5@haskell.org> #15124: Improve block layout for the NCG -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (NCG) | Version: 8.2.2 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8082 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jmct): * cc: jmct (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 8 17:50:16 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 May 2018 17:50:16 -0000 Subject: [GHC] #15019: Fix performance regressions from #14737 In-Reply-To: <047.36d31dd41a03f5d1b4531d3b52b0f31a@haskell.org> References: <047.36d31dd41a03f5d1b4531d3b52b0f31a@haskell.org> Message-ID: <062.386391840e6da55271503abbb701157b@haskell.org> #15019: Fix performance regressions from #14737 -------------------------------------+------------------------------------- Reporter: tdammers | Owner: tdammers Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #14737 | Differential Rev(s): phab:D4568 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 8 20:52:17 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 May 2018 20:52:17 -0000 Subject: [GHC] #15019: Fix performance regressions from #14737 In-Reply-To: <047.36d31dd41a03f5d1b4531d3b52b0f31a@haskell.org> References: <047.36d31dd41a03f5d1b4531d3b52b0f31a@haskell.org> Message-ID: <062.cebb23c1530e89b7f35882d2ef5602b1@haskell.org> #15019: Fix performance regressions from #14737 -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #14737 | Differential Rev(s): phab:D4568 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: closed => new * owner: tdammers => (none) * resolution: fixed => Comment: But where is ​Phab:D4635? Did that land? comment:17 is all about that patch, but comment:19 is a different patch entirely. Re-opening until we sort this out. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 8 20:52:34 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 May 2018 20:52:34 -0000 Subject: [GHC] #7411: Exceptions are optimized away in certain situations In-Reply-To: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> References: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> Message-ID: <065.262aca757d48de85e82a2f0923736529@haskell.org> #7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I think the `-fno-state-hack` is almost certainly a clue, although I'm not exactly sure how it ends up relating in that specific example. What I ''suspect'' is happening (without actually tracing simplification) is roughly this: {{{#!hs evaluate (undefined `seq` return ()) -- ===> inline IO $ \s -> seq# (undefined `seq` IO (\s' -> (# s', () #))) s -- ===> simplify the coercions for my sanity IO $ \s -> seq# (IO $ undefined `seq` \s' -> (# s', () #)) s -- ===> This is where I suspect things go sideways. I believe we generally -- assume that it's okay to eta-expand IO things. IO $ \s -> seq# (IO $ \s'' -> (undefined `seq` (\s' -> (# s', () #))) s'') s }}} We've effectively turned a bottom with an `IO` type into a non-bottom `IO` value that only ''returns'' a bottom. Then the `seq#` ends up going away: {{{#!hs -- ===> beta reduce past seq IO $ \s -> seq# (IO $ \s'' -> undefined `seq` (# s'', () #)) s -- ===> PrelRules.seqRule says we can eliminate seq# for WHNF things IO $ \s -> (# s, IO $ \s'' -> undefined `seq` (# s'', () #)) }}} I imagine the behavior is a bit fragile because it depends on GHC not recognizing that the undefined value is in fact undefined, or at least not recognizing it too early. I suspect the solution is likely to make `-fpedantic-bottoms` go a little further than it currently does, although I don't know enough to say just what. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 8 21:13:52 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 May 2018 21:13:52 -0000 Subject: [GHC] #14547: Wrong warning by -Wincomplete-patterns In-Reply-To: <052.21a9ad8704f084ec9db31f385a693f01@haskell.org> References: <052.21a9ad8704f084ec9db31f385a693f01@haskell.org> Message-ID: <067.ff19cc57408465e007aebf92bf764978@haskell.org> #14547: Wrong warning by -Wincomplete-patterns -------------------------------------+------------------------------------- Reporter: YoshikuniJujo | Owner: (none) Type: bug | Status: closed Priority: low | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: incomplete- | patterns OverloadedLists, | PatternMatchWarnings TypeFamilies Operating System: Linux | Architecture: x86 Type of failure: Incorrect | Test Case: error/warning at compile-time | deSugar/should_compile/T14547 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4624 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"849547bd3a5bc6876268c94f97bf3e79c31340ec/ghc" 849547b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="849547bd3a5bc6876268c94f97bf3e79c31340ec" Revert "Normalize the element type of ListPat, fix #14547" This reverts commit 981bf4718de7daef7817a363ccc14030c2688632. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 8 21:14:07 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 May 2018 21:14:07 -0000 Subject: [GHC] #14547: Wrong warning by -Wincomplete-patterns In-Reply-To: <052.21a9ad8704f084ec9db31f385a693f01@haskell.org> References: <052.21a9ad8704f084ec9db31f385a693f01@haskell.org> Message-ID: <067.bd9205b45236aae842fc3f9eaf229147@haskell.org> #14547: Wrong warning by -Wincomplete-patterns -------------------------------------+------------------------------------- Reporter: YoshikuniJujo | Owner: (none) Type: bug | Status: closed Priority: low | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: incomplete- | patterns OverloadedLists, | PatternMatchWarnings TypeFamilies Operating System: Linux | Architecture: x86 Type of failure: Incorrect | Test Case: error/warning at compile-time | deSugar/should_compile/T14547 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4624 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"ba6e445e1cf31957f2a327a73f9f66cfa7f24e26/ghc" ba6e445/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ba6e445e1cf31957f2a327a73f9f66cfa7f24e26" Normalize the element type of ListPat, fix #14547 Summary: The element type of `List` maybe a type family instacen, rather than a trivial type. For example in Trac #14547, ``` {-# LANGUAGE TypeFamilies, OverloadedLists #-} class Foo f where type It f foo :: [It f] -> f data List a = Empty | a :! List a deriving Show instance Foo (List a) where type It (List a) = a foo [] = Empty foo (x : xs) = x :! foo xs ``` Here the element type of `[]` is `It (List a)`, we should also normalize it as `a`. Test Plan: make test TEST="T14547" Reviewers: bgamari Reviewed By: bgamari Subscribers: thomie, carter GHC Trac Issues: #14547 Differential Revision: https://phabricator.haskell.org/D4624 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 8 21:35:14 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 May 2018 21:35:14 -0000 Subject: [GHC] #7411: Exceptions are optimized away in certain situations In-Reply-To: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> References: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> Message-ID: <065.3bea24465f487c83db284a4fde015348@haskell.org> #7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Here's what is going on: * After a late float-out pass we get this {{{ lvl_s2Yn [Occ=Once] -- Comes from 'return ()' :: GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, () #) [LclId] lvl_s2Yn = \ (s_a2z6 [Occ=Once, Dmd=] :: GHC.Prim.State# GHC.Prim.RealWorld) -> (# s_a2z6, GHC.Tuple.() #) lvl_s2Yo [Occ=Once] :: GHC.Types.IO () [LclId] -- Comes from (('a':undefined) `dslist` return ()) lvl_s2Yo = case go_s2WQ lvl_s2Ym of { __DEFAULT -> lvl_s2Yn `cast` (Sym (GHC.Types.N:IO[0] <()>_R) :: (GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, () #) :: *) ~R# (GHC.Types.IO () :: *)) } main_s2z7 = \ (s_a2yI [Occ=Once, Dmd=] :: GHC.Prim.State# GHC.Prim.RealWorld) -> GHC.Prim.seq# @ (GHC.Types.IO ()) @ GHC.Prim.RealWorld lvl_s2Yo s_a2yI }}} So far so good. * But then we see that `lvl_s2Yn` has arity 1 (which it does). And then we eta-expand `lvl_s2Yo`, moving the lambda outside the `case go lvl_s2Ym`, to get {{{ lvl_s2Yo = (\ (eta_B1 [Occ=Once] :: GHC.Prim.State# GHC.Prim.RealWorld) -> case go_s2WQ lvl_s2Ym of { () -> (lvl_s2Yn `cast` ...) eta_B1 }) `cast` ... }}} * Aargh! Now `lvl_s2Yo` is a HNF, not bottom as it should be. And so `seq# lvl_s2Y# x` is (correctly) reduced to `x`. How to avoid this? It's the notorious "state hack" that "justifies" floating the lambda out. The motivation is functions like this: {{{ f :: [Int] -> IO () f xs = print ys >> print xs where ys = reverse xs }}} Without the state hack we get an arity-1 function thus {{{ f = \xs. let ys = reverse xs in \s. case print ys s of (# s' ,_ #) -> print xs s' }}} That's signficantly less efficient than an arity-2 function; but that penalty may be worth paying if the application `(f xs)` is shared. For example: {{{ let fxs = f [1..100] in fxs >> fxs >> fxs }}} In the arity-1 case we'd reverse `[1..100]` once; in the arity-2 case we'd reverse it three times. In practice this doesn't seem to come up much. ------------ I'm not sure it's worth fixing this. It doesn't seem to be harming anyone, an it's not clear how to fix it. The only fix I can think of (apart from abandoning the state hack) would be to restrict the state hack a bit more so that it doesn't apply to an arity-zero binding like `lvl_s2Yo` -- but still does apply to `f` above. But if we did that, then this minor variant of #7411 would still misbehave: {{{ {-# NOINLINE f #-} f2 :: Int -> IO () f2 x = ('a':undefined) `dslist` return () main = evaluate (f2 3) }}} Here I've just given `f` an argument; like `f`above it'll be eta-expanded. Morally, it's the same problem as before, but perhaps it just occurs less often. I'm inclined to focus on other tickets that are causing users actual pain. But it's a long time since I tried measuring the perf cost of simply switching the state hack off altogether. Would anyone like to to just try that? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 8 21:41:56 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 May 2018 21:41:56 -0000 Subject: [GHC] #15116: GHC internal error when GADT return type mentions its own constructor name In-Reply-To: <050.dc668ea98cda5bfcd872cc4585004dde@haskell.org> References: <050.dc668ea98cda5bfcd872cc4585004dde@haskell.org> Message-ID: <065.61f84cd0a958198b9de995622697f5c4@haskell.org> #15116: GHC internal error when GADT return type mentions its own constructor name -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: GADTs, Resolution: fixed | TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | polykinds/T15116, T15116a Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): For the record, I read this patch and think it's lovely. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 8 21:48:13 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 May 2018 21:48:13 -0000 Subject: [GHC] #11786: Need -fno-print-explicit-runtime-reps to work on IfaceType, else RuntimeRep leaks In-Reply-To: <046.943657e3f9ed3d83fd8aca1ffc9a9fa0@haskell.org> References: <046.943657e3f9ed3d83fd8aca1ffc9a9fa0@haskell.org> Message-ID: <061.0fc8e24bf161a21e52ee2a0141f8a97c@haskell.org> #11786: Need -fno-print-explicit-runtime-reps to work on IfaceType, else RuntimeRep leaks -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * priority: normal => highest * status: closed => new * resolution: fixed => * milestone: 8.2.1 => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 8 21:49:41 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 May 2018 21:49:41 -0000 Subject: [GHC] #15116: GHC internal error when GADT return type mentions its own constructor name In-Reply-To: <050.dc668ea98cda5bfcd872cc4585004dde@haskell.org> References: <050.dc668ea98cda5bfcd872cc4585004dde@haskell.org> Message-ID: <065.902da50a6ec9afd2cbda38ee7176bd36@haskell.org> #15116: GHC internal error when GADT return type mentions its own constructor name -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: GADTs, Resolution: fixed | TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | polykinds/T15116, T15116a Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Thank you! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 8 21:53:12 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 May 2018 21:53:12 -0000 Subject: [GHC] #15019: Fix performance regressions from #14737 In-Reply-To: <047.36d31dd41a03f5d1b4531d3b52b0f31a@haskell.org> References: <047.36d31dd41a03f5d1b4531d3b52b0f31a@haskell.org> Message-ID: <062.48fe3713ef9f759ef9caee399b182a5f@haskell.org> #15019: Fix performance regressions from #14737 -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #14737 | Differential Rev(s): phab:D4635 Wiki Page: | -------------------------------------+------------------------------------- Changes (by tdammers): * status: new => patch * differential: phab:D4568 => phab:D4635 Comment: Figured out what went wrong. Phab:D4568 was listed in the ticket data, but that one actually belongs to #14737, where we fixed the badness in the infamous Grammar.hs (now the T13737 test case), and doctored the performance tests to silence the resulting regressions. This one has landed. The patch that is supposed to close this ticket is Phab:D4635, where we fix the regressions introduced earlier. This one hasn't landed, but I believe it should ASAP. The confusion came from me looking at the status of D4568 earlier today, but thinking I was looking at D4635; seeing that the patch had landed, I concluded that this should close the ticket as well. So, in short: this ticket isn't done yet, but all that's missing is landing Phab:D4635. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 8 21:56:43 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 May 2018 21:56:43 -0000 Subject: [GHC] #15131: Speed up certain Foldable NonEmpty methods Message-ID: <045.a14e4452f4631f3337e0e1509638b7cc@haskell.org> #15131: Speed up certain Foldable NonEmpty methods -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Core | Version: 8.2.2 Libraries | 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: -------------------------------------+------------------------------------- Yitzchak Gale pointed out [https://www.reddit.com/r/haskell/comments/8hxpns/why_is_nonempty_missing_some_foldable_method/ on Reddit] that some `Foldable` methods are allowed to take default definitions for `NonEmpty` when they probably shouldn't. The biggest problem appears to be `foldr1`, which ends up with a fairly atrocious definition. Yitz seems to think we should also provide a custom definition of `null`, to avoid relying on optimizations, but at present there is no obvious need for that. He doesn't mention this, but the definition of `length` should be changed. Indeed, the default definition of `length` would be better than the custom definition we currently have. I also noticed that we don't mark `foldl1` `INLINE`. At present its unfolding is optimized, so its `foldr` is not exposed. Thus, for example, {{{#!hs foldl1 (+) $ 1 :| [2..n] }}} won't fuse. We can certainly mark `foldl1` `INLINE` to fix this (`INLINABLE` doesn't do the trick), but it would be nice to know if there's another way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 8 22:11:10 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 May 2018 22:11:10 -0000 Subject: [GHC] #7411: Exceptions are optimized away in certain situations In-Reply-To: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> References: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> Message-ID: <065.11c4a3176202acd85f119e1415870b2b@haskell.org> #7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Simon, I don't see anything problematic about the floating. It looks to me as though the eta expansion past the `case` is where meaning shifts, but maybe I'm missing something? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 8 22:56:37 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 May 2018 22:56:37 -0000 Subject: [GHC] #15122: GHC HEAD typechecker regression In-Reply-To: <046.6b6ee0b02b0ede932ee344925ca869d9@haskell.org> References: <046.6b6ee0b02b0ede932ee344925ca869d9@haskell.org> Message-ID: <061.b6500fe02386c727afda73a197e87b3f@haskell.org> #15122: GHC HEAD typechecker regression -------------------------------------+------------------------------------- Reporter: fmixing | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by simonpj): I took a look. Not yet complete but may help Richard. Analysing the program in cmmment:8. {{{ foo :: (F a ~ F b) => IsStar a -> Proxy b -> Proxy (F a) -> Proxy (F b) foo IsStar _ p = p }}} Informally we have {{{ (a::k), (b::k) [G] F a ~ F b [G] k ~ * [W] F a ~ F b }}} The given `k ~ *` should rewrite both the given and wanted equality, which should allow us to prove it no problem. The firsts slightly surprising thing is that the data constructor `IsStar` binds an existential: {{{ IsStar : forall k (a::k). forall (a2::*). (k~*, a~a2) => IsStar @k a }}} Is this rigth? Well, if `IsStar` had some arguments it mmight be more persuasive {{{ data IsStar2 (a :: k) where IsStar2 :: a2 -> IsStar a2 }}} Now {{{ IsStar : forall k (a::k). forall (a2::*). (k~*, a~a2) => a2 -> IsStar @k a }}} We can't have `a` on the LHS of the arrow, because it has the wrong kind. Here's the implication we can't solve {{{ Implic { TcLevel = 2 Skolems = k_a1hM[sk:2] (a_a1hN[sk:2] :: k_a1hM[sk:2]) (b_a1hO[sk:2] :: k_a1hM[sk:2]) No-eqs = False Status = Unsolved Given = $d~_a1hQ :: (F a_a1hN[sk:2] :: k_a1hM[sk:2]) ~ (F b_a1hO[sk:2] :: k_a1hM[sk:2]) Wanted = WC {wc_impl = Implic { TcLevel = 3 Skolems = a_a1hR[ssk:3] No-eqs = False Status = Unsolved Given = co_a1hS :: (k_a1hM[sk:2] :: *) ~# (* :: *) co_a1hT :: (a_a1hN[sk:2] :: k_a1hM[sk:2]) ~# (a_a1hR[ssk:3] :: *) Wanted = WC {wc_simple = [WD] hole{co_a1ig} {3}:: (F (b_a1hO[sk:2] |> co_a1hS) :: *) ~# (F a_a1hR[ssk:3] :: *) (CNonCanonical)} Binds = EvBindsVar a pattern with constructor: IsStar :: forall a. IsStar a, in an equation for `foo_a1hP' }} }}} Not yet sure why we can't solve it. At the crucial moment in typechecking `foo` we see this: {{{ work item = [WD] hole{co_a1hU} {0}:: (F a_a1hN[sk:2] :: k_a1hM[sk:2]) ~# (F b_a1hO[sk:2] :: k_a1hM[sk:2]) (CNonCanonical) inerts = {Equalities: [G] co_a1hS {0}:: (k_a1hM[sk:2] :: *) ~# (* :: *) (CTyEqCan) [G] co_a1i4 {1}:: (fsk_a1i0[fsk:0] :: k_a1hM[sk:2]) ~# (fsk_a1i2[fsk:0] :: k_a1hM[sk:2]) (CTyEqCan) [G] co_a1i9 {1}:: (a_a1hN[sk:2] :: k_a1hM[sk:2]) ~# ((a_a1hR[ssk:3] |> Sym co_a1hS) :: k_a1hM[sk:2]) (CTyEqCan) Type-function equalities = [G] co_a1ib {0}:: (F (b_a1hO[sk:2] |> co_a1hS) :: *) ~# (fsk_a1ia[fsk:0] :: *) (CFunEqCan) [G] co_a1id {0}:: (F a_a1hR[ssk:3] :: *) ~# (fsk_a1ic[fsk:0] :: *) (CFunEqCan) Dictionaries = [G] $d~~_a1i8 {0}:: ((fsk_a1i2[fsk:0] |> co_a1hS) :: *) ~~ ((fsk_a1i2[fsk:0] |> co_a1hS) :: *) (CDictCan) [G] $d~_a1i7 {0}:: ((fsk_a1i2[fsk:0] |> co_a1hS) :: *) ~ ((fsk_a1i2[fsk:0] |> co_a1hS) :: *) (CDictCan) }}} Note these two lines: {{{ [G] co_a1hS {0}:: (k_a1hM[sk:2] :: *) ~# (* :: *) (CTyEqCan) [G] co_a1i4 {1}:: (fsk_a1i0[fsk:0] :: k_a1hM[sk:2]) ~# (fsk_a1i2[fsk:0] :: k_a1hM[sk:2]) (CTyEqCan) }}} The first can rewrite the second, but we have not made it do so. I think because the substitution does not claim to be idempotent. But then we end up trying to prove that {{{ [W] fsk1 :: * ~ fsk2 : * }}{ and we have somehow lost the connection to our 'givens'. That's as far as I got. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 9 00:40:28 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 May 2018 00:40:28 -0000 Subject: [GHC] #15131: Speed up certain Foldable NonEmpty methods In-Reply-To: <045.a14e4452f4631f3337e0e1509638b7cc@haskell.org> References: <045.a14e4452f4631f3337e0e1509638b7cc@haskell.org> Message-ID: <060.793188dfc2be30e1ed933fea235cf2aa@haskell.org> #15131: Speed up certain Foldable NonEmpty methods -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4677 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch * differential: => Phab:D4677 Comment: I've put together a patch, Phab:D4677, to make `foldr1` decent and `length` slightly better. I'll wait for feedback from mpickering and/or nomeata before mucking about with inlining. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 9 03:52:23 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 May 2018 03:52:23 -0000 Subject: [GHC] #10346: Cross-module SpecConstr In-Reply-To: <046.b576f13f2450fed85380ce289fdfae5b@haskell.org> References: <046.b576f13f2450fed85380ce289fdfae5b@haskell.org> Message-ID: <061.e39c8fbc69e171af83fcd067142b804c@haskell.org> #10346: Cross-module SpecConstr -------------------------------------+------------------------------------- Reporter: simonpj | Owner: ckoparkar Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: SpecConstr, | newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13016 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ckoparkar): It turns out that I was comparing the Core output of the regular Specializer instead of SpecConstr. Now that I'm looking at the proper thing, I'm a bit confused and have the same question as ak3n did. Even if I just use GHC HEAD, it seems that the call to `foo` in a different module is specialized. Using the same example with modules `M` and `X`, and compiling it with: `ghc-stage2 -O2 -fforce-recomp -ddump-spec -fspec- constr -fno-specialize X.hs`, this is what `bar` looks like after SpecConstr runs: {{{ bar :: (Integer, Integer) [LclIdX] bar = case $wfoo1_s1h9 GHC.Types.False ww_s1h3 ww_s1h4 of { (# ww_s1ha, ww_s1hb #) -> (ww_s1ha, ww_s1hb) } }}} (This is exactly what the last paragraph in the `Note [Seeding top-level recursive groups]` says should happen. There's a specialized copy of `foo` in the importing module. Or that's what I think it is.) I feel like I'm making a dumb mistake and I'm trying to track this down. mpickering: Do you remember if you were using some specific example while working on that patch ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 9 07:24:38 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 May 2018 07:24:38 -0000 Subject: [GHC] #9221: (super!) linear slowdown of parallel builds on 40 core machine In-Reply-To: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> References: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> Message-ID: <060.04b862d63e748a75ea8029851024b8c1@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #910, #8224 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by maoe): * cc: maoe (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 9 08:08:18 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 May 2018 08:08:18 -0000 Subject: [GHC] #7411: Exceptions are optimized away in certain situations In-Reply-To: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> References: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> Message-ID: <065.b2b44e7590c526a8b09181e3b84dcc48@haskell.org> #7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > I don't see anything problematic about the floating If we eta-expand `lvl_s2Yo` its value goes from possibly-bottom (if there are bottoms in the list, which there are) to definitely non-bottom. As a result `seq# lvl_s2yo e` is optimised to `e`; which is incorrect here (that is precisely the bug reported), but absolutely fine for definite non-values in the first argument. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 9 08:28:18 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 May 2018 08:28:18 -0000 Subject: [GHC] #14684: combineIdenticalAlts is only partially implemented In-Reply-To: <049.66bb6a9ebb8aeb6bc16c5fd3f9c006db@haskell.org> References: <049.66bb6a9ebb8aeb6bc16c5fd3f9c006db@haskell.org> Message-ID: <064.89adc0b50845b14593bd76b29a0fb699@haskell.org> #14684: combineIdenticalAlts is only partially implemented -------------------------------------+------------------------------------- Reporter: mpickering | Owner: sjakobi Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: newcomer, CSE Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4542 Wiki Page: | -------------------------------------+------------------------------------- Comment (by sjakobi): As I haven't made any progress with this in a while, and as I'm not sure I'll make any soon, I'm recording where I'm currently stuck: While `combineIdenticalAlts` uses {{{ cheapEqExpr' :: (Tickish Id -> Bool) -> Expr b -> Expr b -> Bool }}} `CSE.combineAlts` uses {{{ eqExpr :: InScopeSet -> CoreExpr -> CoreExpr -> Bool }}} What I haven't figured out, is how to translate the use of `eqExpr` into using a `CoreMap` where `CoreExpr`s end up as the same key if they are equal according to `eqExpr in_scope`. I wanted to look at how the rest of `CSE` uses `CoreMap`s, but I didn't get around to that yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 9 08:46:23 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 May 2018 08:46:23 -0000 Subject: [GHC] #13362: GHC first generation of GC to be as large as largest cache size by default In-Reply-To: <045.9df30bf1acd19df01317b133116e51f6@haskell.org> References: <045.9df30bf1acd19df01317b133116e51f6@haskell.org> Message-ID: <060.e3f5ec1e1a764bbe416f43e629b28f1c@haskell.org> #13362: GHC first generation of GC to be as large as largest cache size by default -------------------------------------+------------------------------------- Reporter: varosi | Owner: sjakobi Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: numa cache gc | newcomers Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4679 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sjakobi): * differential: => Phab:D4679 Comment: In order to move things forward, I have uploaded a patch. Regarding my questions from comment:11, I propose only looking at L3 and L2 caches for now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 9 09:03:10 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 May 2018 09:03:10 -0000 Subject: [GHC] #15125: Typeclass instance selection depends on the optimisation level In-Reply-To: <046.a1eae0b46fb82f39391c9ac78a55a0fc@haskell.org> References: <046.a1eae0b46fb82f39391c9ac78a55a0fc@haskell.org> Message-ID: <061.804525ecb09f9953491de1591c5b494e@haskell.org> #15125: Typeclass instance selection depends on the optimisation level -------------------------------------+------------------------------------- Reporter: nicuveo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I investigated. Turns out that this is a near-dup of #14434 -- a bug in the "short-cut solver" for type classes. Happily, it was fixed six months ago, and the fix is in 8.4. I also agree with comment:4. So I'll just close this. I don't think it's worth a new regression test. If anyone reading this has a concrete suggestion for making the user manual clearer, please do re-open and off your proposed text. The user manual can always do with improvement! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 9 09:03:18 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 May 2018 09:03:18 -0000 Subject: [GHC] #7411: Exceptions are optimized away in certain situations In-Reply-To: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> References: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> Message-ID: <065.6e16c859df316ad1c9b10fb979ecfa4e@haskell.org> #7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Replying to [comment:26 simonpj]: > I'm not sure it's worth fixing this. It doesn't seem to be harming anyone, an it's not clear how to fix it. OK, so here's what I think. Right now, the simplifier will change the behavior of programs. This is completely unexpected and undocumented, and it's subtle enough to make it all-night debugging session material. I'm a bit uncomfortable with just shrugging this off. Last resort would be to just document the problem (where?) and move on; but I think we should at least give the other options a fair try. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 9 09:06:20 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 May 2018 09:06:20 -0000 Subject: [GHC] #7411: Exceptions are optimized away in certain situations In-Reply-To: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> References: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> Message-ID: <065.215693c4fe009fe5b5b99511a3b7bec3@haskell.org> #7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > I think we should at least give the other options a fair try. Do you have other options in mind? This has bugged us for a decade -- it's why it's called the "state hack". Getting perf numbers for compiling everything (incl libraries) with `-fno- state-hack` would give us a bit of data to go on. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 9 09:17:27 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 May 2018 09:17:27 -0000 Subject: [GHC] #15125: Typeclass instance selection depends on the optimisation level In-Reply-To: <046.a1eae0b46fb82f39391c9ac78a55a0fc@haskell.org> References: <046.a1eae0b46fb82f39391c9ac78a55a0fc@haskell.org> Message-ID: <061.bf7678226b5dc8c0f157ed606d4de131@haskell.org> #15125: Typeclass instance selection depends on the optimisation level -------------------------------------+------------------------------------- Reporter: nicuveo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nicuveo): I am afraid I still see this behaviour in 8.4.2... I replaced INCOHERENT with OVERLAPPABLE, built my small example with --resolver nightly-2018-05-09, and in both cases it shortcuts and picks the general instance and prints 0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 9 09:38:58 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 May 2018 09:38:58 -0000 Subject: [GHC] #7411: Exceptions are optimized away in certain situations In-Reply-To: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> References: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> Message-ID: <065.2f78e372d66ee60de3b83a38a12584bc@haskell.org> #7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Replying to [comment:30 simonpj]: > > I think we should at least give the other options a fair try. > > Do you have other options in mind? This has bugged us for a decade -- it's why it's called the "state hack". > > Getting perf numbers for compiling everything (incl libraries) with `-fno-state-hack` would give us a bit of data to go on. I'm thinking in two directions here. The first one would be to just throw out the state hack altogether, as you suggested, or at least make `-fno-state-hack` the default and pepper the `fstate-hack` flag with dire warnings. Timing things with and without the state hack shouldn't be a very difficult task, so I suggest I put a bit of time into this. For the second one, let me summarize what I think the core of the problem is: The equational reasoning strategies behind this eta expansion and `seq` are at odds. The eta expansion assumes that floating bottoms around will not make an effective difference (as per fast-and-loose reasoning), but this assumption doesn't hold when `seq` is involved, because `seq` is like this magical backdoor to bottoms. Eta expansion says that `case x of { _ -> f }` is equivalent to `\eta -> case x of { _ -> f eta }`, even if there are bottoms involved. But this breaks when `seq` is involved, because the eta expansion allows the argument to slip past `seq`. So what we would need to fix this "properly" would be a way to mark the relevant code sections as "here be dragons", and make the state hack skip over those. But I suspect this would be a rather invasive change (extending Core with such markers), and detecting such sections correctly could be tricky. Or maybe not, I really don't know. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 9 10:41:11 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 May 2018 10:41:11 -0000 Subject: [GHC] #15131: Speed up certain Foldable NonEmpty methods In-Reply-To: <045.a14e4452f4631f3337e0e1509638b7cc@haskell.org> References: <045.a14e4452f4631f3337e0e1509638b7cc@haskell.org> Message-ID: <060.68a49340b247fc40f66bb3d7d907e0ed@haskell.org> #15131: Speed up certain Foldable NonEmpty methods -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4677 Wiki Page: | -------------------------------------+------------------------------------- Comment (by YitzGale): I just gave one or two examples in the reddit thread, but really all the methods need review. I'm not convinced about the default {{length}} being better. Perhaps switch the order, {{List.length as + 1}}. Does GHC not inline primitive {{+}}? And you do an extra {{+0}}. But if I'm wrong, the clear explanatory comment is highly appreciated. Why not just put the obvious trivial explicit implementation for every method? It would make the code cleaner and easier to read, without having to look up the default and then scratch your head about what gets optimized. Note that for historical reasons several methods for List are still implemented via {{foldl}}. That is in very rare cases better than {{foldl'}}, in many cases the same because GHC optimizes it, and in some cases worse. My opinion is that {{NonEmpty}} should always behave the same as {{List}}, whatever that may be. It's worth it to add one extra operation to the {{NonEmpty}} implementation so that we can refer to the List implementation and not hard-code a copy of it. Here's my alternative "patch" (sorry I don't know how to offer an alternative patch on Phab): {{{ #!haskell instance Foldable NonEmpty where elem x (a :| as) = x == a || x `List.elem` as foldl f z ~(a :| as) = List.foldl f (f z a) as foldl' f z ~(a :| as) = let z' = f z a in z' `seq` foldl' f z' as foldl1 f ~(a :| as) = List.foldl f a as foldr f z ~(a :| as) = f a (List.foldr f z as) foldr1 f ~(a :| as) = List.foldr f a as foldMap f ~(a :| as) = f a `mappend` foldMap f as fold ~(m :| ms) = m `mappend` fold ms length (_ :| as) = List.length as + 1 maximum (a :| as) = max a (List.maximum as) minimum (a :| as) = min a (List.minimum as) null _ = False product (a :| as) = a * List.product as sum (a :| as) = a + List.sum as toList (a :| as) = a : as -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 9 11:13:13 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 May 2018 11:13:13 -0000 Subject: [GHC] #15009: Float equalities past local equalities In-Reply-To: <047.0a49c3ac676b2b3bc6f93c4594762c08@haskell.org> References: <047.0a49c3ac676b2b3bc6f93c4594762c08@haskell.org> Message-ID: <062.fb05d3507ed42953a6fbabb899739b65@haskell.org> #15009: Float equalities past local equalities -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.3 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I took a look. Turns out that it is what I guessed: > I don't say that it's perfectly implemented (eg I'm a bit worried about whether it's sensitive to whether the constraint looks like a ~ b or b ~ a) We end up with {{{ Implic { TcLevel = 2 Skolems = a_a2do[sk:2] p_a2dt[sk:2] No-eqs = True Status = Unsolved Given = Wanted = WC {wc_impl = Implic { TcLevel = 3 Skolems = b_a2dp[ssk:3] No-eqs = True Status = Unsolved Given = $d~_a2dq :: (b_a2dp[ssk:3] :: *) ~ (a_a2do[tau:2] :: *) Wanted = WC {wc_simple = [WD] hole{co_a2dE} {1}:: (p_a2dt[sk:2] :: *) GHC.Prim.~# (Bool :: *) (CNonCanonical) [WD] hole{co_a2dR} {1}:: (a_a2do[sk:2] :: *) GHC.Prim.~# (Bool :: *) (CNonCanonical)} a pattern with constructor: MkT1 :: forall b a. ((b :: *) ~ (a :: *)) => b -> T1 a }}} After expanding superclases etc, that Given `b_a2dp ~ a_a2do` turns into {{{ [G] (a_a2do[tau:2] :: *) GHC.Prim.~# (b_a2dp[ssk:3] :: *) }}} with the unification variable carefully placed on the left (see `TcUnify.swapOverTyVars`. But alas `TcSMonad.getNoGivenEqs` only looks on the left in the test `skolem_bound_here`. So it conservatively says "this implication may bind non-local equalities" and we lose. I see two ways to fix this 1. Make `getNoGivenEqs` look on the right as well as the left. That, a Given `CTyEqCan` equality `b ~# a` would not count as a "given equality" if `a` is a skolem bound by this implication. 2. Change `swapOverTyVars` so that puts the skolem (not the meta-tyvar) on the left for Givens. (No change for Wanteds.) I think (2) is better. I think (1) won't help at all. Consider doing type inference for `f`: {{{ data T1 a where MkT1 :: a ~ b => b -> T1 a f (MkT1 a) = not a }}} We decide (roughly) that `f :: T alpha[1] -> beta[1]`, and then simplify this implication {{{ forall[2] b. (alpha[1] ~# b) => alpha[1] ~# Bool, beta[1] ~# Bool }}} (The `[1]` and `[2]` are the level numbers; `alpha[1]` is untouchable inside the `[2]` implication.) If we orient the Given as shown, with `alpha[1]` on the left, we'll rewrite the Wanteds thus: {{{ forall[2] b. (alpha[1] ~# b) => b ~# Bool, beta[1] ~# Bool }}} And now, ''even if we say that the Given doesn't count as a "given equality"'', we still can't solve that `b ~# Bool`. (We could float and solve `beta[1] ~# Bool`, but that's only half the problem.) What we want is to orient the Given the other way round `b ~# alpha[1]`. Then we could float out ''both'' Wanteds. Another way to think about putting `b` on the left is that it helps to eliminate occurrences of skolems, which might prevent floating. Richard, any thoughts? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 9 11:16:47 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 May 2018 11:16:47 -0000 Subject: [GHC] #15132: Hadrian-built GHC cannot locate `unlit` Message-ID: <047.d089c6615b0cd7036d5e9baacadd7872@haskell.org> #15132: Hadrian-built GHC cannot locate `unlit` ----------------------------------------+--------------------------------- Reporter: tdammers | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Build System | Version: Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- When trying to compile a Literate Haskell source with a Hadrian-built GHC, compilation fails due to GHC not finding the `unlit` binary. How to reproduce: - Compile GHC using the default Hadrian `build.sh` script - Create a minimal LHS file, e.g. `echo '> main = return ()' > test.lhs` - Compile the LHS file with the in-place GHC: `$GHC_SRC_TREE/_build/stage1/bin/ghc test.lhs` This fails with something like: {{{ ghc: could not execute: $GHC_SRC_TREE/_build/stage1/lib/bin/unlit }}} However, the `unlit` binary is in `$GHC_SRC_TREE/_build/stage1/bin/unlit`. Considering how `make`-built GHC works fine, this seems to be a misconfiguration in the Hadrian build system. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 9 11:26:47 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 May 2018 11:26:47 -0000 Subject: [GHC] #15133: Make `nofib` work with Hadrian Message-ID: <047.3debb5e25137f26bba1d26ebffe5dbd6@haskell.org> #15133: Make `nofib` work with Hadrian -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: NoFib | Version: benchmark suite | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hadrian puts its build output in different places than the make-based build system; but nofib has the make-based paths (`inplace/bin/ghc- stage2`) hardcoded into it. It would be nice to provide a convenient way of making it work out of the box, ideally by detecting a Hadrian-built GHC and changing the paths accordingly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 9 11:33:11 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 May 2018 11:33:11 -0000 Subject: [GHC] #15038: Memory Corruption (strange closure type) In-Reply-To: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> References: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> Message-ID: <064.06987562b47a477abb09ad83cd1fdee2@haskell.org> #15038: Memory Corruption (strange closure type) -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #9718 | Differential Rev(s): Phab:D4680 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * differential: Phab:D4652 => Phab:D4680 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 9 11:37:03 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 May 2018 11:37:03 -0000 Subject: [GHC] #15125: Typeclass instance selection depends on the optimisation level In-Reply-To: <046.a1eae0b46fb82f39391c9ac78a55a0fc@haskell.org> References: <046.a1eae0b46fb82f39391c9ac78a55a0fc@haskell.org> Message-ID: <061.002ab1bc56aaa48d46ab864229bb4676@haskell.org> #15125: Typeclass instance selection depends on the optimisation level -------------------------------------+------------------------------------- Reporter: nicuveo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nicuveo): Since in 8.4.2 the behaviour does not depend on the optimization level, should I maybe close this bug and reopen ticket:14434? Or should I rewrite this one and create a better minimal test case? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 9 12:45:10 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 May 2018 12:45:10 -0000 Subject: [GHC] #15111: GHCi leaks the first modules loaded In-Reply-To: <047.0c4c39abd5bd384dc6fc34801a3d6baa@haskell.org> References: <047.0c4c39abd5bd384dc6fc34801a3d6baa@haskell.org> Message-ID: <062.13959dd26ceb17ecde8b14937639c6a0@haskell.org> #15111: GHCi leaks the first modules loaded -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: ghci Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4658 Wiki Page: | Phab:D4659 -------------------------------------+------------------------------------- Comment (by Simon Marlow ): In [changeset:"5fe6aaa3756cda654374ebfd883fa8f064ff64a4/ghc" 5fe6aaa/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5fe6aaa3756cda654374ebfd883fa8f064ff64a4" Add -fghci-leak-check to check for space leaks Summary: Space leaks in GHCi emerge from time to time and tend to come back again after they get fixed. This is an attempt to limit regressions by * adding a reliable detection for some classes of space leaks in GHCi * turning on leak checking for all GHCi tests in the test suite, so that we'll notice if the leak appears again. The idea for detecting space leaks is quite simple: * find some data that we expect to be GC'd later, make a weak pointer to it * when we expect the data to be dead, do a `performGC` and then check the status of the weak pointer. It would be nice to apply this trick to lots of things in GHC, e.g. ensuring that HsSyn is not retained after the desugarer, or ensuring that CoreSyn from the previous simplifier pass is not retained. Test Plan: validate Reviewers: bgamari, simonpj, erikd, niteria Subscribers: thomie, carter GHC Trac Issues: #15111 Differential Revision: https://phabricator.haskell.org/D4658 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 9 13:04:01 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 May 2018 13:04:01 -0000 Subject: [GHC] #15125: Typeclass instance selection depends on the optimisation level In-Reply-To: <046.a1eae0b46fb82f39391c9ac78a55a0fc@haskell.org> References: <046.a1eae0b46fb82f39391c9ac78a55a0fc@haskell.org> Message-ID: <061.82f7716ae029a6509256f6da7911e03a@haskell.org> #15125: Typeclass instance selection depends on the optimisation level -------------------------------------+------------------------------------- Reporter: nicuveo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I'm quite confused, as I can't seem to trigger this bug in GHC 8.4.2 (or HEAD). First, it's worth noting that the tarball you provided has a slightly different program than the one you gave in the original description. The modules in the tarball are: {{{#!hs {-# LANGUAGE FlexibleInstances #-} {-# OPTIONS_GHC -fno-warn-simplifiable-class-constraints #-} module A where import Data.Maybe class A a where someValue :: a -> Maybe Int instance {-# INCOHERENT #-} A a where someValue = const Nothing getInt :: A a => a -> Int getInt x = fromMaybe 0 $ someValue x }}} {{{#!hs module B where import A data B = B Int data C = C Int instance A B where someValue (B x) = Just x getBInt :: Int getBInt = getInt $ B 42 getCInt :: Int getCInt = getInt $ C 42 }}} {{{#!hs -- Main.hs import B main :: IO () main = do putStrLn "==========================================" putStrLn $ "B: " ++ show getBInt putStrLn $ "C: " ++ show getCInt }}} I'll use these, since the programs in the original description do not compile. Second, when I compile and run these with GHC 8.4.2, I get the same answer, regardless of optimization level: {{{ $ /opt/ghc/8.4.2/bin/ghc -O0 -fforce-recomp Main.hs [1 of 3] Compiling A ( A.hs, A.o ) [2 of 3] Compiling B ( B.hs, B.o ) [3 of 3] Compiling Main ( Main.hs, Main.o ) Linking Main ... $ ./Main ========================================== B: 42 C: 0 $ /opt/ghc/8.4.2/bin/ghc -O2 -fforce-recomp Main.hs [1 of 3] Compiling A ( A.hs, A.o ) [2 of 3] Compiling B ( B.hs, B.o ) [3 of 3] Compiling Main ( Main.hs, Main.o ) Linking Main ... $ ./Main ========================================== B: 42 C: 0 }}} So unless you're using a yet more different version of this program, I'm inclined to agree that there is no bug here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 9 13:29:22 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 May 2018 13:29:22 -0000 Subject: [GHC] #15131: Speed up certain Foldable NonEmpty methods In-Reply-To: <045.a14e4452f4631f3337e0e1509638b7cc@haskell.org> References: <045.a14e4452f4631f3337e0e1509638b7cc@haskell.org> Message-ID: <060.15c40b91fff159ccbdbf4ff0ec2d4558@haskell.org> #15131: Speed up certain Foldable NonEmpty methods -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4677 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Yours has to hold on to the "and then add one" while calculating the length of the list. Same goes for `max` and `min`. I'll look more later. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 9 13:37:26 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 May 2018 13:37:26 -0000 Subject: [GHC] #15134: enumFrom... aren't really documented. Message-ID: <045.101e34e5570fe8f6e2839dfe4e91d13c@haskell.org> #15134: enumFrom... aren't really documented. -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Core | Version: 8.2.2 Libraries | Keywords: | 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 Haddocks for `enumFrom`, `enumFromTo`, etc., say nothing whatsoever about what these functions actually do. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 9 13:37:29 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 May 2018 13:37:29 -0000 Subject: [GHC] #15125: Typeclass instance selection depends on the optimisation level In-Reply-To: <046.a1eae0b46fb82f39391c9ac78a55a0fc@haskell.org> References: <046.a1eae0b46fb82f39391c9ac78a55a0fc@haskell.org> Message-ID: <061.b160d3c2037b180da59adb5415e1ee3d@haskell.org> #15125: Typeclass instance selection depends on the optimisation level -------------------------------------+------------------------------------- Reporter: nicuveo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nicuveo): Yes, I'm using the version in the tarball; I simplified it for the purpose of the bug description. And my apologies: I double-checked, and indeed, the code in the tarball works for 8.4.2; my stack setup was wrong. Sorry about that! ...however, sadly, there is the other bug I highlight in comment:6. If you replace //A.hs// to read: {{{#!hs instance A a where someValue = const Nothing }}} and //B.hs// to read: {{{#!hs instance {-# OVERLAPPING #-} A B where someValue (B x) = Just x }}} Then the same behaviour is back with 8.4.2: with -O0, it prints 42, with -O2, it prints 0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 9 13:43:39 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 May 2018 13:43:39 -0000 Subject: [GHC] #15134: enumFrom... aren't really documented. In-Reply-To: <045.101e34e5570fe8f6e2839dfe4e91d13c@haskell.org> References: <045.101e34e5570fe8f6e2839dfe4e91d13c@haskell.org> Message-ID: <060.22a9f921fa901da10b86fcf946b96522@haskell.org> #15134: enumFrom... aren't really documented. -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 9 13:47:25 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 May 2018 13:47:25 -0000 Subject: [GHC] #15125: Typeclass instance selection depends on the optimisation level In-Reply-To: <046.a1eae0b46fb82f39391c9ac78a55a0fc@haskell.org> References: <046.a1eae0b46fb82f39391c9ac78a55a0fc@haskell.org> Message-ID: <061.25d625318a892c92965e206a6eb4bd9e@haskell.org> #15125: Typeclass instance selection depends on the optimisation level -------------------------------------+------------------------------------- Reporter: nicuveo | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14434 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #14434 Comment: Indeed, that is a separate bug, so I'd recommend opening a new ticket so that it does not get lost in here. Some advice for the future: * Make sure to post the complete code. The files in the original description leave off several details like the language extensions and module names. Without these, we have to reverse-engineer them, which is quite annoying. * Don't bother posting `stack.yaml` files or other extraneous things like that. An ideal reproducing test case is one where you can simply invoke GHC on some files to produce the issue. And you already have such a test case! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 9 13:50:49 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 May 2018 13:50:49 -0000 Subject: [GHC] #15125: Typeclass instance selection depends on the optimisation level In-Reply-To: <046.a1eae0b46fb82f39391c9ac78a55a0fc@haskell.org> References: <046.a1eae0b46fb82f39391c9ac78a55a0fc@haskell.org> Message-ID: <061.847d4de22b38fcff8db9c7d2a72be803@haskell.org> #15125: Typeclass instance selection depends on the optimisation level -------------------------------------+------------------------------------- Reporter: nicuveo | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14434 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nicuveo): Duly noted. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 9 14:10:41 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 May 2018 14:10:41 -0000 Subject: [GHC] #15135: Overlapping typeclass instance selection depends on the optimisation level Message-ID: <046.e35da1b896548effba77cf7dc5003beb@haskell.org> #15135: Overlapping typeclass instance selection depends on the optimisation level -------------------------------------+------------------------------------- Reporter: nicuveo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- A file A defines a typeclass, and gives an instance for all types a, and exports a function relying on said typeclass. A file B defines a data type, makes it a specific `OVERLAPPING` instance of that class, and uses the function defined in A. Which instance ends up being picked for B depends on the optimisation level those files are compiled with. **Minimal test case** //A.hs// {{{#!hs {-# LANGUAGE FlexibleInstances #-} {-# OPTIONS_GHC -fno-warn-simplifiable-class-constraints #-} module A where import Data.Maybe class A a where someValue :: a -> Maybe Int instance A a where someValue = const Nothing getInt :: A a => a -> Int getInt x = fromMaybe 0 $ someValue x }}} //B.hs// {{{#!hs module B where import A data B = B Int instance {-# OVERLAPPING #-} A B where someValue (B x) = Just x getBInt :: Int getBInt = getInt $ B 42 }}} //Main.hs// {{{#!hs import B main :: IO () main = putStrLn $ "B: " ++ show getBInt }}} To reproduce: {{{ $ ghc -O0 -fforce-recomp Main.hs && ./Main [1 of 3] Compiling A ( A.hs, A.o ) [2 of 3] Compiling B ( B.hs, B.o ) [3 of 3] Compiling Main ( Main.hs, Main.o ) Linking Main ... B: 42 $ ghc -O2 -fforce-recomp Main.hs && ./Main [1 of 3] Compiling A ( A.hs, A.o ) [2 of 3] Compiling B ( B.hs, B.o ) [3 of 3] Compiling Main ( Main.hs, Main.o ) Linking Main ... B: 0 }}} The fix introduced to fix ticket:14434 instructs the "short-cut solver" to not automatically choose a matching instance if it marked as `INCOHERENT` or `OVERLAPPABLE`, but in this case the instance is not marked in any way. This might be the source of the bug? Additionally, whatever the optimisation level, ghc emits a warning about the `A a =>` class constraint being simplifiable; but if it is removed, then the program prints "0" in both cases. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 9 14:27:42 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 May 2018 14:27:42 -0000 Subject: [GHC] #15132: Hadrian-built GHC cannot locate `unlit` In-Reply-To: <047.d089c6615b0cd7036d5e9baacadd7872@haskell.org> References: <047.d089c6615b0cd7036d5e9baacadd7872@haskell.org> Message-ID: <062.5c57c16491f9af1f5cffd758be34aaa1@haskell.org> #15132: Hadrian-built GHC cannot locate `unlit` ---------------------------------+---------------------------------------- Reporter: tdammers | Owner: alpmestan Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Build System | Version: Resolution: | Keywords: hadrian Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by alpmestan): * keywords: => hadrian * cc: alpmestan (added) * owner: (none) => alpmestan Comment: This is due to GHC systematically looking for unlit under libexec, not even trying to look at the directory where the `ghc` binary resides, to see whether it also has an `unlit` executable. I have a fairly simple fix for this on the hadrian side, that just places `unlit` executables under `/stage/lib/bin/unlit` instead of `/stage/bin/unlit`. Will submit a PR shortly. A better solution would be to change the code from `SysTools.hs` to do something a little smarter. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 9 14:40:44 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 May 2018 14:40:44 -0000 Subject: [GHC] #15132: Hadrian-built GHC cannot locate `unlit` In-Reply-To: <047.d089c6615b0cd7036d5e9baacadd7872@haskell.org> References: <047.d089c6615b0cd7036d5e9baacadd7872@haskell.org> Message-ID: <062.f027b6090210a7f1be35545c1bd83c04@haskell.org> #15132: Hadrian-built GHC cannot locate `unlit` ---------------------------------+---------------------------------------- Reporter: tdammers | Owner: alpmestan Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Build System | Version: Resolution: | Keywords: hadrian Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by alpmestan): Hadrian pull request [https://github.com/snowleopard/hadrian/pull/591 here]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 9 16:25:01 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 May 2018 16:25:01 -0000 Subject: [GHC] #15135: Overlapping typeclass instance selection depends on the optimisation level In-Reply-To: <046.e35da1b896548effba77cf7dc5003beb@haskell.org> References: <046.e35da1b896548effba77cf7dc5003beb@haskell.org> Message-ID: <061.5d740fa9ff24622adb7bed0bc4f0d155@haskell.org> #15135: Overlapping typeclass instance selection depends on the optimisation level -------------------------------------+------------------------------------- Reporter: nicuveo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): You are on thin ice here. In `getInt`: {{{ getInt :: A a => a -> Int getInt x = fromMaybe 0 $ someValue x }}} we have a "wanted" constraint `A a`. How can we solve it? In two ways: * From the instance * From the `A a =>` given to `getInt`. GHC chooses to solve it from the instance. But then you later overlap the instance, so that decision was arguably wrong. But the same thing would happen if you tried to infer a type for `getInt`: {{{ getInt x = fromMaybe 0 $ someValue x }}} Again, GHC will use the instance and infer {{{ getInt :: a -> Int }}} If you want to signal to GHC that the instance might be overlapped, use `{-# OVERLAPPABLE #-}`; and then you'll always get 42. I think it's arguable that an instance should only be overlappable if it says `{-# OVERLAPPABLE #-}`. But that's not our current spec. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 9 16:44:17 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 May 2018 16:44:17 -0000 Subject: [GHC] #15009: Float equalities past local equalities In-Reply-To: <047.0a49c3ac676b2b3bc6f93c4594762c08@haskell.org> References: <047.0a49c3ac676b2b3bc6f93c4594762c08@haskell.org> Message-ID: <062.e9e057c7837379e78c30b90b8c79bd47@haskell.org> #15009: Float equalities past local equalities -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.3 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I very much like 2a, especially because it has an articulable reason behind it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 9 16:59:37 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 May 2018 16:59:37 -0000 Subject: [GHC] #15131: Speed up certain Foldable NonEmpty methods In-Reply-To: <045.a14e4452f4631f3337e0e1509638b7cc@haskell.org> References: <045.a14e4452f4631f3337e0e1509638b7cc@haskell.org> Message-ID: <060.d55660e072f5d9bb443e94f3e228c5fb@haskell.org> #15131: Speed up certain Foldable NonEmpty methods -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4677 Wiki Page: | -------------------------------------+------------------------------------- Comment (by YitzGale): Replying to [comment:3 dfeuer]: > Yours has to hold on to the "and then add one" while calculating the length of the list. Are you sure GHC doesn't inline the {{{+1}}}? In any case, this is slightly better: {{{#!hs length (_ :| as) = List.foldl' (\c _ -> c+1) 1 as }}} > Same goes for `max` and `min`. Yes, and also for {{{product}}} and {{{sum}}}, but I did that purposely. I want the semantics to be the same as for {{{List}}}, which is a bit weird because it uses {{{foldl}}}. And I don't want to hard-code a copy of the {{{foldl}}} here. I want it to be fixed automatically if we every get around to fixing it for List. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 9 17:59:10 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 May 2018 17:59:10 -0000 Subject: [GHC] #13896: Use response file to invoke hsc2hs In-Reply-To: <046.8d005e1593e32147d596c190fbabb716@haskell.org> References: <046.8d005e1593e32147d596c190fbabb716@haskell.org> Message-ID: <061.3a4dd73a088a8f5a35c00e31122611a9@haskell.org> #13896: Use response file to invoke hsc2hs ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: ckoparkar Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: hsc2hs | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4612 Wiki Page: | ---------------------------------+---------------------------------------- Comment (by ckoparkar): Step 2.2: https://github.com/haskell/haddock/pull/821 Ryan Scott helped me fix the issue I was having while trying to build `haddock/ghc-head` on my local machine. I needed to pass `--allow-newer` to Cabal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 10 00:37:04 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 May 2018 00:37:04 -0000 Subject: [GHC] #15136: High CPU when asynchronous exception and unblocking retry on TVar raced Message-ID: <047.29d934aee302d96a63fcdabcdc59c0f2@haskell.org> #15136: High CPU when asynchronous exception and unblocking retry on TVar raced -------------------------------------+------------------------------------- Reporter: nshimaza | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Runtime | Version: 8.4.2 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Detail: https://github.com/nshimaza/race-tmvar-async-exception Runtime falls into high CPU under racing condition between async exception and unblocking retry on TVar. * Reproduces with +RTS -Nx where x > 1 * Does NOT reproduce with +RTS -N1 * Program stalls at `killThread` * High CPU based on given -Nx * CPU won't be 100% if you gave x smaller than available hardware threads of your platform. * Does NOT reproduce if TVar/retry is replaced by MVar * Reproduced with GHC 8.4.2 (macOS High Sierra (10.13.4)) * Reproduced with GHC 8.4.2 (Docker for Mac Version 18.03.1-ce-mac65) * Reproduced with ghc-8.5.20180506 (Docker for Mac Version 18.03.1-ce- mac65) Minimal reproducing code here. (You can find more verbose code on the above github repo.) {{{#!hs main :: IO () main = do let volume = 1000 forM_ [1..1000] $ \i -> do putStrFlush $ show i ++ " " -- Spawn massive number of threads. threads <- replicateM volume $ do trigger <- newTVarIO False tid <- forkIO $ void $ atomically $ do t <- readTVar trigger if t then pure t else retry pure (trigger, tid) -- Make sure all threads are spawned. threadDelay 30000 -- Let threads start to exit normally. forkIO $ forM_ threads $ \(trigger, _) -> threadDelay 1 *> atomically (writeTVar trigger True) -- Concurrently kill threads in order to create race. -- TMVar operation and asynchronous exception can hit same thread simultaneously. -- Adjust threadDelay if you don't reproduce very well. threadDelay 1000 forM_ threads $ \(_, tid) -> do putCharFlush 'A' killThread tid -- When the issue reproduced, this killThread doesn't return. putCharFlush '\b' }}} This program intentionally creates race condition between asynchronous exception and unblocking operation of `retry` on TVar. From one side, a `writeTVar trigger True` is attempted from external thread while target thread is blocking at `retry` on the same `TVar`. On the other side, an asynchronous exception `ThreadKilled` is thrown by yet another external thread to the same target thread. In other word, it attempts to kill a thread about to unblock. I guess when the above two operation hit the same thread at the same time in parallel in SMP environment, GHC runtime falls into high CPU. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 10 01:52:46 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 May 2018 01:52:46 -0000 Subject: [GHC] #4806: Make error message more user friendly when module is not found because package is unusable In-Reply-To: <044.33251b8e69d1b6796ddff38b98a4991e@haskell.org> References: <044.33251b8e69d1b6796ddff38b98a4991e@haskell.org> Message-ID: <059.c137460fe07d3192a91a63f5bc48a479@haskell.org> #4806: Make error message more user friendly when module is not found because package is unusable -------------------------------------+------------------------------------- Reporter: mitar | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgillespie): I can seem to reproduce the issue by running {{{ cabal sandbox init cabal install MonadRandom cabal exec -- ghc-pkg unregister --force fail cabal repl }}} Then import anything from the now-unusable package {{{ Prelude> :m + Control.Monad.Random : error: Could not find module ‘Control.Monad.Random’ Perhaps you meant Control.Monad.Reader (from mtl-2.2.2) Control.Monad.Cont (from mtl-2.2.2) Control.Monad.Error (from mtl-2.2.2) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 10 04:00:40 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 May 2018 04:00:40 -0000 Subject: [GHC] #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) In-Reply-To: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> References: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> Message-ID: <057.77085b1bf43675337cd50757b37b2d23@haskell.org> #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 (CodeGen) | Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: T13658 at runtime | T14779a T14779b T14868 debug | parsing001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4654 Wiki Page: | -------------------------------------+------------------------------------- Comment (by abarbu): Please prioritize a GHC-8.4.3. We just upgraded our machines and builds are failing because of this. When devs tell the community to wait 6+ months to fix a fatal error on a supported platform, and that the fix will be bundled with many other changes forcing a major upgrade, it really undercuts the argument that we should be relying on Haskell or GHC for anything. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 10 04:52:11 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 May 2018 04:52:11 -0000 Subject: [GHC] #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) In-Reply-To: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> References: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> Message-ID: <057.eb09f042c8740b520d2fe604800596b8@haskell.org> #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.4.3 Component: Compiler | Version: 8.4.1 (CodeGen) | Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: T13658 at runtime | T14779a T14779b T14868 debug | parsing001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4654 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: closed => merge * milestone: 8.6.1 => 8.4.3 Comment: Can those who are affected by this issue confirm that they are building with debug information enabled (`ghc -g`)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 10 08:05:51 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 May 2018 08:05:51 -0000 Subject: [GHC] #15038: Memory Corruption (strange closure type) In-Reply-To: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> References: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> Message-ID: <064.bca1eacbe1e74d53f9a8c2e2375a702c@haskell.org> #15038: Memory Corruption (strange closure type) -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.4.3 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #9718 | Differential Rev(s): Phab:D4680 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * milestone: 8.6.1 => 8.4.3 Comment: It seems like we'll be making another 8.4 release (for #15068), we should probably include the fix for this as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 10 08:53:55 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 May 2018 08:53:55 -0000 Subject: [GHC] #15038: Memory Corruption (strange closure type) In-Reply-To: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> References: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> Message-ID: <064.8969d65037e28dc60f119d9443d673c0@haskell.org> #15038: Memory Corruption (strange closure type) -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.4.3 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #9718 | Differential Rev(s): Phab:D4680 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ömer Sinan Ağacan ): In [changeset:"b2ff5dde399cd012218578945ada1d9ff68daa35/ghc" b2ff5dde/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b2ff5dde399cd012218578945ada1d9ff68daa35" Fix #15038 We introduce a new Id for unused pointer values in unboxed sums that is not CAFFY. Because the Id is not CAFFY it doesn't make non-CAFFY definitions CAFFY, fixing #15038. To make sure anything referenced by the new id will be retained we get a stable pointer to in on RTS startup. Test Plan: Passes validate Reviewers: simonmar, simonpj, hvr, bgamari, erikd Reviewed By: simonmar Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15038 Differential Revision: https://phabricator.haskell.org/D4680 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 10 08:55:09 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 May 2018 08:55:09 -0000 Subject: [GHC] #15038: Memory Corruption (strange closure type) In-Reply-To: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> References: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> Message-ID: <064.eb22274ce58ea10d685cefeb4368837d@haskell.org> #15038: Memory Corruption (strange closure type) -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.4.3 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #9718 | Differential Rev(s): Phab:D4680 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 10 08:57:15 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 May 2018 08:57:15 -0000 Subject: [GHC] #15137: Install primitive on CI before running tests Message-ID: <043.133b68846e07c2a28062d962181dcdcc@haskell.org> #15137: Install primitive on CI before running tests -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 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: -------------------------------------+------------------------------------- #15038 added a regression test that requires primitive package. Because the package is not installed by validate script it won't run on CI. We should probably update validate script to install it before running the test suite. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 10 08:57:34 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 May 2018 08:57:34 -0000 Subject: [GHC] #15137: Install the "primitive" package on CI before running tests (was: Install primitive on CI before running tests) In-Reply-To: <043.133b68846e07c2a28062d962181dcdcc@haskell.org> References: <043.133b68846e07c2a28062d962181dcdcc@haskell.org> Message-ID: <058.c2cec06f5fe360afa5cdbec4ebe2f2d6@haskell.org> #15137: Install the "primitive" package on CI before running tests -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 10 09:30:59 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 May 2018 09:30:59 -0000 Subject: [GHC] #15138: Unable to instantiate data members of kind Nat in backpack signatures. Message-ID: <042.e290873b59fcee0c98fbf371f48d1238@haskell.org> #15138: Unable to instantiate data members of kind Nat in backpack signatures. -------------------------------------+------------------------------------- Reporter: ppk | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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 in context with backpack signatures and their instantiation with concrete implementation. Consider the signature `Abstract` which contains a data `NatType` of kind `Nat`. {{{#!hs {- skipped relevant language extensions -} signature Abstract where import GHC.TypeLits data NatType :: Nat -- comment this out }}} Concrete implementations are unable to instantiate this abstract class during linking {{{#!hs module Concrete where type NatType = 42 }}} This is neither working with explicit .bkp files nor actual cabal package. I have isolated a minimum example into a repository [[https://github.com /piyush-kurur/backpack-nat| a cabal packages]] as well as a [[https://github.com/piyush-kurur/backpack-nat/blob/master/as-bkpfiles /backpack-nat.bkp|single bkp file]]. The urls above also have the associated ghc log messages. The version of ghc I have tested with is 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 10 10:39:50 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 May 2018 10:39:50 -0000 Subject: [GHC] #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) In-Reply-To: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> References: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> Message-ID: <057.324933e929757c0cc92a5550865b8766@haskell.org> #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.4.3 Component: Compiler | Version: 8.4.1 (CodeGen) | Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: T13658 at runtime | T14779a T14779b T14868 debug | parsing001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4654 Wiki Page: | -------------------------------------+------------------------------------- Comment (by recursion-ninja): Yes, I was building with `ghc -g` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 10 11:06:32 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 May 2018 11:06:32 -0000 Subject: [GHC] #15038: Memory Corruption (strange closure type) In-Reply-To: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> References: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> Message-ID: <064.9b576aecd27a7edaa0c3202f9b4aa989@haskell.org> #15038: Memory Corruption (strange closure type) -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.4.3 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #9718 | Differential Rev(s): Phab:D4680 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Just to note that the patch in comment:36 should be reverted when we implement #9718. Or at least revisited to make the treatment of error-ids uniform with each other. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 10 11:08:04 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 May 2018 11:08:04 -0000 Subject: [GHC] #9718: Avoid TidyPgm predicting what CorePrep will do In-Reply-To: <046.5eef205a104808a079ad54238c650906@haskell.org> References: <046.5eef205a104808a079ad54238c650906@haskell.org> Message-ID: <061.c9b331b1e0b97d1d9595b1d0abec726c@haskell.org> #9718: Avoid TidyPgm predicting what CorePrep will do -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: CodeGen, CAFs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): When we fix this, let's revisit the patch in comment:36 of #15038. It implements a very special case for one error-id, solely because that error-id is introduced after the CAF computation has been done in !TidyCore. When we fix this ticket, #9718, we can remove the special case and treat all error-ids uniformly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 10 11:12:00 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 May 2018 11:12:00 -0000 Subject: [GHC] #15038: Memory Corruption (strange closure type) In-Reply-To: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> References: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> Message-ID: <064.a6f9484b705e3dbbaaeeb55dbe87cbf3@haskell.org> #15038: Memory Corruption (strange closure type) -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.4.3 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #9718 | Differential Rev(s): Phab:D4680 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Also to note: Omer tried the approach in comment:33, but we found that binary sizes went up by 1%. Comment:33 means that we'd link the code for all error-ids into every binary even if they are not actually used; but it seems hard to believe that would increase code size by 1%. Rather than pursue this mystery, we backed off and did the ad-hoc special case implemented in comment:36. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 10 11:59:30 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 May 2018 11:59:30 -0000 Subject: [GHC] #14444: Linker limit on OS X Sierra breaks builds for big projects In-Reply-To: <049.ef1cbd3eecd105a31deac573ded19c35@haskell.org> References: <049.ef1cbd3eecd105a31deac573ded19c35@haskell.org> Message-ID: <064.86a53b3f6519d356064cfe63be296d69@haskell.org> #14444: Linker limit on OS X Sierra breaks builds for big projects -------------------------------------+------------------------------------- Reporter: dredozubov | Owner: angerman Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Linking) | Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gelisam): > I tried it with a few work projects and it still fails for some of them, which is very frustrating. Note that the script alters the way in which dylibs are ''created'', not the way in which they are linked. As a consequence, you may have to delete your existing dylib files, otherwise your build tool may choose to keep your old broken dylib files instead of re-creating them using our wrapper script. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 10 12:14:09 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 May 2018 12:14:09 -0000 Subject: [GHC] #14251: LLVM Code Gen messes up registers In-Reply-To: <047.9ece2514d7c7f668525c93ec15fb841a@haskell.org> References: <047.9ece2514d7c7f668525c93ec15fb841a@haskell.org> Message-ID: <062.74e1e659047c95b0179f539a9a5deb6a@haskell.org> #14251: LLVM Code Gen messes up registers -------------------------------------+------------------------------------- Reporter: angerman | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Compiler (LLVM) | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mbw): Does this imply that using the llvm backend is currently a no-no? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 10 12:53:52 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 May 2018 12:53:52 -0000 Subject: [GHC] #15038: Memory Corruption (strange closure type) In-Reply-To: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> References: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> Message-ID: <064.4a457e1829edd00c760d4c6299c3acac@haskell.org> #15038: Memory Corruption (strange closure type) -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.4.3 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #9718 | Differential Rev(s): Phab:D4680 Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): Should I now be able to try building my original repository (`packed`) with GHC HEAD? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 10 14:26:16 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 May 2018 14:26:16 -0000 Subject: [GHC] #15038: Memory Corruption (strange closure type) In-Reply-To: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> References: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> Message-ID: <064.db330ab8370b56bf85263d04945f66f4@haskell.org> #15038: Memory Corruption (strange closure type) -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.4.3 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #9718 | Differential Rev(s): Phab:D4680 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): That'd be great. I tried your reproducer (`correupted-memory-example`) but not the original package. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 10 16:33:08 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 May 2018 16:33:08 -0000 Subject: [GHC] #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) In-Reply-To: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> References: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> Message-ID: <057.a6fde408978d4717c404da55074e547e@haskell.org> #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.4.3 Component: Compiler | Version: 8.4.1 (CodeGen) | Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: T13658 at runtime | T14779a T14779b T14868 debug | parsing001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4654 Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): It's worth pointing out that this would mostly be experienced with Stack's somewhat questionable defaults. It should be rather easy to fix this on Stack's side by detecting system configurations which are known to be incompatible and avoid passing `-g` to GHC by default. For those that are blocked on this, I'd recommend either giving `cabal new-build` a try or using Stack w/ the GHC 8.4.2 (`ghc-8.4.2 8.4.2-8~18.04`) or GHC 8.2.2 (`ghc-8.2.2 8.2.2-4~18.04`) packages for Ubuntu 18.04 LTS from my Ubuntu PPA which don't suffer from this issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 10 16:59:56 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 May 2018 16:59:56 -0000 Subject: [GHC] #15139: EmptyCase produces incorrect SrcSpans Message-ID: <050.786ae7468713016c9bdf7df625aed35f@haskell.org> #15139: EmptyCase produces incorrect SrcSpans -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If you compile the following program, you'll get a warning for `f` with an improperly placed `SrcSpan`: {{{#!hs {-# LANGUAGE EmptyCase #-} {-# LANGUAGE TypeOperators #-} {-# OPTIONS_GHC -Wincomplete-patterns #-} module Bug where import Data.Type.Equality can'tHappen :: Int :~: Bool can'tHappen = undefined f, g :: Bool -> Bool f True = case can'tHappen of {} g True = case () of () -> True }}} {{{ $ /opt/ghc/8.4.2/bin/ghci Bug.hs GHCi, version 8.4.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:12:1: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In an equation for ‘f’: Patterns not matched: False | 12 | f True = case can'tHappen of {} | ^^^^^^^^^^^^^ Bug.hs:13:1: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In an equation for ‘g’: Patterns not matched: False | 13 | g True = case () of () -> True | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Ok, one module loaded. }}} Compare that to the warning for `g`, whose `SrcSpan` spans the entire clause, as expected. The bug lies in the parser—patch incoming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 10 17:05:19 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 May 2018 17:05:19 -0000 Subject: [GHC] #15139: EmptyCase produces incorrect SrcSpans In-Reply-To: <050.786ae7468713016c9bdf7df625aed35f@haskell.org> References: <050.786ae7468713016c9bdf7df625aed35f@haskell.org> Message-ID: <065.bb344e973eb90d6bd15c7c16fc00ee3d@haskell.org> #15139: EmptyCase produces incorrect SrcSpans -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4685 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D4685 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 10 18:00:53 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 May 2018 18:00:53 -0000 Subject: [GHC] #15140: GHC 8.4.2 installation crash with Stack Message-ID: <046.5c4e1ae0dfa78e4df619c5255b5c09d4@haskell.org> #15140: GHC 8.4.2 installation crash with Stack -------------------------------------+------------------------------------- Reporter: fpanahi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Build System | Version: 8.4.2 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: Installing GHC | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I got this problem while installing GHC 8.4.2 with the "stack install" command. I had successfully installed Stack and cloned https://github.com/haskell/haskell-ide-engine beforehand. The OS is Windows 10 (64b). The error message is on the screen copy herein attached. It is already such a long and difficult process to install Haskell, compared to similar PL ... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 10 18:07:30 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 May 2018 18:07:30 -0000 Subject: [GHC] #15140: GHC 8.4.2 installation crash with Stack In-Reply-To: <046.5c4e1ae0dfa78e4df619c5255b5c09d4@haskell.org> References: <046.5c4e1ae0dfa78e4df619c5255b5c09d4@haskell.org> Message-ID: <061.cec8e74cd773eb461b1ebf4b960f85c3@haskell.org> #15140: GHC 8.4.2 installation crash with Stack ------------------------------------------+------------------------------ Reporter: fpanahi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Build System | Version: 8.4.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Installing GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------------+------------------------------ Changes (by fpanahi): * Attachment "HaskellInstallCrash.pdf" added. Screen copy of the message error -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 10 18:09:57 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 May 2018 18:09:57 -0000 Subject: [GHC] #15140: GHC 8.4.2 installation crash with Stack In-Reply-To: <046.5c4e1ae0dfa78e4df619c5255b5c09d4@haskell.org> References: <046.5c4e1ae0dfa78e4df619c5255b5c09d4@haskell.org> Message-ID: <061.7775572c1812d333acc38a600ffba6b0@haskell.org> #15140: GHC 8.4.2 installation crash with Stack ------------------------------------------+------------------------------ Reporter: fpanahi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Build System | Version: 8.4.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Installing GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------------+------------------------------ Comment (by fpanahi): Here is the error message: package directory (directory-1.3.1.5-J5MwWdrFyEn9y6RDLELiL1) requires time-1.8.0.2-D1fwd9ZaD3eDd2StmPCsSC Preprocessing library for ghc-exactprint-0.5.6.1.. Building library for ghc-exactprint-0.5.6.1.. [ 1 of 13] Compiling Language.Haskell.GHC.ExactPrint.Types ( src\Language\Haskell\GHC\ExactPrint\Types.hs, .stack- work\dist\7d103d30\build\Language\Haskell\GHC\ExactPrint\Types.o ) [ 2 of 13] Compiling Language.Haskell.GHC.ExactPrint.Lookup ( src\Language\Haskell\GHC\ExactPrint\Lookup.hs, .stack- work\dist\7d103d30\build\Language\Haskell\GHC\ExactPrint\Lookup.o ) [ 3 of 13] Compiling Language.Haskell.GHC.ExactPrint.AnnotateTypes ( src\Language\Haskell\GHC\ExactPrint\AnnotateTypes.hs, .stack- work\dist\7d103d30\build\Language\Haskell\GHC\ExactPrint\AnnotateTypes.o ) GHC runtime linker: fatal error: I found a duplicate definition for symbol rgb whilst processing object file C:\Users\Farhad\AppData\Local\Programs\stack\x86_64-windows\ghc-8.4.2\lib\Win32-2.6.1.0\HSWin32-2.6.1.0.o The symbol was previously defined in C:\sr\snapshots\03fa9465\lib\x86_64-windows- ghc-8.4.2\Win32-2.5.4.1-LVNqK0SwW285hUwHpPOkae\HSWin32-2.5.4.1-LVNqK0SwW285hUwHpPOkae.o This could be caused by: * Loading two different object files which export the same symbol * Specifying the same object file twice on the GHCi command line * An incorrect `package.conf' entry, causing some object to be loaded twice. ghc.EXE: panic! (the 'impossible' happened) (GHC version 8.4.2 for x86_64-unknown-mingw32): loadObj "C:\\Users\\Farhad\\AppData\\Local\\Programs\\stack\\x86_64-windows\\ghc-8.4.2\\lib\\Win32-2.6.1.0\\HSWin32-2.6.1.0.o": failed Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug c:\hie> -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 10 18:14:16 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 May 2018 18:14:16 -0000 Subject: [GHC] #15140: GHC 8.4.2 installation crash with Stack In-Reply-To: <046.5c4e1ae0dfa78e4df619c5255b5c09d4@haskell.org> References: <046.5c4e1ae0dfa78e4df619c5255b5c09d4@haskell.org> Message-ID: <061.29badd4375e419dc9cd8a2f1e1e85c34@haskell.org> #15140: GHC 8.4.2 installation crash with Stack ------------------------------------------+------------------------------ Reporter: fpanahi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Build System | Version: 8.4.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Installing GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------------+------------------------------ Comment (by fpanahi): Can I at least roll back and re-install? I appreciate your help; I am an amateur, with a job that is not related to Haskell, so no much time to browse the litterature. Thanks -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 10 19:23:20 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 May 2018 19:23:20 -0000 Subject: [GHC] #15140: GHC 8.4.2 installation crash with Stack In-Reply-To: <046.5c4e1ae0dfa78e4df619c5255b5c09d4@haskell.org> References: <046.5c4e1ae0dfa78e4df619c5255b5c09d4@haskell.org> Message-ID: <061.5a1fb80695eaf01096485034f14facd6@haskell.org> #15140: GHC 8.4.2 installation crash with Stack ------------------------------------------+------------------------------ Reporter: fpanahi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Build System | Version: 8.4.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Installing GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------------+------------------------------ Comment (by hvr): Despite GHC suggesting to file this as a GHC bug, I'd suggest trying to report this to https://github.com/commercialhaskell/stack/issues Alternatively, I'd ask you to try to reproduce this without the use of Stack and let us know if the issue still occurs then. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 10 20:42:33 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 May 2018 20:42:33 -0000 Subject: [GHC] #15131: Speed up certain Foldable NonEmpty methods In-Reply-To: <045.a14e4452f4631f3337e0e1509638b7cc@haskell.org> References: <045.a14e4452f4631f3337e0e1509638b7cc@haskell.org> Message-ID: <060.5edec75f964f4fb8b185b5a764b54b9f@haskell.org> #15131: Speed up certain Foldable NonEmpty methods -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4677 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): GHC isn't clever enough to reassociate a recursively calculated sum, no. The `foldl'` definition you give ends up looking just the same as the default. As for `sum`, etc., I don't really think we should write worse code today because maybe some year the definition for lists will improve while the default definition doesn't. You can push for those changes separately, and in due course we can adjust this instance again if necessary. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 10 21:56:08 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 May 2018 21:56:08 -0000 Subject: [GHC] #15140: GHC 8.4.2 installation crash with Stack In-Reply-To: <046.5c4e1ae0dfa78e4df619c5255b5c09d4@haskell.org> References: <046.5c4e1ae0dfa78e4df619c5255b5c09d4@haskell.org> Message-ID: <061.f2f5b41893c59ed3224974dee9d9b82f@haskell.org> #15140: GHC 8.4.2 installation crash with Stack ------------------------------------------+------------------------------ Reporter: fpanahi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Build System | Version: 8.4.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Installing GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------------+------------------------------ Comment (by fpanahi): I reported to https://github.com/commercialhaskell/stack/issues, issue #4020. Sorry, I am new in Haskell, and don't know how to do it without Stack. Do I need to rollback in some way? Thanks for your help. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 11 08:16:24 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 May 2018 08:16:24 -0000 Subject: [GHC] #15132: Hadrian-built GHC cannot locate `unlit` In-Reply-To: <047.d089c6615b0cd7036d5e9baacadd7872@haskell.org> References: <047.d089c6615b0cd7036d5e9baacadd7872@haskell.org> Message-ID: <062.ed81d49ecc5adbc9c5287e6b06dfdf88@haskell.org> #15132: Hadrian-built GHC cannot locate `unlit` ---------------------------------+---------------------------------------- Reporter: tdammers | Owner: alpmestan Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Build System | Version: Resolution: fixed | Keywords: hadrian Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by alpmestan): * status: new => closed * resolution: => fixed Comment: The pull request has been merged. Hadrian now produces GHCs that can successfully process `.lhs` files. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 11 11:40:03 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 May 2018 11:40:03 -0000 Subject: [GHC] #15101: $tooldir not expanded for NoFib In-Reply-To: <047.4f2835072dd91dcbeeff182bdae28e75@haskell.org> References: <047.4f2835072dd91dcbeeff182bdae28e75@haskell.org> Message-ID: <062.4a6881f0e893640ceb576a243d848d1d@haskell.org> #15101: $tooldir not expanded for NoFib -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: alpmestan Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: NoFib benchmark | Version: suite | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4667 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alpmestan): * status: new => patch * differential: => Phab:D4667 Comment: Phyx wrote a first patch that fixes this without `unsafePerformIO` at [https://phabricator.haskell.org/D4667 D4667], but I have one that should fix the problem without `unsafePerformIO`, which might be desirable. See [https://phabricator.haskell.org/D4686 D4686]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 11 13:06:18 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 May 2018 13:06:18 -0000 Subject: [GHC] #15140: GHC 8.4.2 installation crash with Stack In-Reply-To: <046.5c4e1ae0dfa78e4df619c5255b5c09d4@haskell.org> References: <046.5c4e1ae0dfa78e4df619c5255b5c09d4@haskell.org> Message-ID: <061.1ce7d3121c2dc2881ff55601227cfc46@haskell.org> #15140: GHC 8.4.2 installation crash with Stack ------------------------------------------+------------------------------ Reporter: fpanahi | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Build System | Version: 8.4.2 Resolution: invalid | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Installing GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------------+------------------------------ Changes (by Phyx-): * status: new => closed * resolution: => invalid Comment: Right, this is indeed not a GHC bug. Stack's resolver has decided to link both `Win32` versions `2.5.4.1` and `2.6.1.0` together at the same time. For stack advice it's best to ask on their issue tracker as you have. Alternatively is using the Haskell Platform and using `cabal`. I've closed the ticket as this isn't a linker bug, re-open it if you believe it is. (You can still comment with it closed.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 11 14:03:52 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 May 2018 14:03:52 -0000 Subject: [GHC] #15038: Memory Corruption (strange closure type) In-Reply-To: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> References: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> Message-ID: <064.2ff56c703ee02d67b3953df94704f05a@haskell.org> #15038: Memory Corruption (strange closure type) -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.4.3 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #9718 | Differential Rev(s): Phab:D4680 Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): I just confirmed that my original library no longer crashes when built with GHC head. If it is possible to release this fix with GHC 8.4.3, I would greatly appreciate it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 11 14:34:35 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 May 2018 14:34:35 -0000 Subject: [GHC] #14068: Loopification using join points In-Reply-To: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> References: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> Message-ID: <061.c2b5f6bf2f99dc7bfd798b9e52492178@haskell.org> #14068: Loopification using join points -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13966 #14067 | Differential Rev(s): Phab:D3811 #14827 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Status update for those who understandably don’t want to read the whole thread: There is working code for loopification on `wip/T14068`. If one disables !SpecConstr and compares this branch to master, then there is only one allocation regression (in `queens`, not investigated). However, with !SpecConstr (i.e. the default), many nofib tests regress. I have paused working on loopification until we have improved SpecConstr to yield equivalently good results for the loopified code. Relevant tickets are #14844 (!SpecConstr should also apply to top-level non- recursive bindings) and #14951 (!SpecConstr is not idempotent; in other words: a stack of deeply nested functions do not get specialized in one go). If these were fixed we would get rid of some of the !SpecConstr related regressions introduced by loopification – but still not all of them, I fear, and there will be more to be tracked down. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 11 15:54:08 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 May 2018 15:54:08 -0000 Subject: [GHC] #15141: decideKindGeneralisationPlan is too complicated Message-ID: <046.4f6050513c6b4233d9cf0aed569bb12a@haskell.org> #15141: decideKindGeneralisationPlan is too complicated -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Consider this program, which originally comes from #14846. I have decorated it with kind signatures so you can see what is going on {{{ {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE EmptyCase #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE InstanceSigs #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeInType #-} module T14846 where import Data.Kind import Data.Proxy -- Cat :: * -> * type Cat ob = ob -> ob -> Type -- Struct :: forall k. (k -> Constraint) -> * data Struct :: (k -> Constraint) -> Type where S :: Proxy (a::k) -> Struct (cls::k -> Constraint) -- Structured :: forall k -- forall (a:k) (cls:k->Constraint) -> Struct k cls type Structured a cls = (S ('Proxy :: Proxy a) :: Struct cls) -- AStruct :: forall k (cls : k->Constraint). Struct cls -> Type data AStruct :: Struct cls -> Type where AStruct :: cls a => AStruct (Structured a cls) -- StructI :: forall k1 k2 (cls :: k2 -> Constraint). -- k1 -> Struct k2 cls -> Constraint class StructI xx (structured::Struct (cls :: k -> Constraint)) where struct :: AStruct structured -- Hom :: forall k1 k2 (cls :: k2 -> Constraint). -- Cat k1 -> Cat (Struct {k2} cls) data Hom :: Cat k -> Cat (Struct cls) where -- Category :: forall ob. Cat ob -> Constraint class Category (cat::Cat ob) where i :: StructI xx a => ríki a a instance forall (riki :: Cat kx) (cls :: kk -> Constraint). Category riki => Category (Hom riki :: Cat (Struct cls)) where i :: forall xx a. StructI xx a => Hom riki a a i = case struct :: AStruct (Structured a cls) of }}} Focus on the final instance declaration. Do kind inference on the type signature for `i`. I think we should get {{{ i :: forall {k1} {k2} {cls1 :: k2 -> Constraint} forall (xx :: k1) (a :: Struct {k2} cls1). StructI {k1} {k2} xx a => Hom {kx} {k2} riki a a }}} Nothing about `i`'s type signature constraints the `cls` to be the same as the in-scope `cls`. Yes `riki` is in scope, but its kind is unrelated. But at present GHC does not kind-generalise `i`'s type (because of `kindGeneralisationPlan`), so random things in the body of `i` may influence how its kinds get fixed. And if we changed the signature a bit so that it didn't mention `riki` any more, suddenly it ''would'' be kind-generalised. This seems incomprehensibly complicated to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 11 16:03:03 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 May 2018 16:03:03 -0000 Subject: [GHC] #15141: decideKindGeneralisationPlan is too complicated In-Reply-To: <046.4f6050513c6b4233d9cf0aed569bb12a@haskell.org> References: <046.4f6050513c6b4233d9cf0aed569bb12a@haskell.org> Message-ID: <061.89d44d4f621f754f619130d8f4be25db@haskell.org> #15141: decideKindGeneralisationPlan is too complicated -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > Consider this program, which originally comes from #14846. I have > decorated it with kind signatures so you can see what is going on > {{{ > {-# LANGUAGE AllowAmbiguousTypes #-} > {-# LANGUAGE ConstraintKinds #-} > {-# LANGUAGE EmptyCase #-} > {-# LANGUAGE FlexibleInstances #-} > {-# LANGUAGE GADTs #-} > {-# LANGUAGE InstanceSigs #-} > {-# LANGUAGE MultiParamTypeClasses #-} > {-# LANGUAGE ScopedTypeVariables #-} > {-# LANGUAGE TypeInType #-} > module T14846 where > > import Data.Kind > import Data.Proxy > > -- Cat :: * -> * > type Cat ob = ob -> ob -> Type > > -- Struct :: forall k. (k -> Constraint) -> * > data Struct :: (k -> Constraint) -> Type where > S :: Proxy (a::k) -> Struct (cls::k -> Constraint) > > -- Structured :: forall k > -- forall (a:k) (cls:k->Constraint) -> Struct k cls > type Structured a cls = (S ('Proxy :: Proxy a) :: Struct cls) > > -- AStruct :: forall k (cls : k->Constraint). Struct cls -> Type > data AStruct :: Struct cls -> Type where > AStruct :: cls a => AStruct (Structured a cls) > > -- StructI :: forall k1 k2 (cls :: k2 -> Constraint). > -- k1 -> Struct k2 cls -> Constraint > class StructI xx (structured::Struct (cls :: k -> Constraint)) where > struct :: AStruct structured > > -- Hom :: forall k1 k2 (cls :: k2 -> Constraint). > -- Cat k1 -> Cat (Struct {k2} cls) > data Hom :: Cat k -> Cat (Struct cls) where > > -- Category :: forall ob. Cat ob -> Constraint > class Category (cat::Cat ob) where > i :: StructI xx a => ríki a a > > instance forall (riki :: Cat kx) > (cls :: kk -> Constraint). > Category riki => Category (Hom riki :: Cat (Struct cls)) where > i :: forall xx a. StructI xx a => Hom riki a a > i = case struct :: AStruct (Structured a cls) of > }}} > Focus on the final instance declaration. Do kind inference on the type > signature for `i`. > I think we should get > {{{ > i :: forall {k1} {k2} {cls1 :: k2 -> Constraint} > forall (xx :: k1) (a :: Struct {k2} cls1). > StructI {k1} {k2} xx a => Hom {kx} {k2} riki a a > }}} > Nothing about `i`'s type signature constraints the `cls` to be the same > as the > in-scope `cls`. Yes `riki` is in scope, but its kind is unrelated. > > But at present GHC does not kind-generalise `i`'s type (because of > `kindGeneralisationPlan`), > so random things in the body of `i` may influence how its kinds get > fixed. And if we changed > the signature a bit so that it didn't mention `riki` any more, suddenly > it ''would'' be kind-generalised. > > This seems incomprehensibly complicated to me. New description: Consider this program, which originally comes from #14846. I have decorated it with kind signatures so you can see what is going on {{{ {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE EmptyCase #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE InstanceSigs #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeInType #-} module T14846 where import Data.Kind import Data.Proxy -- Cat :: * -> * type Cat ob = ob -> ob -> Type -- Struct :: forall k. (k -> Constraint) -> * data Struct :: (k -> Constraint) -> Type where S :: Proxy (a::k) -> Struct (cls::k -> Constraint) -- Structured :: forall k -- forall (a:k) (cls:k->Constraint) -> Struct k cls type Structured a cls = (S ('Proxy :: Proxy a) :: Struct cls) -- AStruct :: forall k (cls : k->Constraint). Struct cls -> Type data AStruct :: Struct cls -> Type where AStruct :: cls a => AStruct (Structured a cls) -- StructI :: forall k1 k2 (cls :: k2 -> Constraint). -- k1 -> Struct k2 cls -> Constraint class StructI xx (structured::Struct (cls :: k -> Constraint)) where struct :: AStruct structured -- Hom :: forall k1 k2 (cls :: k2 -> Constraint). -- Cat k1 -> Cat (Struct {k2} cls) data Hom :: Cat k -> Cat (Struct cls) where -- Category :: forall ob. Cat ob -> Constraint class Category (cat::Cat ob) where i :: StructI xx a => ríki a a instance forall (riki :: Cat kx) (cls :: kk -> Constraint). Category riki => Category (Hom riki :: Cat (Struct cls)) where i :: forall xx a. StructI xx a => Hom riki a a i = case struct :: AStruct (Structured a cls) of }}} Focus on the final instance declaration. Do kind inference on the type signature for `i`. I think we should get {{{ i :: forall {k1} {k2} {cls1 :: k2 -> Constraint} forall (xx :: k1) (a :: Struct {k2} cls1). StructI {k1} {k2} xx a => Hom {kx} {k2} riki a a }}} Nothing about `i`'s type signature constraints the `cls` to be the same as the in-scope `cls`. Yes `riki` is in scope, but its kind is unrelated. But at present GHC does not kind-generalise `i`'s type (because of `kindGeneralisationPlan`), so random things in the body of `i` may influence how its kinds get fixed. And if we changed the signature a bit so that it didn't mention `riki` any more, suddenly it ''would'' be kind-generalised. This seems incomprehensibly complicated to me. Moreover, the type of `i` from the ''class'' decl: {{{ class Category (cat::Cat ob) where i :: StructI xx a => ríki a a }}} comes out in its full glory as {{{ i :: forall k1 k2 (cls :: k2 -> Constraint) (xx :: k1) (a :: Struct {k2} cls) (riki :: Cat (Struct {k2} cls). StructI {k1} {k2} cls xx a => riki a a }}} So indeed `i` is expected to be as polymorphic as I expected, and the unexpected lack of generalisation gives rise (in HEAD) to a bogus error: {{{ T14846.hs:51:8: error: • Couldn't match type ‘ríki’ with ‘Hom kx k1 cls0 riki’ ‘ríki’ is a rigid type variable bound by the type signature for: i :: forall k (cls1 :: k -> Constraint) k3 (xx :: k3) (a :: Struct k cls1) (ríki :: Struct k cls1 -> Struct k cls1 -> *). StructI k3 k cls1 xx a => ríki a a at T14846.hs:51:8-51 Expected type: ríki a a Actual type: Hom kx k1 cls0 riki a0 a0 • When checking that instance signature for ‘i’ is more general than its signature in the class Instance sig: forall (xx :: k0) (a :: Struct k1 cls0). StructI k0 k1 cls0 xx a => Hom kx k1 cls0 riki a a Class sig: forall k1 (cls :: k1 -> Constraint) k2 (xx :: k2) (a :: Struct k1 cls) (ríki :: Struct k1 cls -> Struct k1 cls -> *). StructI k2 k1 cls xx a => ríki a a In the instance declaration for ‘Category {Struct kk cls} (Hom kx kk cls riki)’ }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 11 16:28:47 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 May 2018 16:28:47 -0000 Subject: [GHC] #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) In-Reply-To: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> References: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> Message-ID: <057.109158fe5a29b8a121e2ae274aaa9950@haskell.org> #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 (CodeGen) | Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: T13658 at runtime | T14779a T14779b T14868 debug | parsing001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4654 Wiki Page: | -------------------------------------+------------------------------------- Changes (by recursion-ninja): * milestone: 8.4.3 => 8.6.1 Comment: I ran the following on my Ubuntu 18.04 installation to install the `gcc-8.1` which resolved the issue. {{{ $ add-apt-repository ppa:ubuntu-toolchain-r/test -y $ apt-get install gcc-snapshot -y $ apt-get install gcc-8 g++-8 -y $ update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-8 60 --slave /usr/bin/g++ g++ /usr/bin/g++-8 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 11 16:49:31 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 May 2018 16:49:31 -0000 Subject: [GHC] #15133: Make `nofib` work with Hadrian In-Reply-To: <047.3debb5e25137f26bba1d26ebffe5dbd6@haskell.org> References: <047.3debb5e25137f26bba1d26ebffe5dbd6@haskell.org> Message-ID: <062.63b63817082eba52c57794badf774cac@haskell.org> #15133: Make `nofib` work with Hadrian -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: NoFib benchmark | Version: suite | Resolution: | Keywords: hadrian Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alpmestan): * cc: tdammers, alpmestan (added) * keywords: => hadrian Comment: I got nofib to boot (with the hadrian-built GHC) and start running the programs. {{{#!sh # I need to set PERL because I'm on NixOS and by default nofib expects # perl to live at /usr/bin/perl. Most people should only have to set # WithNofibHc. # # This assumes a build root living at the source of the ghc tree, under # _build/. $ make WithNofibHc=/path/to/ghc/_build/stage1/bin/ghc PERL=$(which perl) boot $ make WithNofibHc=/path/to/ghc/_build/stage1/bin/ghc PERL=$(which perl) 2>&1 | tee nofib-log }}} But after successfully building/running several programs, it errors out on `kahan` with: {{{#!sh ------------------------------------------------------------------------ == make all --no-print-directory; in /home/alp/ghc-hadrian/nofib/imaginary/kahan ------------------------------------------------------------------------ HC = /home/alp/ghc-hadrian/_build/stage1/bin/ghc HC_OPTS = -O2 -Rghc-timing -H32m -hisuf hi -package array -rtsopts RUNTEST_OPTS = -ghc-timing ==nofib== kahan: time to compile Main follows... /home/alp/ghc-hadrian/_build/stage1/bin/ghc -O2 -Rghc-timing -H32m -hisuf hi -package array -rtsopts -c Main.hs -o Main.o <> ==nofib== kahan: size of Main.o follows... text data bss dec hex filename 6231 928 0 7159 1bf7 Main.o ==nofib== kahan: time to link kahan follows... <> ==nofib== kahan: size of kahan follows... text data bss dec hex filename 5195892 1780304 19280 6995476 6abe14 kahan ==nofib== kahan: time to run kahan follows... ../../runstdtest/runstdtest ./kahan -o1 kahan.stdout-x86-linux -o1 kahan.stdout -o1 kahan.stdout-x86-linux -o1 kahan.stdout -ghc-timing 250000; ../../runstdtest/runstdtest ./kahan -o1 kahan.stdout-x86-linux -o1 kahan.stdout -o1 kahan.stdout-x86-linux -o1 kahan.stdout -ghc-timing 250000; ../../runstdtest/runstdtest ./kahan -o1 kahan.stdout-x86-linux -o1 kahan.stdout -o1 kahan.stdout-x86-linux -o1 kahan.stdout -ghc-timing 250000; ../../runstdtest/runstdtest ./kahan -o1 kahan.stdout-x86-linux -o1 kahan.stdout -o1 kahan.stdout-x86-linux -o1 kahan.stdout -ghc-timing 250000; ../../runstdtest/runstdtest ./kahan -o1 kahan.stdout-x86-linux -o1 kahan.stdout -o1 kahan.stdout-x86-linux -o1 kahan.stdout -ghc-timing 250000; real 0m11,382s user 0m11,263s sys 0m0,068s ././kahan 250000 < /dev/null expected stdout not matched by reality --- kahan.stdout-x86-linux 2018-03-10 15:08:24.331394642 +0100 +++ /run/user/1001/runtest13524.1 2018-05-11 18:37:37.613917102 +0200 @@ -1 +1 @@ -[3.1250125e10,5.36870300052329e14,5.36837990393551e14,5.3687312586475e14,5.36892278012076e14,5.36871047805518e14,5.3687440679156e14,5.3687150968798e14,5.36874206293665e14,5.36874289929871e14,5.36870880467025e14,5.36875752291217e14,5.36873633974166e14,5.36871490695926e14,5.36874278767665e14,5.36872044001672e14,5.36871695562571e14,5.36873241365323e14,5.36891344796027e14,5.36871364042615e14,5.3687207278968e14,5.36871448030966e14,5.36873526701777e14,5.3686969070379e14,5.36873450147425e14,5.36872888629708e14,5.36856877513993e14,5.36874914314386e14,5.36871980531699e14,5.36871094708076e14,5.36873955182668e14,5.36874682367534e14,5.36872670189794e14,5.36874208954481e14,5.36875109444419e14,5.36842522061035e14,5.36874743897417e14,5.36872676298261e14,5.3687521100164e14,5.37029772381399e14,5.36717626691437e14,5.36875098307795e14,5.3687135659988e14,5.3687220832171e14,5.36869853797463e14,5.36871593957261e14,5.36874725145677e14,5.36874015378327e14,5.36870944841328e14,5.36871037575406e14,5.36873183 358449e14,5.36882187757708e14,5.36870940912301e14,5.36871870408919e14,5.36873968990764e14,5.36871156107761e14,5.36875072608341e14,5.36858008730007e14,5.36876524461459e14,5.36878488396239e14,5.36876779527723e14,5.36872661359734e14,5.36874318642204e14,5.36871460577141e14,5.36874984929578e14,5.36871760562537e14,5.36874220890509e14,5.36901362050601e14,5.36873164135689e14,5.36870903655178e14,5.36865469589493e14,5.36875005250276e14,5.3687315418581e14,5.36874203724596e14,5.36874641590899e14,5.36864478058453e14,5.36872930904085e14,5.36875040750164e14,5.36875047071234e14,5.36873558748207e14,5.36871250001095e14,5.36835527755852e14,5.36877495114286e14,5.36872406679435e14,5.36874497481236e14,5.36872432916625e14,5.36880439868243e14,5.36874970523979e14,5.368803137722e14,5.36873202285098e14,5.36873334467439e14,5.36874672392215e14,5.36864084831155e14,5.36874402006603e14,5.36873140773385e14,5.36873395210604e14,5.36873794811151e14,5.36889150064628e14,5.37000097185173e14,5.36872851431577e14] +[3.1250125e10,3.355499554634193e19,2.3040489940690484e24,2.3058611154149143e24,2.3058472999120834e24,2.305844366659836e24,2.3058511330925993e24,2.3058473237338452e24,2.3058491660124912e24,2.3058481802173242e24,2.3058592583884928e24,2.3058507171309392e24,2.305846357572962e24,2.3058600032611292e24,2.3058387331300874e24,2.3058544370965998e24,2.305854548059399e24,2.3058722997954022e24,2.3058473047014345e24,2.3058691015804894e24,2.305852394265984e24,2.305851015951487e24,2.3058514092899828e24,2.305847204233281e24,2.3058493506776456e24,2.3058434724109167e24,2.3058537432776209e24,2.3058577600833426e24,2.3058560332176753e24,2.3058552279964046e24,2.3058510774016444e24,2.3058543202414105e24,2.3058524412598442e24,2.305843375327811e24,2.3058553394757444e24,2.3058441168348285e24,2.3058578577038755e24,2.305846042950312e24,2.3058447805295862e24,2.3058581160339402e24,2.3058793268512367e24,2.3058541939481701e24,2.3058530998187608e24,2.305776647028963e24,2.3058564304971686e24,2.305848270690023e24,2.3 058591076257776e24,2.3058633843993342e24,2.3058514500671367e24,2.3058593681438864e24,2.305856660539601e24,2.3058418820446874e24,2.305847853976928e24,2.305861203230318e24,2.3058465203390485e24,2.305860577530072e24,2.3058521690184257e24,2.3059793055137653e24,2.3058405512440228e24,2.3058613673864072e24,2.3058691465592112e24,2.305856476432445e24,2.305849891690243e24,2.30578305869136e24,2.305934172151329e24,2.305861654605338e24,2.305859714668305e24,2.3058519833483362e24,2.3058528468598076e24,2.3058463504146476e24,2.305778094950151e24,2.3058450194826421e24,2.3058448499656401e24,2.3058454039512146e24,2.3058221698005295e24,2.3059247644029773e24,2.30585544278754e24,2.3058297108614905e24,2.3058516267875765e24,2.305857364380186e24,2.305846737382448e24,2.3058308488853875e24,2.3058502421923537e24,2.3058608737162822e24,2.305859908092539e24,2.3056098809237103e24,2.305838541092883e24,2.3058591359437852e24,2.3058599172516063e24,2.3058610717389374e24,2.3058452431025416e24,2.305842957398577e24,2.30584 81366100907e24,2.3057325810298926e24,2.3058567218200272e24,2.3058526702262708e24,2.305842838994198e24,2.305860407812593e24,2.3059245607640613e24,2.3058485117216825e24] real 0m11,374s user 0m11,306s sys 0m0,066s ././kahan 250000 < /dev/null expected stdout not matched by reality --- kahan.stdout-x86-linux 2018-03-10 15:08:24.331394642 +0100 +++ /run/user/1001/runtest13546.1 2018-05-11 18:37:49.018879250 +0200 @@ -1 +1 @@ -[3.1250125e10,5.36870300052329e14,5.36837990393551e14,5.3687312586475e14,5.36892278012076e14,5.36871047805518e14,5.3687440679156e14,5.3687150968798e14,5.36874206293665e14,5.36874289929871e14,5.36870880467025e14,5.36875752291217e14,5.36873633974166e14,5.36871490695926e14,5.36874278767665e14,5.36872044001672e14,5.36871695562571e14,5.36873241365323e14,5.36891344796027e14,5.36871364042615e14,5.3687207278968e14,5.36871448030966e14,5.36873526701777e14,5.3686969070379e14,5.36873450147425e14,5.36872888629708e14,5.36856877513993e14,5.36874914314386e14,5.36871980531699e14,5.36871094708076e14,5.36873955182668e14,5.36874682367534e14,5.36872670189794e14,5.36874208954481e14,5.36875109444419e14,5.36842522061035e14,5.36874743897417e14,5.36872676298261e14,5.3687521100164e14,5.37029772381399e14,5.36717626691437e14,5.36875098307795e14,5.3687135659988e14,5.3687220832171e14,5.36869853797463e14,5.36871593957261e14,5.36874725145677e14,5.36874015378327e14,5.36870944841328e14,5.36871037575406e14,5.36873183 358449e14,5.36882187757708e14,5.36870940912301e14,5.36871870408919e14,5.36873968990764e14,5.36871156107761e14,5.36875072608341e14,5.36858008730007e14,5.36876524461459e14,5.36878488396239e14,5.36876779527723e14,5.36872661359734e14,5.36874318642204e14,5.36871460577141e14,5.36874984929578e14,5.36871760562537e14,5.36874220890509e14,5.36901362050601e14,5.36873164135689e14,5.36870903655178e14,5.36865469589493e14,5.36875005250276e14,5.3687315418581e14,5.36874203724596e14,5.36874641590899e14,5.36864478058453e14,5.36872930904085e14,5.36875040750164e14,5.36875047071234e14,5.36873558748207e14,5.36871250001095e14,5.36835527755852e14,5.36877495114286e14,5.36872406679435e14,5.36874497481236e14,5.36872432916625e14,5.36880439868243e14,5.36874970523979e14,5.368803137722e14,5.36873202285098e14,5.36873334467439e14,5.36874672392215e14,5.36864084831155e14,5.36874402006603e14,5.36873140773385e14,5.36873395210604e14,5.36873794811151e14,5.36889150064628e14,5.37000097185173e14,5.36872851431577e14] +[3.1250125e10,3.355499554634193e19,2.3040489940690484e24,2.3058611154149143e24,2.3058472999120834e24,2.305844366659836e24,2.3058511330925993e24,2.3058473237338452e24,2.3058491660124912e24,2.3058481802173242e24,2.3058592583884928e24,2.3058507171309392e24,2.305846357572962e24,2.3058600032611292e24,2.3058387331300874e24,2.3058544370965998e24,2.305854548059399e24,2.3058722997954022e24,2.3058473047014345e24,2.3058691015804894e24,2.305852394265984e24,2.305851015951487e24,2.3058514092899828e24,2.305847204233281e24,2.3058493506776456e24,2.3058434724109167e24,2.3058537432776209e24,2.3058577600833426e24,2.3058560332176753e24,2.3058552279964046e24,2.3058510774016444e24,2.3058543202414105e24,2.3058524412598442e24,2.305843375327811e24,2.3058553394757444e24,2.3058441168348285e24,2.3058578577038755e24,2.305846042950312e24,2.3058447805295862e24,2.3058581160339402e24,2.3058793268512367e24,2.3058541939481701e24,2.3058530998187608e24,2.305776647028963e24,2.3058564304971686e24,2.305848270690023e24,2.3 058591076257776e24,2.3058633843993342e24,2.3058514500671367e24,2.3058593681438864e24,2.305856660539601e24,2.3058418820446874e24,2.305847853976928e24,2.305861203230318e24,2.3058465203390485e24,2.305860577530072e24,2.3058521690184257e24,2.3059793055137653e24,2.3058405512440228e24,2.3058613673864072e24,2.3058691465592112e24,2.305856476432445e24,2.305849891690243e24,2.30578305869136e24,2.305934172151329e24,2.305861654605338e24,2.305859714668305e24,2.3058519833483362e24,2.3058528468598076e24,2.3058463504146476e24,2.305778094950151e24,2.3058450194826421e24,2.3058448499656401e24,2.3058454039512146e24,2.3058221698005295e24,2.3059247644029773e24,2.30585544278754e24,2.3058297108614905e24,2.3058516267875765e24,2.305857364380186e24,2.305846737382448e24,2.3058308488853875e24,2.3058502421923537e24,2.3058608737162822e24,2.305859908092539e24,2.3056098809237103e24,2.305838541092883e24,2.3058591359437852e24,2.3058599172516063e24,2.3058610717389374e24,2.3058452431025416e24,2.305842957398577e24,2.30584 81366100907e24,2.3057325810298926e24,2.3058567218200272e24,2.3058526702262708e24,2.305842838994198e24,2.305860407812593e24,2.3059245607640613e24,2.3058485117216825e24] real 0m12,447s user 0m12,371s sys 0m0,075s ././kahan 250000 < /dev/null expected stdout not matched by reality --- kahan.stdout-x86-linux 2018-03-10 15:08:24.331394642 +0100 +++ /run/user/1001/runtest13841.1 2018-05-11 18:38:01.501837860 +0200 @@ -1 +1 @@ -[3.1250125e10,5.36870300052329e14,5.36837990393551e14,5.3687312586475e14,5.36892278012076e14,5.36871047805518e14,5.3687440679156e14,5.3687150968798e14,5.36874206293665e14,5.36874289929871e14,5.36870880467025e14,5.36875752291217e14,5.36873633974166e14,5.36871490695926e14,5.36874278767665e14,5.36872044001672e14,5.36871695562571e14,5.36873241365323e14,5.36891344796027e14,5.36871364042615e14,5.3687207278968e14,5.36871448030966e14,5.36873526701777e14,5.3686969070379e14,5.36873450147425e14,5.36872888629708e14,5.36856877513993e14,5.36874914314386e14,5.36871980531699e14,5.36871094708076e14,5.36873955182668e14,5.36874682367534e14,5.36872670189794e14,5.36874208954481e14,5.36875109444419e14,5.36842522061035e14,5.36874743897417e14,5.36872676298261e14,5.3687521100164e14,5.37029772381399e14,5.36717626691437e14,5.36875098307795e14,5.3687135659988e14,5.3687220832171e14,5.36869853797463e14,5.36871593957261e14,5.36874725145677e14,5.36874015378327e14,5.36870944841328e14,5.36871037575406e14,5.36873183 358449e14,5.36882187757708e14,5.36870940912301e14,5.36871870408919e14,5.36873968990764e14,5.36871156107761e14,5.36875072608341e14,5.36858008730007e14,5.36876524461459e14,5.36878488396239e14,5.36876779527723e14,5.36872661359734e14,5.36874318642204e14,5.36871460577141e14,5.36874984929578e14,5.36871760562537e14,5.36874220890509e14,5.36901362050601e14,5.36873164135689e14,5.36870903655178e14,5.36865469589493e14,5.36875005250276e14,5.3687315418581e14,5.36874203724596e14,5.36874641590899e14,5.36864478058453e14,5.36872930904085e14,5.36875040750164e14,5.36875047071234e14,5.36873558748207e14,5.36871250001095e14,5.36835527755852e14,5.36877495114286e14,5.36872406679435e14,5.36874497481236e14,5.36872432916625e14,5.36880439868243e14,5.36874970523979e14,5.368803137722e14,5.36873202285098e14,5.36873334467439e14,5.36874672392215e14,5.36864084831155e14,5.36874402006603e14,5.36873140773385e14,5.36873395210604e14,5.36873794811151e14,5.36889150064628e14,5.37000097185173e14,5.36872851431577e14] +[3.1250125e10,3.355499554634193e19,2.3040489940690484e24,2.3058611154149143e24,2.3058472999120834e24,2.305844366659836e24,2.3058511330925993e24,2.3058473237338452e24,2.3058491660124912e24,2.3058481802173242e24,2.3058592583884928e24,2.3058507171309392e24,2.305846357572962e24,2.3058600032611292e24,2.3058387331300874e24,2.3058544370965998e24,2.305854548059399e24,2.3058722997954022e24,2.3058473047014345e24,2.3058691015804894e24,2.305852394265984e24,2.305851015951487e24,2.3058514092899828e24,2.305847204233281e24,2.3058493506776456e24,2.3058434724109167e24,2.3058537432776209e24,2.3058577600833426e24,2.3058560332176753e24,2.3058552279964046e24,2.3058510774016444e24,2.3058543202414105e24,2.3058524412598442e24,2.305843375327811e24,2.3058553394757444e24,2.3058441168348285e24,2.3058578577038755e24,2.305846042950312e24,2.3058447805295862e24,2.3058581160339402e24,2.3058793268512367e24,2.3058541939481701e24,2.3058530998187608e24,2.305776647028963e24,2.3058564304971686e24,2.305848270690023e24,2.3 058591076257776e24,2.3058633843993342e24,2.3058514500671367e24,2.3058593681438864e24,2.305856660539601e24,2.3058418820446874e24,2.305847853976928e24,2.305861203230318e24,2.3058465203390485e24,2.305860577530072e24,2.3058521690184257e24,2.3059793055137653e24,2.3058405512440228e24,2.3058613673864072e24,2.3058691465592112e24,2.305856476432445e24,2.305849891690243e24,2.30578305869136e24,2.305934172151329e24,2.305861654605338e24,2.305859714668305e24,2.3058519833483362e24,2.3058528468598076e24,2.3058463504146476e24,2.305778094950151e24,2.3058450194826421e24,2.3058448499656401e24,2.3058454039512146e24,2.3058221698005295e24,2.3059247644029773e24,2.30585544278754e24,2.3058297108614905e24,2.3058516267875765e24,2.305857364380186e24,2.305846737382448e24,2.3058308488853875e24,2.3058502421923537e24,2.3058608737162822e24,2.305859908092539e24,2.3056098809237103e24,2.305838541092883e24,2.3058591359437852e24,2.3058599172516063e24,2.3058610717389374e24,2.3058452431025416e24,2.305842957398577e24,2.30584 81366100907e24,2.3057325810298926e24,2.3058567218200272e24,2.3058526702262708e24,2.305842838994198e24,2.305860407812593e24,2.3059245607640613e24,2.3058485117216825e24] real 0m12,986s user 0m12,903s sys 0m0,067s ././kahan 250000 < /dev/null expected stdout not matched by reality --- kahan.stdout-x86-linux 2018-03-10 15:08:24.331394642 +0100 +++ /run/user/1001/runtest14856.1 2018-05-11 18:38:14.520794739 +0200 @@ -1 +1 @@ -[3.1250125e10,5.36870300052329e14,5.36837990393551e14,5.3687312586475e14,5.36892278012076e14,5.36871047805518e14,5.3687440679156e14,5.3687150968798e14,5.36874206293665e14,5.36874289929871e14,5.36870880467025e14,5.36875752291217e14,5.36873633974166e14,5.36871490695926e14,5.36874278767665e14,5.36872044001672e14,5.36871695562571e14,5.36873241365323e14,5.36891344796027e14,5.36871364042615e14,5.3687207278968e14,5.36871448030966e14,5.36873526701777e14,5.3686969070379e14,5.36873450147425e14,5.36872888629708e14,5.36856877513993e14,5.36874914314386e14,5.36871980531699e14,5.36871094708076e14,5.36873955182668e14,5.36874682367534e14,5.36872670189794e14,5.36874208954481e14,5.36875109444419e14,5.36842522061035e14,5.36874743897417e14,5.36872676298261e14,5.3687521100164e14,5.37029772381399e14,5.36717626691437e14,5.36875098307795e14,5.3687135659988e14,5.3687220832171e14,5.36869853797463e14,5.36871593957261e14,5.36874725145677e14,5.36874015378327e14,5.36870944841328e14,5.36871037575406e14,5.36873183 358449e14,5.36882187757708e14,5.36870940912301e14,5.36871870408919e14,5.36873968990764e14,5.36871156107761e14,5.36875072608341e14,5.36858008730007e14,5.36876524461459e14,5.36878488396239e14,5.36876779527723e14,5.36872661359734e14,5.36874318642204e14,5.36871460577141e14,5.36874984929578e14,5.36871760562537e14,5.36874220890509e14,5.36901362050601e14,5.36873164135689e14,5.36870903655178e14,5.36865469589493e14,5.36875005250276e14,5.3687315418581e14,5.36874203724596e14,5.36874641590899e14,5.36864478058453e14,5.36872930904085e14,5.36875040750164e14,5.36875047071234e14,5.36873558748207e14,5.36871250001095e14,5.36835527755852e14,5.36877495114286e14,5.36872406679435e14,5.36874497481236e14,5.36872432916625e14,5.36880439868243e14,5.36874970523979e14,5.368803137722e14,5.36873202285098e14,5.36873334467439e14,5.36874672392215e14,5.36864084831155e14,5.36874402006603e14,5.36873140773385e14,5.36873395210604e14,5.36873794811151e14,5.36889150064628e14,5.37000097185173e14,5.36872851431577e14] +[3.1250125e10,3.355499554634193e19,2.3040489940690484e24,2.3058611154149143e24,2.3058472999120834e24,2.305844366659836e24,2.3058511330925993e24,2.3058473237338452e24,2.3058491660124912e24,2.3058481802173242e24,2.3058592583884928e24,2.3058507171309392e24,2.305846357572962e24,2.3058600032611292e24,2.3058387331300874e24,2.3058544370965998e24,2.305854548059399e24,2.3058722997954022e24,2.3058473047014345e24,2.3058691015804894e24,2.305852394265984e24,2.305851015951487e24,2.3058514092899828e24,2.305847204233281e24,2.3058493506776456e24,2.3058434724109167e24,2.3058537432776209e24,2.3058577600833426e24,2.3058560332176753e24,2.3058552279964046e24,2.3058510774016444e24,2.3058543202414105e24,2.3058524412598442e24,2.305843375327811e24,2.3058553394757444e24,2.3058441168348285e24,2.3058578577038755e24,2.305846042950312e24,2.3058447805295862e24,2.3058581160339402e24,2.3058793268512367e24,2.3058541939481701e24,2.3058530998187608e24,2.305776647028963e24,2.3058564304971686e24,2.305848270690023e24,2.3 058591076257776e24,2.3058633843993342e24,2.3058514500671367e24,2.3058593681438864e24,2.305856660539601e24,2.3058418820446874e24,2.305847853976928e24,2.305861203230318e24,2.3058465203390485e24,2.305860577530072e24,2.3058521690184257e24,2.3059793055137653e24,2.3058405512440228e24,2.3058613673864072e24,2.3058691465592112e24,2.305856476432445e24,2.305849891690243e24,2.30578305869136e24,2.305934172151329e24,2.305861654605338e24,2.305859714668305e24,2.3058519833483362e24,2.3058528468598076e24,2.3058463504146476e24,2.305778094950151e24,2.3058450194826421e24,2.3058448499656401e24,2.3058454039512146e24,2.3058221698005295e24,2.3059247644029773e24,2.30585544278754e24,2.3058297108614905e24,2.3058516267875765e24,2.305857364380186e24,2.305846737382448e24,2.3058308488853875e24,2.3058502421923537e24,2.3058608737162822e24,2.305859908092539e24,2.3056098809237103e24,2.305838541092883e24,2.3058591359437852e24,2.3058599172516063e24,2.3058610717389374e24,2.3058452431025416e24,2.305842957398577e24,2.30584 81366100907e24,2.3057325810298926e24,2.3058567218200272e24,2.3058526702262708e24,2.305842838994198e24,2.305860407812593e24,2.3059245607640613e24,2.3058485117216825e24] real 0m11,926s user 0m11,874s sys 0m0,051s ././kahan 250000 < /dev/null expected stdout not matched by reality --- kahan.stdout-x86-linux 2018-03-10 15:08:24.331394642 +0100 +++ /run/user/1001/runtest15369.1 2018-05-11 18:38:26.477755177 +0200 @@ -1 +1 @@ -[3.1250125e10,5.36870300052329e14,5.36837990393551e14,5.3687312586475e14,5.36892278012076e14,5.36871047805518e14,5.3687440679156e14,5.3687150968798e14,5.36874206293665e14,5.36874289929871e14,5.36870880467025e14,5.36875752291217e14,5.36873633974166e14,5.36871490695926e14,5.36874278767665e14,5.36872044001672e14,5.36871695562571e14,5.36873241365323e14,5.36891344796027e14,5.36871364042615e14,5.3687207278968e14,5.36871448030966e14,5.36873526701777e14,5.3686969070379e14,5.36873450147425e14,5.36872888629708e14,5.36856877513993e14,5.36874914314386e14,5.36871980531699e14,5.36871094708076e14,5.36873955182668e14,5.36874682367534e14,5.36872670189794e14,5.36874208954481e14,5.36875109444419e14,5.36842522061035e14,5.36874743897417e14,5.36872676298261e14,5.3687521100164e14,5.37029772381399e14,5.36717626691437e14,5.36875098307795e14,5.3687135659988e14,5.3687220832171e14,5.36869853797463e14,5.36871593957261e14,5.36874725145677e14,5.36874015378327e14,5.36870944841328e14,5.36871037575406e14,5.36873183 358449e14,5.36882187757708e14,5.36870940912301e14,5.36871870408919e14,5.36873968990764e14,5.36871156107761e14,5.36875072608341e14,5.36858008730007e14,5.36876524461459e14,5.36878488396239e14,5.36876779527723e14,5.36872661359734e14,5.36874318642204e14,5.36871460577141e14,5.36874984929578e14,5.36871760562537e14,5.36874220890509e14,5.36901362050601e14,5.36873164135689e14,5.36870903655178e14,5.36865469589493e14,5.36875005250276e14,5.3687315418581e14,5.36874203724596e14,5.36874641590899e14,5.36864478058453e14,5.36872930904085e14,5.36875040750164e14,5.36875047071234e14,5.36873558748207e14,5.36871250001095e14,5.36835527755852e14,5.36877495114286e14,5.36872406679435e14,5.36874497481236e14,5.36872432916625e14,5.36880439868243e14,5.36874970523979e14,5.368803137722e14,5.36873202285098e14,5.36873334467439e14,5.36874672392215e14,5.36864084831155e14,5.36874402006603e14,5.36873140773385e14,5.36873395210604e14,5.36873794811151e14,5.36889150064628e14,5.37000097185173e14,5.36872851431577e14] +[3.1250125e10,3.355499554634193e19,2.3040489940690484e24,2.3058611154149143e24,2.3058472999120834e24,2.305844366659836e24,2.3058511330925993e24,2.3058473237338452e24,2.3058491660124912e24,2.3058481802173242e24,2.3058592583884928e24,2.3058507171309392e24,2.305846357572962e24,2.3058600032611292e24,2.3058387331300874e24,2.3058544370965998e24,2.305854548059399e24,2.3058722997954022e24,2.3058473047014345e24,2.3058691015804894e24,2.305852394265984e24,2.305851015951487e24,2.3058514092899828e24,2.305847204233281e24,2.3058493506776456e24,2.3058434724109167e24,2.3058537432776209e24,2.3058577600833426e24,2.3058560332176753e24,2.3058552279964046e24,2.3058510774016444e24,2.3058543202414105e24,2.3058524412598442e24,2.305843375327811e24,2.3058553394757444e24,2.3058441168348285e24,2.3058578577038755e24,2.305846042950312e24,2.3058447805295862e24,2.3058581160339402e24,2.3058793268512367e24,2.3058541939481701e24,2.3058530998187608e24,2.305776647028963e24,2.3058564304971686e24,2.305848270690023e24,2.3 058591076257776e24,2.3058633843993342e24,2.3058514500671367e24,2.3058593681438864e24,2.305856660539601e24,2.3058418820446874e24,2.305847853976928e24,2.305861203230318e24,2.3058465203390485e24,2.305860577530072e24,2.3058521690184257e24,2.3059793055137653e24,2.3058405512440228e24,2.3058613673864072e24,2.3058691465592112e24,2.305856476432445e24,2.305849891690243e24,2.30578305869136e24,2.305934172151329e24,2.305861654605338e24,2.305859714668305e24,2.3058519833483362e24,2.3058528468598076e24,2.3058463504146476e24,2.305778094950151e24,2.3058450194826421e24,2.3058448499656401e24,2.3058454039512146e24,2.3058221698005295e24,2.3059247644029773e24,2.30585544278754e24,2.3058297108614905e24,2.3058516267875765e24,2.305857364380186e24,2.305846737382448e24,2.3058308488853875e24,2.3058502421923537e24,2.3058608737162822e24,2.305859908092539e24,2.3056098809237103e24,2.305838541092883e24,2.3058591359437852e24,2.3058599172516063e24,2.3058610717389374e24,2.3058452431025416e24,2.305842957398577e24,2.30584 81366100907e24,2.3057325810298926e24,2.3058567218200272e24,2.3058526702262708e24,2.305842838994198e24,2.305860407812593e24,2.3059245607640613e24,2.3058485117216825e24] make[2]: *** [../../mk/target.mk:102: runtests] Error 1 Failed making all in kahan: 1 make[1]: *** [../mk/ghc-recurse.mk:69: all] Error 1 Failed making all in imaginary: 1 make: *** [mk/ghc-recurse.mk:69: all] Error 1 }}} Does anyone know what's going wrong there? Tobias, Andreas? I can definitely help you fix it but this is the first time I'm running nofib, so I need your help for making sense of these failures. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 11 17:14:22 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 May 2018 17:14:22 -0000 Subject: [GHC] #14251: LLVM Code Gen messes up registers In-Reply-To: <047.9ece2514d7c7f668525c93ec15fb841a@haskell.org> References: <047.9ece2514d7c7f668525c93ec15fb841a@haskell.org> Message-ID: <062.8465acda8335495af0b619eba700b883@haskell.org> #14251: LLVM Code Gen messes up registers -------------------------------------+------------------------------------- Reporter: angerman | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Compiler (LLVM) | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): It sounds like using it would be a bit risky. Kavon, did anything ever happen on this front? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 11 17:31:10 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 May 2018 17:31:10 -0000 Subject: [GHC] #14875: -ddump-splices pretty-printing oddities with case statements In-Reply-To: <050.0e58dfe7bbe09336b7902dab619fac86@haskell.org> References: <050.0e58dfe7bbe09336b7902dab619fac86@haskell.org> Message-ID: <065.8f5c98d7ea16a6be774a9d8d6b84b4a5@haskell.org> #14875: -ddump-splices pretty-printing oddities with case statements -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Debugging | Unknown/Multiple information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4688 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D4688 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 11 18:05:39 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 May 2018 18:05:39 -0000 Subject: [GHC] #13362: GHC first generation of GC to be as large as largest cache size by default In-Reply-To: <045.9df30bf1acd19df01317b133116e51f6@haskell.org> References: <045.9df30bf1acd19df01317b133116e51f6@haskell.org> Message-ID: <060.9d4f8090677238d6a56b37d394e4a988@haskell.org> #13362: GHC first generation of GC to be as large as largest cache size by default -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: numa cache gc | newcomers Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4679 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sjakobi): * owner: sjakobi => (none) Comment: There are several interesting comments on ​Phab:D4679 pointing out that a more intricate method is required for auto-sizing the allocation area. As I need to focus on my GSoC project (and due to my lack of understanding of the GC) I'm unlikely to be of much further help with this ticket. I'm also unsure whether this is still a good newcomer ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 11 18:22:18 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 May 2018 18:22:18 -0000 Subject: [GHC] #14420: Data families should not instantiate to non-Type kinds In-Reply-To: <047.a64d114cfae11861b31f70375118e394@haskell.org> References: <047.a64d114cfae11861b31f70375118e394@haskell.org> Message-ID: <062.e37f0029d106982f48a3fa7f2863cb9b@haskell.org> #14420: Data families should not instantiate to non-Type kinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by oerjan): * cc: oerjan (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 11 19:26:45 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 May 2018 19:26:45 -0000 Subject: [GHC] #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) In-Reply-To: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> References: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> Message-ID: <057.16ddbced89e091858b9746851266d54d@haskell.org> #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 (CodeGen) | Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: T13658 at runtime | T14779a T14779b T14868 debug | parsing001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4654 Wiki Page: | -------------------------------------+------------------------------------- Comment (by svenpanne): I think that none of the suggestion so far is very helpful in the long run, the raw numbers (e.g. DistroWatch, State of Haskell Survey) indicate that this problem is a show stopper for 8.4.2 and its presence alone is a reason for an 8.4.3 release: Stack is by far the most popular way to install GHC, stack is far more popular as a build tool than cabal, and Ubuntu is ranking among the top 3 (or 4, depending on the survey) Linux distros, with 18.04 even being an LTS release. Put another way: Installing and using GHC in one of the most probable ways according to surveys will lead to a fragile/broken installation. Installing a GHC by hand or changing the default GCC (which will definitely lead to problems later and undermines the whole idea of an LTS release) is OK as a stopgap measure, but not a real solution until August. I am sure everyone on this list is able to work around the problems, but I worry more about the average/wannabe Haskell user. Would it really be that hard to release an 8.4.3 with just the single fix above cherry-picked? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 11 20:15:48 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 May 2018 20:15:48 -0000 Subject: [GHC] #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) In-Reply-To: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> References: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> Message-ID: <057.f0af32b489329f160439ad6fe6630bd2@haskell.org> #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 (CodeGen) | Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: T13658 at runtime | T14779a T14779b T14868 debug | parsing001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4654 Wiki Page: | -------------------------------------+------------------------------------- Comment (by vanessamchale): >Stack is by far the most popular way to install GHC I don't think that's true. > stack is far more popular as a build tool than cabal You can use the system GHC with stack, as mentioned above. > indicate that this problem is a show stopper for 8.4.2 This is not true. > I worry more about the average/wannabe Haskell user If for whatever reason they are constrained to using stack on Ubuntu without using the system GHC, they can use the latest LTS snapshot. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 11 20:28:52 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 May 2018 20:28:52 -0000 Subject: [GHC] #14251: LLVM Code Gen messes up registers In-Reply-To: <047.9ece2514d7c7f668525c93ec15fb841a@haskell.org> References: <047.9ece2514d7c7f668525c93ec15fb841a@haskell.org> Message-ID: <062.214846a64c554003e67aae20750a4813@haskell.org> #14251: LLVM Code Gen messes up registers -------------------------------------+------------------------------------- Reporter: angerman | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Compiler (LLVM) | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): so anyone using unboxed floats/doubles targetting llvm best be careful of argument order for unlifted double# and float# till this gets fixed? this is eerily similar to some of the previous float/double register bugs we've seen in ghc, like the 7.8-7.10 series bug and the more recent windows64 abi one -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 11 20:45:37 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 May 2018 20:45:37 -0000 Subject: [GHC] #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) In-Reply-To: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> References: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> Message-ID: <057.958bc093545cfdf73f7f42f9811c0d97@haskell.org> #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 (CodeGen) | Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: T13658 at runtime | T14779a T14779b T14868 debug | parsing001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4654 Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:27 svenpanne]: Sven, I'm not sure you're seeing the full picture here. The (questionable) popularity argument is completely off-topic and irrelevant to the issue at hand. Releasing a quickfixed GHC 8.4.3 would still undermine the whole idea of Stack's "LTS" snapshot releases and its (imperfect) "reproducability" concept, as this problem isn't limited to GHC 8.4.* but rather extends back to GHC 8.2.1. As such I see no reason for yet another rushed quickfix release of GHC, for something that *must* be fixed on Stack's end anyway in order to be effective. And it would be quite laughable if Stack wasn't in a better position to release a quick fix than for GHC HQ to make a full compiler release (which I have to emphasize wouldn't be sufficient anyway for users that are forced to use Stack and their GHC 8.[24].[12] snapshots to keep working with the affected GCC versions)... ;-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 11 21:27:23 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 May 2018 21:27:23 -0000 Subject: [GHC] #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) In-Reply-To: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> References: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> Message-ID: <057.942bb09be98dc8901924ecc61f9b746d@haskell.org> #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 (CodeGen) | Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: T13658 at runtime | T14779a T14779b T14868 debug | parsing001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4654 Wiki Page: | -------------------------------------+------------------------------------- Comment (by svenpanne): Replying to [comment:28 vanessamchale]: > >Stack is by far the most popular way to install GHC > > I don't think that's true. See http://taylor.fausak.me/2017/11/15/2017-state-of-haskell-survey- results/#question-15, if you've got more plausible/recent numbers, I would be interested to see them. > > stack is far more popular as a build tool than cabal > > You can use the system GHC with stack, as mentioned above. I think you totally miss the point here: Of course you could do that, but one of the main points of `stack`'s popularity is that you don't need to do that: All you need for a happy Haskell life is to install a single tool (stack), which pulls in other tools/compilers/packages as needed. > > indicate that this problem is a show stopper for 8.4.2 > > This is not true. In all companies I've worked so far, "crashing/not working on common platforms" ''is'' a definition of show stopper. > > > I worry more about the average/wannabe Haskell user > > If for whatever reason they are constrained to using stack on Ubuntu without using the system GHC, they can use the latest LTS snapshot. Telling people: "I've got buggy new SW, just use older one" is not really productive. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 11 21:32:27 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 May 2018 21:32:27 -0000 Subject: [GHC] #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) In-Reply-To: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> References: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> Message-ID: <057.2a649166493f390115111d35b82089af@haskell.org> #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.4.3 Component: Compiler | Version: 8.4.1 (CodeGen) | Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: T13658 at runtime | T14779a T14779b T14868 debug | parsing001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4654 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.6.1 => 8.4.3 Comment: I will try to push out a new 8.4 release next week. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 11 21:40:36 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 May 2018 21:40:36 -0000 Subject: [GHC] #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) In-Reply-To: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> References: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> Message-ID: <057.acbbe67754eed708f2500c67946da947@haskell.org> #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 (CodeGen) | Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: T13658 at runtime | T14779a T14779b T14868 debug | parsing001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4654 Wiki Page: | -------------------------------------+------------------------------------- Changes (by svenpanne): * milestone: 8.4.3 => 8.6.1 Comment: Replying to [comment:29 hvr]: > Replying to [comment:27 svenpanne]: > > Sven, I'm not sure you're seeing the full picture here. The (questionable) popularity argument is completely off-topic and irrelevant to the issue at hand. Why on earth is popularity off-topic? Each and every bug is weighed by its impact. Why do we e.g. focus on x86_64 CPUs and not on e.g. ARM64? > Releasing a quickfixed GHC 8.4.3 would still undermine the whole idea of Stack's "LTS" snapshot releases and its (imperfect) "reproducability" concept, as this problem isn't limited to GHC 8.4.* but rather extends back to GHC 8.2.1. As such I see no reason for yet another rushed quickfix release of GHC, for something that *must* be fixed on Stack's end anyway in order to be effective. I fail to see why `stack` should be changed. > And it would be quite laughable if Stack wasn't in a better position to release a quick fix than for GHC HQ to make a full compiler release (which I have to emphasize wouldn't be sufficient anyway for users that are forced to use Stack and their GHC 8.[24].[12] snapshots to keep working with the affected GCC versions)... ;-) It's not laughable at all: You can provoke the same bug with `cabal`, too, just pass '-g' to GHC somehow. I somehow doubt that Ubuntu will release a new version of binutils soon (they would have to recompile each and every package if they take testing/QA seriously), so the only sane way to fix this would be in GHC itself. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 11 22:05:32 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 May 2018 22:05:32 -0000 Subject: [GHC] #11764: ghc internal error building llvm-general-3.5.1.2 In-Reply-To: <049.1e7850c7fbe53a08db3314e9a97a33fc@haskell.org> References: <049.1e7850c7fbe53a08db3314e9a97a33fc@haskell.org> Message-ID: <064.75de66832ad9cc4d03cc658559fd40c6@haskell.org> #11764: ghc internal error building llvm-general-3.5.1.2 -------------------------------------+------------------------------------- Reporter: andrew.wja | Owner: dfeuer Type: bug | Status: infoneeded Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: cabal install | llvm-general Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by George): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 11 22:50:10 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 May 2018 22:50:10 -0000 Subject: [GHC] #15142: GHC HEAD regression: tcTyVarDetails Message-ID: <050.e98a1ae073f44bf5c57814edebb43575@haskell.org> #15142: GHC HEAD regression: tcTyVarDetails -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 (Type checker) | Keywords: TypeInType, | Operating System: Unknown/Multiple TypeFamilies | Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This regression prevents the `generic-lens` library from building. Here is a minimized test case: {{{#!hs {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind class ListTuple (tuple :: Type) (as :: [(k, Type)]) where type ListToTuple as :: Type }}} On GHC 8.4.2, this compiles, but on GHC HEAD, it panics: {{{ $ ~/Software/ghc/inplace/bin/ghc-stage2 Bug.hs[1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.5.20180511 for x86_64-unknown-linux): tcTyVarDetails co_aWx :: (k_aWt[tau:2] :: *) ~# (* :: *) Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1162:37 in ghc:Outputable pprPanic, called at compiler/basicTypes/Var.hs:497:22 in ghc:Var }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 11 23:37:32 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 May 2018 23:37:32 -0000 Subject: [GHC] #15142: GHC HEAD regression: tcTyVarDetails In-Reply-To: <050.e98a1ae073f44bf5c57814edebb43575@haskell.org> References: <050.e98a1ae073f44bf5c57814edebb43575@haskell.org> Message-ID: <065.c685bd71cc6cce9ab55c0a56dadab7b5@haskell.org> #15142: GHC HEAD regression: tcTyVarDetails -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: TypeInType, Resolution: | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: goldfire (added) Comment: This was introduced in commit faec8d358985e5d0bf363bd96f23fe76c9e281f7 (`Track type variable scope more carefully.`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 12 01:02:09 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 May 2018 01:02:09 -0000 Subject: [GHC] #15143: Passing an IO value through several functions results in program hanging. Message-ID: <048.73b9ec11a636d72a48f971cab3c258d0@haskell.org> #15143: Passing an IO value through several functions results in program hanging. -------------------------------------+------------------------------------- Reporter: Burtannia | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 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 came across this rather interesting bug while writing my dissertation. The following function takes an IO Obs and if it is an observable of time (ObsTime) it increments the contained Int. Otherwise it leaves it unchanged: {{{#!hs incTime :: IO Obs -> IO Obs incTime o = do obs <- o case obs of ObsTime t -> return $ ObsTime (t+1) _ -> o }}} The case for ObsTime works as expected however, the wildcard case gets progressively slower the more times a value is passed through. At 30 iterations I waited 10 seconds before aborting execution, the function had still not returned. This issue does not occur with the following change to the wildcard case: {{{#!hs _ -> return obs }}} This issue occurs both in GHCi and after compiling with GHC. I have attached a file with the necessary code to demonstrate the issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 12 01:02:42 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 May 2018 01:02:42 -0000 Subject: [GHC] #15143: Passing an IO value through several functions results in program hanging. In-Reply-To: <048.73b9ec11a636d72a48f971cab3c258d0@haskell.org> References: <048.73b9ec11a636d72a48f971cab3c258d0@haskell.org> Message-ID: <063.8cb5060bc2b8522c922c02a4039e2e33@haskell.org> #15143: Passing an IO value through several functions results in program hanging. -------------------------------------+------------------------------------- Reporter: Burtannia | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | 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: | -------------------------------------+------------------------------------- Changes (by Burtannia): * Attachment "Bug.hs" added. Data structure and functions to demonstrate the bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 12 01:07:30 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 May 2018 01:07:30 -0000 Subject: [GHC] #15143: Passing an IO value through several functions results in program hanging. In-Reply-To: <048.73b9ec11a636d72a48f971cab3c258d0@haskell.org> References: <048.73b9ec11a636d72a48f971cab3c258d0@haskell.org> Message-ID: <063.6f7e187210d5e92a9cee084d09428e82@haskell.org> #15143: Passing an IO value through several functions results in program hanging. -------------------------------------+------------------------------------- Reporter: Burtannia | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | 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: | -------------------------------------+------------------------------------- Description changed by Burtannia: Old description: > I came across this rather interesting bug while writing my dissertation. > > The following function takes an IO Obs and if it is an observable of > time (ObsTime) it increments the contained Int. Otherwise it leaves it > unchanged: > > {{{#!hs > incTime :: IO Obs -> IO Obs > incTime o = do > obs <- o > case obs of > ObsTime t -> return $ ObsTime (t+1) > _ -> o > }}} > > The case for ObsTime works as expected however, the wildcard case gets > progressively slower the more times a value is passed through. At 30 > iterations I waited 10 seconds before aborting execution, the function > had still not returned. > > This issue does not occur with the following change to the wildcard case: > {{{#!hs > _ -> return obs > }}} > > This issue occurs both in GHCi and after compiling with GHC. > > I have attached a file with the necessary code to demonstrate the issue. New description: I came across this rather interesting bug while writing my dissertation. The following function takes an IO Obs and if it is an observable of time (ObsTime) it increments the contained Int. Otherwise it leaves it unchanged: {{{#!hs incTime :: IO Obs -> IO Obs incTime o = do obs <- o case obs of ObsTime t -> return $ ObsTime (t+1) _ -> o }}} The case for ObsTime works as expected however, the wildcard case gets progressively slower the more times a value is passed through. At 30 iterations I waited 10 seconds before aborting execution, the function had still not returned. This issue does not occur with the following change to the wildcard case: {{{#!hs _ -> return obs }}} This issue occurs both in GHCi and after compiling with GHC. It might also be worth mentioning that I've had the issue on Ubuntu (GHC 8.4.2 & 7.10.3) and Windows 7 (GHC 8.0.2). So it doesn't seem to be OS specific or caused by a recent change to GHC. I have attached a file with the necessary code to demonstrate the issue. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 12 01:08:20 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 May 2018 01:08:20 -0000 Subject: [GHC] #15143: Passing an IO value through several functions results in program hanging. In-Reply-To: <048.73b9ec11a636d72a48f971cab3c258d0@haskell.org> References: <048.73b9ec11a636d72a48f971cab3c258d0@haskell.org> Message-ID: <063.9cbdf1aa8de55ba9c03e62ca72001ac8@haskell.org> #15143: Passing an IO value through several functions results in program hanging. -------------------------------------+------------------------------------- Reporter: Burtannia | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | 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: | -------------------------------------+------------------------------------- Description changed by Burtannia: Old description: > I came across this rather interesting bug while writing my dissertation. > > The following function takes an IO Obs and if it is an observable of > time (ObsTime) it increments the contained Int. Otherwise it leaves it > unchanged: > > {{{#!hs > incTime :: IO Obs -> IO Obs > incTime o = do > obs <- o > case obs of > ObsTime t -> return $ ObsTime (t+1) > _ -> o > }}} > > The case for ObsTime works as expected however, the wildcard case gets > progressively slower the more times a value is passed through. At 30 > iterations I waited 10 seconds before aborting execution, the function > had still not returned. > > This issue does not occur with the following change to the wildcard case: > {{{#!hs > _ -> return obs > }}} > > This issue occurs both in GHCi and after compiling with GHC. > > It might also be worth mentioning that I've had the issue on Ubuntu (GHC > 8.4.2 & 7.10.3) and Windows 7 (GHC 8.0.2). So it doesn't seem to be OS > specific or caused by a recent change to GHC. > > I have attached a file with the necessary code to demonstrate the issue. New description: I came across this rather interesting bug while writing my dissertation. The following function takes an IO Obs and if it is an observable of time (ObsTime) it increments the contained Int. Otherwise it leaves it unchanged: {{{#!hs incTime :: IO Obs -> IO Obs incTime o = do obs <- o case obs of ObsTime t -> return $ ObsTime (t+1) _ -> o }}} The case for ObsTime works as expected however, the wildcard case gets progressively slower the more times a value is passed through. At 30 iterations I waited 10 seconds before aborting execution, the function had still not returned. This issue does not occur with the following change to the wildcard case: {{{#!hs _ -> return obs }}} This issue occurs both in GHCi and after compiling with GHC (with and without -O2). It might also be worth mentioning that I've had the issue on Ubuntu (GHC 8.4.2 & 7.10.3) and Windows 7 (GHC 8.0.2). So it doesn't seem to be OS specific or caused by a recent change to GHC. I have attached a file with the necessary code to demonstrate the issue. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 12 03:38:51 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 May 2018 03:38:51 -0000 Subject: [GHC] #12721: Implement sigINT handler for Window's timeout.exe In-Reply-To: <044.42a4ccfd5f9a2869586ed8f0bc527884@haskell.org> References: <044.42a4ccfd5f9a2869586ed8f0bc527884@haskell.org> Message-ID: <059.63ee23a97091a3b98db7a2af617a9049@haskell.org> #12721: Implement sigINT handler for Window's timeout.exe -------------------------------+---------------------------------------- Reporter: Phyx- | Owner: Azel Type: task | Status: patch Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4631 Wiki Page: | -------------------------------+---------------------------------------- Changes (by Azel): * status: new => patch * differential: => Phab:D4631 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 12 07:52:36 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 May 2018 07:52:36 -0000 Subject: [GHC] #15143: Passing an IO value through several functions results in program hanging. In-Reply-To: <048.73b9ec11a636d72a48f971cab3c258d0@haskell.org> References: <048.73b9ec11a636d72a48f971cab3c258d0@haskell.org> Message-ID: <063.943c3ac0e1405b322b17712315264921@haskell.org> #15143: Passing an IO value through several functions results in program hanging. -------------------------------------+------------------------------------- Reporter: Burtannia | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by osa1): Reproduced with HEAD as well. Only differences in STG between the two versions are: {{{ --- Fast.dump-stg 2018-05-12 10:47:41.827648570 +0300 +++ Slow.dump-stg 2018-05-12 10:47:47.415771391 +0300 @@ -1,6 +1,6 @@ ==================== Pre unarise: ==================== -2018-05-12 07:47:41.816039401 UTC +2018-05-12 07:47:47.404211898 UTC Main.$WObsTime [InlPrag=INLINE[2]] :: GHC.Types.Int -> Main.Obs [GblId[DataConWrapper], @@ -42,7 +42,7 @@ [GblId, Arity=4, Caf=NoCafRefs, - Str=, + Str=, Unf=OtherCon []] = [] \r [sc sg sc1 sc2] case sc1 of ds { @@ -51,8 +51,8 @@ sat [Occ=Once] :: GHC.Types.IO Main.Obs [LclId] = [sc2] \r [s] - case sc2 s of ds1 { - (#,#) ipv [Occ=Once] ipv1 [Occ=Once!] -> + case sc2 s of { + (#,#) ipv [Occ=Once*] ipv1 [Occ=Once!] -> case ipv1 of { Main.ObsTime dt [Occ=Once] -> case +# [dt 1#] of sat { @@ -63,7 +63,7 @@ CCCS Main.ObsTime! [sat]; } in (#,#) [ipv sat]; }; - Main.ObsTemp _ [Occ=Dead] -> ds1; + Main.ObsTemp _ [Occ=Dead] -> sc2 ipv; }; }; } in }}} So I guess `sc2 ipv` is causing the slowness? This is the argument passed as `sc2`: {{{ Main.main2 :: GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, Main.Obs #) [GblId, Arity=1, Caf=NoCafRefs, Str=, Unf=OtherCon []] = [] \r [void] Unit# [Main.main3]; }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 12 07:55:42 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 May 2018 07:55:42 -0000 Subject: [GHC] #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) In-Reply-To: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> References: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> Message-ID: <057.e85fa8820355c4b72507d2f0a0577e2f@haskell.org> #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 (CodeGen) | Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: T13658 at runtime | T14779a T14779b T14868 debug | parsing001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4654 Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): Sven, I still believe you're not seeing the point I'm making and trying to get back into a line of argument that's besides the point (don't get me started on the validity of those "statistics" you quote) and would only detract from the technical arguments that are pertinent to this issue. Please stop bringing up the irrelevant claims about Stack's (questionable) popularity and thus Stack would be too-big-to-fail that we have to adjust the surrounding ecosystem to Stack's needs, or even your (questionable) subjective perception about what a "happy Haskell life" constitutes, unless you really want me to get into an extended off-topic rant about of Stack's negative impact on Haskell's ecosystem and community and now even reaching into teaching (e.g. the popular data61 fp-course publicly getting attacked and its course materials even forked over Stack ideology)... But let's try to get back on-topic. Maybe I'm not explaining myself well enough to get across the technical point, that rushing a GHC 8.4.3 quickfix just to workaround bad decisions made in Stack won't be enough and that Stack will need to address this on their end or Stack users will be still be "broken" with GHC 8.2.1, 8.2.2, 8.4.1 and 8.4.2 based install- plans on their end; and that we should rather focus our limited resources on letting GHC 8.4.2 mature a bit more (which is essentially a quickfixed/proper GHC 8.4.1 which is what some communities would declare a "NUKED" release; iow, for all practical purposes GHC 8.4.1 should be considered as if it never happened). To summarise, this bug has been present in GHC since GHC 8.2.1. If we follow your logic, Stack's mere existence would require us to make a GHC 8.2.3 point release as well rather than to fix this in Stack, in order not to leave those unfortunate GHC 8.2/Stack/Ubuntu18 users out in the rain. Moreover, the most principled and thus recommended way to install and manage GHC on Debian or Ubuntu if you need a version that's not packaged by Debian/Ubuntu is via the instructions mentioned on http://downloads.haskell.org/debian/ which provides non-generic bindists specifically configured and built for the respective distribution release (this may not be so relevant on OSX or Windows, but for Linux's ABI compat story it is); this btw also means that a redundant(!) GHC 8.4.3 release would cause me a lot of busy work to "fix" something that my packaging doesn't even suffer from as I'd need to package up 8.4.3 and build it for various non-EOL'ed distros; not to mention I'd have to scrap the rather costly/time-consuming builds of a GHC 8.4.2 bindist for AIX I was working on, and start over w/ GHC 8.4.3, as well as having to carefully prepare Hackage releases of a couple GHC bootlibs and their associated Haddocks. Finally, this doesn't affect non-Stack users, unless they are on a just released Ubuntu 18 release (NB: there's currently 3 LTS releases of Ubuntu that aren't EOL'ed; nobody is forced to use the still very infantly young new Ubuntu LTS yet) *and* don't use the packages provided either by Ubuntu or by my Ubuntu PPA (or aren't capable of building GHC from source) *and* use a non-default flag which is only relevant if you actually intend and know how to debug a Haskell program at a low-level via a debugger such as GDB. I seriously doubt this is a large enough group of people to demand this urgency. I for one I can't use (nor do I recommend) using GHC 8.4.x for anything mission critical until it has matured at least 2 more months and seen more field testing, and we've had time to accumulate fixes and release a non-redundant GHC 8.4.3 with those, to get it to the same level of confidence the GHC 8.2.2 release has. I've already written more about this that I wanted to; I haven't heard any compelling reason yet that would justify rushing a redundant GHC 8.4.3 release only to keep Stack from fixing its bad choice of defaults. This is like asking to move a mountain because you don't feel like going around it. I'd rather want to see a GHC 8.4.3 released shortly before its support-window closes (which is in a couple months from now when GHC 8.6 becomes a thing), and releasing a GHC 8.4.3 now would make it more likely we won't see a GHC 8.4.4, thereby leaving us with a potentially less- reliable GHC 8.4.3 than it would be if it had had more time to mature and collect more fixes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 12 07:56:34 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 May 2018 07:56:34 -0000 Subject: [GHC] #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) In-Reply-To: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> References: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> Message-ID: <057.116072226dbf000e99bc20601c87438d@haskell.org> #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 (CodeGen) | Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: T13658 at runtime | T14779a T14779b T14868 debug | parsing001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4654 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Please move your stack/cabal-related discussions to elsewhere, this ticket is about the bug with `-g` on Ubuntu 18.04, and you're basically spamming GHC maintainers who get emails for updates on tickets. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 12 08:11:21 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 May 2018 08:11:21 -0000 Subject: [GHC] #15107: Testsuite failures on Windows In-Reply-To: <046.8e0cbe335a7ce09f5a7e747d4e07162e@haskell.org> References: <046.8e0cbe335a7ce09f5a7e747d4e07162e@haskell.org> Message-ID: <061.60aee08e1f1158668af2bc13b54e27a6@haskell.org> #15107: Testsuite failures on Windows -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4668 Wiki Page: | Phab:D4667 -------------------------------------+------------------------------------- Comment (by Tamar Christina ): In [changeset:"37810347dfeda977e7036cf8bc87ba079f094baa/ghc" 3781034/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="37810347dfeda977e7036cf8bc87ba079f094baa" Expand $tooldir in ghc --info output Summary: This requires adding an `sToolDir :: Maybe FilePath` field to Settings, since compilerInfo is pure and therefore needs to have all the information available in the DynFlags. This should fix #15101 and #15107. Test Plan: ./validate --fast Reviewers: Phyx, bgamari Reviewed By: Phyx Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15101, #15107 Differential Revision: https://phabricator.haskell.org/D4686 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 12 08:11:21 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 May 2018 08:11:21 -0000 Subject: [GHC] #12721: Implement sigINT handler for Window's timeout.exe In-Reply-To: <044.42a4ccfd5f9a2869586ed8f0bc527884@haskell.org> References: <044.42a4ccfd5f9a2869586ed8f0bc527884@haskell.org> Message-ID: <059.84f9e9f5c07c8b4d7fa91b1caf286037@haskell.org> #12721: Implement sigINT handler for Window's timeout.exe -------------------------------+---------------------------------------- Reporter: Phyx- | Owner: Azel Type: task | Status: patch Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4631 Wiki Page: | -------------------------------+---------------------------------------- Comment (by Tamar Christina ): In [changeset:"2323ffdd552327a8954de8ac37908029ec7cad38/ghc" 2323ffd/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2323ffdd552327a8954de8ac37908029ec7cad38" Adds CTRL-C handler in Windows's timeout (trac issue #12721) Summary: Uses Win32's System.Win32.Console.CtrlHandler.withConsoleCtrlHandler to add to Windows's version of the timeout executable a CTRL-C/CTRL-BREAK handler which does the close IO port/kill job cleanup, just in case. Signed-off-by: ARJANEN Loïc Jean David Reviewers: Phyx, bgamari Reviewed By: Phyx Subscribers: dfeuer, thomie, carter GHC Trac Issues: #12721 Differential Revision: https://phabricator.haskell.org/D4631 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 12 08:11:21 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 May 2018 08:11:21 -0000 Subject: [GHC] #15101: $tooldir not expanded for NoFib In-Reply-To: <047.4f2835072dd91dcbeeff182bdae28e75@haskell.org> References: <047.4f2835072dd91dcbeeff182bdae28e75@haskell.org> Message-ID: <062.ecb4b64997eb379445120fa9d898d015@haskell.org> #15101: $tooldir not expanded for NoFib -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: alpmestan Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: NoFib benchmark | Version: suite | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4667 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Tamar Christina ): In [changeset:"37810347dfeda977e7036cf8bc87ba079f094baa/ghc" 3781034/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="37810347dfeda977e7036cf8bc87ba079f094baa" Expand $tooldir in ghc --info output Summary: This requires adding an `sToolDir :: Maybe FilePath` field to Settings, since compilerInfo is pure and therefore needs to have all the information available in the DynFlags. This should fix #15101 and #15107. Test Plan: ./validate --fast Reviewers: Phyx, bgamari Reviewed By: Phyx Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15101, #15107 Differential Revision: https://phabricator.haskell.org/D4686 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 12 08:13:12 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 May 2018 08:13:12 -0000 Subject: [GHC] #15101: $tooldir not expanded for NoFib In-Reply-To: <047.4f2835072dd91dcbeeff182bdae28e75@haskell.org> References: <047.4f2835072dd91dcbeeff182bdae28e75@haskell.org> Message-ID: <062.e5b244c6d8247459145d7bc10b47d5d7@haskell.org> #15101: $tooldir not expanded for NoFib -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: alpmestan Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: NoFib benchmark | Version: suite | Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4667 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 12 08:14:34 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 May 2018 08:14:34 -0000 Subject: [GHC] #15101: $tooldir not expanded for NoFib In-Reply-To: <047.4f2835072dd91dcbeeff182bdae28e75@haskell.org> References: <047.4f2835072dd91dcbeeff182bdae28e75@haskell.org> Message-ID: <062.45668775405725c8300c54e23ade3ef9@haskell.org> #15101: $tooldir not expanded for NoFib -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: alpmestan Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: NoFib benchmark | Version: suite | Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4667 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Thanks @alpmestan! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 12 08:15:04 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 May 2018 08:15:04 -0000 Subject: [GHC] #12721: Implement sigINT handler for Window's timeout.exe In-Reply-To: <044.42a4ccfd5f9a2869586ed8f0bc527884@haskell.org> References: <044.42a4ccfd5f9a2869586ed8f0bc527884@haskell.org> Message-ID: <059.97aae98633bd9679599bde48f778f928@haskell.org> #12721: Implement sigINT handler for Window's timeout.exe -------------------------------+---------------------------------------- Reporter: Phyx- | Owner: Azel Type: task | Status: closed Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4631 Wiki Page: | -------------------------------+---------------------------------------- Changes (by Phyx-): * status: patch => closed * resolution: => fixed Comment: Thanks @Azel! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 12 09:15:11 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 May 2018 09:15:11 -0000 Subject: [GHC] #4017: Unhelpful error message in GHCi In-Reply-To: <046.b126e34ebdc516a2392e1a0dd50d1e4f@haskell.org> References: <046.b126e34ebdc516a2392e1a0dd50d1e4f@haskell.org> Message-ID: <061.96fac49264d99558e58eff62474228a3@haskell.org> #4017: Unhelpful error message in GHCi -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by supersven): * owner: supersven => (none) Comment: I investigated a few days, then got stuck and lost interest... I unassign this ticket so someone else may pick it up. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 12 09:51:07 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 May 2018 09:51:07 -0000 Subject: [GHC] #15107: Testsuite failures on Windows In-Reply-To: <046.8e0cbe335a7ce09f5a7e747d4e07162e@haskell.org> References: <046.8e0cbe335a7ce09f5a7e747d4e07162e@haskell.org> Message-ID: <061.b5045195796b65e244b36e9f519db9bf@haskell.org> #15107: Testsuite failures on Windows -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4668 Wiki Page: | Phab:D4667 -------------------------------------+------------------------------------- Comment (by alpmestan): The commit above should fix all the issues caused by `$tooldir` not being expanded. Feel free to close the ticket once you have verified that you're not seeing all those `ghc --info`-related failures anymore. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 12 10:57:39 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 May 2018 10:57:39 -0000 Subject: [GHC] #15142: GHC HEAD regression: tcTyVarDetails In-Reply-To: <050.e98a1ae073f44bf5c57814edebb43575@haskell.org> References: <050.e98a1ae073f44bf5c57814edebb43575@haskell.org> Message-ID: <065.f338f8018ac329cd47ffe717d4d49f88@haskell.org> #15142: GHC HEAD regression: tcTyVarDetails -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: TypeInType, Resolution: | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Some more observations about this: * If you swap out `TypeInType` for just `DataKinds` and `PolyKinds`, then the program no longer panics, so `TypeInType` appears to be critical in triggering this panic. * If you try and give the parameter to `ListToTuple` an explicit kind signature: {{{#!hs {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind class ListTuple (tuple :: Type) (as :: [(k, Type)]) where type ListToTuple (as :: [(k, Type)]) :: Type }}} Then this will typecheck on GHC 8.4.2, but on HEAD it will give an error message: {{{ $ ~/Software/ghc/inplace/bin/ghc-stage2 Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:9:29: error: • Expected a type, but ‘k’ has kind ‘k0’ • In the kind ‘[(k, Type)]’ | 9 | type ListToTuple (as :: [(k, Type)]) :: Type | ^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 12 14:01:43 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 May 2018 14:01:43 -0000 Subject: [GHC] #15144: Type inference regression between GHC 8.0.2 and 8.2.2 Message-ID: <050.be8ee3d4bba9d11a883dc98882f5b18d@haskell.org> #15144: Type inference regression between GHC 8.0.2 and 8.2.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 (Type checker) | 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 observed this when debugging a test case from the `HList` library that works in GHC 8.0.2, but not in GHC 8.2.2 or later. Consider the following minimized example: {{{#!hs {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE TypeFamilies #-} module Bug where import Data.Coerce import Data.Proxy type family TagR a class TypeIndexed r tr | r -> tr, tr -> r where typeIndexed :: (Coercible (TagR a) s, Functor f) => Proxy a -> (tr (TagR a) -> f (tr (TagR a))) -> r s -> f (r s) typeIndexed' pa x = typeIndexed pa x }}} In GHC 8.0.2, the type of `typeIndexed'` is correctly inferred as: {{{ $ /opt/ghc/8.0.2/bin/ghci Bug.hs GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Ok, modules loaded: Bug. λ> :t typeIndexed' typeIndexed' :: (Coercible s (TagR a), TypeIndexed r tr, Functor f) => Proxy a -> (tr (TagR a) -> f (tr (TagR a))) -> r s -> f (r s) }}} In GHC 8.2.2 and later, however, the inferred type is less general: {{{ $ /opt/ghc/8.4.2/bin/ghci Bug.hs GHCi, version 8.4.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Ok, one module loaded. λ> :t typeIndexed' typeIndexed' :: (TypeIndexed r tr, Functor f) => Proxy a -> (tr (TagR a) -> f (tr (TagR a))) -> r (TagR a) -> f (r (TagR a)) }}} Notice how the `Coercible s (TagR a)` constraint is no longer inferred. Instead, it seems that GHC is inferring the less general constraint `s ~ TagR a`, since `s` has been substituted for `TagR a` in the type `r (TagR a) -> f (r (TagR a))` (whereas in 8.0.2, it was `r s -> f (r s)`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 12 14:23:38 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 May 2018 14:23:38 -0000 Subject: [GHC] #15144: Type inference regression between GHC 8.0.2 and 8.2.2 In-Reply-To: <050.be8ee3d4bba9d11a883dc98882f5b18d@haskell.org> References: <050.be8ee3d4bba9d11a883dc98882f5b18d@haskell.org> Message-ID: <065.2b157f7d49e418c6c16b259affce156e@haskell.org> #15144: Type inference regression between GHC 8.0.2 and 8.2.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => TypeFamilies Comment: Here's a slightly smaller test case: {{{#!hs {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE TypeFamilies #-} module Bug where import Data.Coerce import Data.Proxy type family F x f :: Coercible (F a) b => Proxy a -> F a -> b f _ = coerce g p x = f p x }}} {{{ $ /opt/ghc/8.0.2/bin/ghci Bug.hs GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Ok, modules loaded: Bug. λ> :t g g :: Coercible b (F a) => Proxy a -> F a -> b }}} {{{ $ /opt/ghc/8.4.2/bin/ghci Bug.hs GHCi, version 8.4.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Ok, one module loaded. λ> :t g g :: Proxy a -> F a -> F a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 12 17:40:02 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 May 2018 17:40:02 -0000 Subject: [GHC] #15139: EmptyCase produces incorrect SrcSpans In-Reply-To: <050.786ae7468713016c9bdf7df625aed35f@haskell.org> References: <050.786ae7468713016c9bdf7df625aed35f@haskell.org> Message-ID: <065.1b30c700c24bafd05d283a58a8c13482@haskell.org> #15139: EmptyCase produces incorrect SrcSpans -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4685 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"78db41eaa806206001b80b3d225cd254435a2f83/ghc" 78db41e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="78db41eaa806206001b80b3d225cd254435a2f83" Use correct source spans for EmptyCase Summary: The parser's calculation of source spans for `EmptyCase` expressions was a bit off, leading to some wonky-looking error messages. Easily fixed with some uses of `comb3` and `sLL`. Test Plan: make test TEST=T15139 Reviewers: bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, thomie, mpickering, carter GHC Trac Issues: #15139 Differential Revision: https://phabricator.haskell.org/D4685 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 12 17:41:37 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 May 2018 17:41:37 -0000 Subject: [GHC] #15139: EmptyCase produces incorrect SrcSpans In-Reply-To: <050.786ae7468713016c9bdf7df625aed35f@haskell.org> References: <050.786ae7468713016c9bdf7df625aed35f@haskell.org> Message-ID: <065.3ce5bda6c187583ce8dce4951d14e33f@haskell.org> #15139: EmptyCase produces incorrect SrcSpans -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 (Parser) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Poor/confusing | Test Case: error message | parser/should_compile/T15139 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4685 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * testcase: => parser/should_compile/T15139 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 12 17:44:50 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 May 2018 17:44:50 -0000 Subject: [GHC] #13753: Improve GHC's ghc package environment lookup logic In-Reply-To: <042.2a208789b5cdf0bbb17f300eaf094b7c@haskell.org> References: <042.2a208789b5cdf0bbb17f300eaf094b7c@haskell.org> Message-ID: <057.d607c60e61b77a1d0bba8254285e3177@haskell.org> #13753: Improve GHC's ghc package environment lookup logic -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gershomb): Along with this, GHC and GHCI should always notify when loading with a package-env file. The default lookup paths make it too easy to accidentally run with a file when you don't realize you are, causing potentially strange behavior. Now that cabal new-* commands generate these files by default, I imagine there will be many people confused by this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 12 17:53:04 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 May 2018 17:53:04 -0000 Subject: [GHC] #15143: Passing an IO value through several functions results in program hanging. In-Reply-To: <048.73b9ec11a636d72a48f971cab3c258d0@haskell.org> References: <048.73b9ec11a636d72a48f971cab3c258d0@haskell.org> Message-ID: <063.c6a60a228fb06f11d9db429075c72f03@haskell.org> #15143: Passing an IO value through several functions results in program hanging. -------------------------------------+------------------------------------- Reporter: Burtannia | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by osa1): I made the slow program parametric on number of iterations. Seems like an exponential behavior in the generated code: {{{ $ for n ({20..30}); do time ./Slow $n; done ObsTemp 1 ./Slow $n 0,05s user 0,00s system 85% cpu 0,064 total ObsTemp 1 ./Slow $n 0,08s user 0,00s system 91% cpu 0,092 total ObsTemp 1 ./Slow $n 0,16s user 0,00s system 98% cpu 0,162 total ObsTemp 1 ./Slow $n 0,31s user 0,00s system 99% cpu 0,312 total ObsTemp 1 ./Slow $n 0,62s user 0,00s system 99% cpu 0,622 total ObsTemp 1 ./Slow $n 1,23s user 0,00s system 99% cpu 1,242 total ObsTemp 1 ./Slow $n 2,47s user 0,00s system 99% cpu 2,472 total ObsTemp 1 ./Slow $n 5,11s user 0,00s system 99% cpu 5,112 total ObsTemp 1 ./Slow $n 9,85s user 0,00s system 99% cpu 9,862 total ObsTemp 1 ./Slow $n 19,92s user 0,01s system 100% cpu 19,922 total ^C^C }}} Increasing the iteration count by one causes time it takes to double.5 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 12 17:56:58 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 May 2018 17:56:58 -0000 Subject: [GHC] #13753: Improve GHC's ghc package environment lookup logic In-Reply-To: <042.2a208789b5cdf0bbb17f300eaf094b7c@haskell.org> References: <042.2a208789b5cdf0bbb17f300eaf094b7c@haskell.org> Message-ID: <057.0c7dfa6485eee590e086231975f100af@haskell.org> #13753: Improve GHC's ghc package environment lookup logic -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gershomb): And one other note -- if the env file points to bad/missing stuff, GHC should emit an error that points to the env file as the source of the problem! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 12 18:11:25 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 May 2018 18:11:25 -0000 Subject: [GHC] #15144: Type inference regression between GHC 8.0.2 and 8.2.2 In-Reply-To: <050.be8ee3d4bba9d11a883dc98882f5b18d@haskell.org> References: <050.be8ee3d4bba9d11a883dc98882f5b18d@haskell.org> Message-ID: <065.5430d6b4657d10b5ae9cd0ea7d47bf20@haskell.org> #15144: Type inference regression between GHC 8.0.2 and 8.2.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: simonpj (added) Comment: This regression was introduced in commit 1eec1f21268af907f59b5d5c071a9a25de7369c7 (`Another major constraint-solver refactoring`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 12 21:23:07 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 May 2018 21:23:07 -0000 Subject: [GHC] #15145: Emit info-level log message when package environments have been picked up Message-ID: <042.c53199cdee50c6795e3e80c97a39de2b@haskell.org> #15145: Emit info-level log message when package environments have been picked up -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: feature | Status: new request | Priority: high | Milestone: 8.4.3 Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- A common complaint with the new package environment files feature is that it's not obvious when package environments have be picked up. Even though this feature has been in GHC since GHC 8.0, now with cabal 2.2 turning on ghc env file generation, this getting wider exposure. A similiar UI issue existed with GHCi and its `.ghci` files and the solution there was to emit a message informing the user that an implicit configuration file was picked up: {{{ GHCi, version 8.5.20180512: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/hvr/.ghci Prelude> }}} The same solution would greatly reduce the confusion with package environment files which have an even trickier lookup logic than `.ghci` files. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 12 21:24:24 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 May 2018 21:24:24 -0000 Subject: [GHC] #13753: Improve GHC's ghc package environment lookup logic In-Reply-To: <042.2a208789b5cdf0bbb17f300eaf094b7c@haskell.org> References: <042.2a208789b5cdf0bbb17f300eaf094b7c@haskell.org> Message-ID: <057.678de6edf185643035bf9d299b2719ef@haskell.org> #13753: Improve GHC's ghc package environment lookup logic -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): I've created #15145 to track the notification feature, for which I have already a working patch which I'll upload asap to Phab for further discussion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 12 21:24:47 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 May 2018 21:24:47 -0000 Subject: [GHC] #15145: Emit info-level log message when package environments have been picked up In-Reply-To: <042.c53199cdee50c6795e3e80c97a39de2b@haskell.org> References: <042.c53199cdee50c6795e3e80c97a39de2b@haskell.org> Message-ID: <057.ff3288c79b22a9b675c295021832c6d3@haskell.org> #15145: Emit info-level log message when package environments have been picked up -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: feature request | Status: new Priority: high | Milestone: 8.4.3 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * owner: (none) => hvr -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 12 21:33:49 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 May 2018 21:33:49 -0000 Subject: [GHC] #15145: Emit info-level log message when package environments have been picked up In-Reply-To: <042.c53199cdee50c6795e3e80c97a39de2b@haskell.org> References: <042.c53199cdee50c6795e3e80c97a39de2b@haskell.org> Message-ID: <057.097406371bb2d20fbdd696092bd8fb5f@haskell.org> #15145: Emit info-level log message when package environments have been picked up -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: feature request | Status: patch Priority: high | Milestone: 8.4.3 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4689 Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * status: new => patch * differential: => Phab:D4689 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 12 23:06:30 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 May 2018 23:06:30 -0000 Subject: [GHC] #13753: Improve GHC's ghc package environment lookup logic In-Reply-To: <042.2a208789b5cdf0bbb17f300eaf094b7c@haskell.org> References: <042.2a208789b5cdf0bbb17f300eaf094b7c@haskell.org> Message-ID: <057.6750e86af808efbff70976009e11ef8d@haskell.org> #13753: Improve GHC's ghc package environment lookup logic -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4690 Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * differential: => Phab:D4690 Comment: Phab:D4690 implements the first half of this feature request, i.e. the ability to opt out from the package environment feature. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 13 02:44:42 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 May 2018 02:44:42 -0000 Subject: [GHC] #12012: Socket operations on Windows check errno instead of calling WSAGetLastError() In-Reply-To: <045.1d8b8b19fc3bbac40a93311c1ba3456a@haskell.org> References: <045.1d8b8b19fc3bbac40a93311c1ba3456a@haskell.org> Message-ID: <060.ea82040c71dca07a078d8d029272ecb2@haskell.org> #12012: Socket operations on Windows check errno instead of calling WSAGetLastError() -------------------------------------+------------------------------------- Reporter: enolan | Owner: Azel Type: bug | Status: patch Priority: normal | Milestone: Component: Core Libraries | Version: Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4639 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Azel): * status: new => patch * differential: => Phab:D4639 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 13 04:46:35 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 May 2018 04:46:35 -0000 Subject: [GHC] #15146: Documentation: ScopedTypeVariables feature not mentioned/misleadingly described Message-ID: <043.d95bdea9ee71d4ecb11e1c8b5424eb30@haskell.org> #15146: Documentation: ScopedTypeVariables feature not mentioned/misleadingly described -------------------------------------+------------------------------------- Reporter: AntC | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Documentation | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple ScopedTypeVariables | Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider these dead-simple examples that use a signature with `tyvars` on a pattern {{{ -- no separate signature for bar, baz; tyvar aa not in scope from anywhere bar (x :: aa) = x :: aa baz (Just (x :: aa)) = x :: aa -- there could be signatures for bar, baz; they might use tyvar aa; but -- bar :: aa -> aa -- } no explicit forall -- baz :: Maybe aa -> aa -- } }}} Those equations with signatures on the patterns aren't valid Haskell 2010, so ghc rejects and suggests you need `ScopedTypeVariables`. Then they compile OK. Would I expect from [https://downloads.haskell.org/~ghc/8.4.2/docs/html/users_guide/glasgow_exts.html #lexically-scoped-type-variables the User Guide documentation] those equations to be valid? I think not, and I see lots of questions on StackOverflow from people confused why they must use explicit `forall` -- and some equally confused answers failing to mention that no you don't necessarily. Arguably, all of the examples in the docos could be expressed equivalently (and less confusingly for beginners) using this style with pattern signatures rather than explicit `forall` bindings. (Misleading) snippets from the docos: [[BR]][[BR]] > 10.16 Enable lexical scoping of type variables explicitly introduced with `forall`. This comment is indented, so is really explaining that `ScopedTypeVariables` implies `ExplicitForall`. But it fails to explain that you're not forced to use explicit `forall`. [[BR]][[BR]] > 10.16 opening example[[BR]] > The type signature for `f` brings the type variable `a` into scope, because of the explicit `forall` ... Fails to mentin that you could achieve the same effect without explicit `forall`. [[BR]][[BR]] > 10.16.4 ... in all patterns ''other'' than pattern bindings, a pattern type signature may mention a type variable that is not in scope; in this case, ''the signature brings that type variable into scope''. This ''might'' be telling that the `bar, baz` above examples are valid, but there is not an example. Furthermore the comment following the `MkT` existential data constructor example undermines that interpretation: > ... in this situation (and only then), a pattern type signature can mention a type variable that is not already in scope ... If all this seems a little odd, ... What is "this situation"? What is "this" that seems odd? The pattern signature binding `(MkT [t :: a])` looks the same as `baz` above's `(Just (x :: aa))`; it's merely that `Just` is not existential. There might be a signature given for `baz`, and it might use `tyvar aa`. But it ''doesn't'' bring `aa` into scope for the equations **unless** that signature has explicit `forall`. That's not made clear. My first several readings of "situation (and only then) ... odd ..." were that this style of pattern signature to bind a `tyvar` applied only for existentials. [[BR]][[BR]][[BR]] BTW, some of the examples in the docos are not valid Haskell/give compilation errors because of lack of `( )` round the patterns with signatures. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 13 08:06:05 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 May 2018 08:06:05 -0000 Subject: [GHC] #10346: Cross-module SpecConstr In-Reply-To: <046.b576f13f2450fed85380ce289fdfae5b@haskell.org> References: <046.b576f13f2450fed85380ce289fdfae5b@haskell.org> Message-ID: <061.1c404959d76c7898f2f6d5c88bf6621f@haskell.org> #10346: Cross-module SpecConstr -------------------------------------+------------------------------------- Reporter: simonpj | Owner: ckoparkar Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: SpecConstr, | newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13016 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): Replying to [comment:18 ckoparkar]: > Now that I'm looking at the proper thing, I'm a bit confused and have the same question as ak3n did. I blame the example. 1. After SpecConstr runs on M, the call isn't really recursive anymore: There will be a specialisation for the call pattern `[x, y] |> [True, (x, y)]`. The resulting function is non-recursive, inlined, and suddenly foo itself isn't recursive anymore and simply gets inlined in X. 2. The `baz` binding in M will make it so that there is a specialisation for the call pattern `[x,y] |> [False, (x,y)]` anyway. The call in X matches this pattern, so will be specialised appropriately. Try this instead: {{{#!hs module M where {-# INLINABLE foo #-} foo 0 y = y foo n y = foo (n-1) y --baz = foo 14 (2,2) --------------------- module X where import M bar = foo 2 (3,4) }}} This works better, because integer literals are not currently considered values (probably to avoid code bloat through endless loop unrolling). Notice that the call in X specialises iff you comment in `baz` in M which has the same call pattern. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 13 10:25:57 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 May 2018 10:25:57 -0000 Subject: [GHC] #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) In-Reply-To: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> References: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> Message-ID: <057.a7bc56ef18dca3ab87868400d85e01cd@haskell.org> #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 (CodeGen) | Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: T13658 at runtime | T14779a T14779b T14868 debug | parsing001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4654 Wiki Page: | -------------------------------------+------------------------------------- Comment (by YitzGale): Replying to [comment:31 bgamari]: > I will try to push out a new 8.4 release next week. Thanks! Is the fix something that can be backported to previous versions of GHC? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 13 11:04:46 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 May 2018 11:04:46 -0000 Subject: [GHC] #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) In-Reply-To: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> References: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> Message-ID: <057.85c358c996cbae724cc92145c58e8c2c@haskell.org> #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 (CodeGen) | Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: T13658 at runtime | T14779a T14779b T14868 debug | parsing001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4654 Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:35 YitzGale]: > Thanks! Is the fix something that can be backported to previous versions of GHC? It can be done, and this is typically something that falls into the scope of packagers and distributors if they need to target affected toolchains; in fact this is what I did in - GHC 8.2.2 (c.f. https://launchpad.net/~hvr/+archive/ubuntu/ghc/+sourcepub/9083599 /+listing-archive-extra) - GHC 8.4.2 (c.f. https://launchpad.net/~hvr/+archive/ubuntu/ghc/+sourcepub/9083600 /+listing-archive-extra) This has also happened in the past; without such backporting of compat- fixes I wouldn't be able to provide GHC versions ranging back to GHC 7.0.1 for the latest Debian & Ubuntu releases which had already made this necessary in the past thanks to evolving toolchains which broke assumptions made by GHC or happened to expose actual bugs, or were actually bugs in the C toolchain. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 13 11:07:08 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 May 2018 11:07:08 -0000 Subject: [GHC] #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) In-Reply-To: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> References: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> Message-ID: <057.db1d61c228e74fce72805b62abbf962f@haskell.org> #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 (CodeGen) | Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: T13658 at runtime | T14779a T14779b T14868 debug | parsing001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4654 Wiki Page: | -------------------------------------+------------------------------------- Comment (by recursion-ninja): I don't want to spam the GHC maintainers who get emails for updates on tickets. However, I think it's important to note that the non-`stack` users affected by this defect may not be so esoteric. Replying to [comment:33 hvr]: > Finally, this doesn't affect non-Stack users, unless they are on a just released Ubuntu 18 release (NB: there's currently 3 LTS releases of Ubuntu that aren't EOL'ed; nobody is forced to use the still very infantly young new Ubuntu LTS yet) ... I was having "show-stopping" graphics driver issues on Ubuntu 16.04 that were only resolved by the 4.15.* version of the Linux kernel which was not and would not be supported (to the best of my knowledge) by Ubuntu 16.04. My upgrade to Ubuntu 18.04 was more or less "forced" to get a kernel version compatible with my machine. Replying to [comment:33 hvr]: > ... *and* use a non-default flag which is only relevant if you actually intend and know how to debug a Haskell program at a low-level via a debugger such as GDB. I was passing the `-g` flag while building with `cabal` because I have been fixing a defective feature involving the `Cabal` library linking to C & C++ sources and required debugging symbols while investigating and correcting the issue. https://github.com/haskell/cabal/pull/5315 Replying to [comment:33 hvr]: > I seriously doubt this is a large enough group of people to demand this urgency. This might be true. However, I did encountered this `-g` related defect through "normal," non-`stack` usage of `ghc`. There's a chance that my situation is an anomaly, but there's also a chance the defect might have a larger impact than estimated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 13 11:58:01 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 May 2018 11:58:01 -0000 Subject: [GHC] #13753: Improve GHC's ghc package environment lookup logic In-Reply-To: <042.2a208789b5cdf0bbb17f300eaf094b7c@haskell.org> References: <042.2a208789b5cdf0bbb17f300eaf094b7c@haskell.org> Message-ID: <057.6ba48703ccc213e6a1f76305bd8e9aaa@haskell.org> #13753: Improve GHC's ghc package environment lookup logic -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4690 Wiki Page: | -------------------------------------+------------------------------------- Changes (by int-e): * cc: int-e (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 13 12:18:57 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 May 2018 12:18:57 -0000 Subject: [GHC] #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) In-Reply-To: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> References: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> Message-ID: <057.e7d81cc0cd66ede06fa92a74db6fe6e8@haskell.org> #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 (CodeGen) | Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: T13658 at runtime | T14779a T14779b T14868 debug | parsing001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4654 Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:37 recursion-ninja]: > I was having "show-stopping" graphics driver issues on Ubuntu 16.04 that were only resolved by the 4.15.* version of the Linux kernel which was not and would not be supported (to the best of my knowledge) by Ubuntu 16.04. My upgrade to Ubuntu 18.04 was more or less "forced" to get a kernel version compatible with my machine. I've been in a similiar situation, and so have a lot others; *but* that's why Ubuntu some time ago introduced https://wiki.ubuntu.com/Kernel/LTSEnablementStack in order to help users who want to avoid having to upgrade away from an LTS release for the sake of a kernel upgrade. I'm happily running a {{{ ii linux-image-4.15.0-20-generic 4.15.0-20.21~16.04.1 amd64 Signed kernel image generic }}} kernel which iirc I had gotten installed before Ubuntu 18.04 Bionic was even released. > This might be true. However, I did encountered this `-g` related defect through "normal," non-`stack` usage of `ghc`. There's a chance that my situation is an anomaly, but there's also a chance the defect might have a larger impact than estimated. Since you're on an Ubuntu system and you seem to be experienced enough to consider installing a bleedinge edge GCC toolchain; but then why aren't you simply using a GHC binary distribution like the ones I offer on https://launchpad.net/~hvr/+archive/ubuntu/ghc which are specifically configured and built for Ubuntu and designed to protect against this very kind of compatibility issues that inevitably creep up over time? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 13 12:46:26 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 May 2018 12:46:26 -0000 Subject: [GHC] #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) In-Reply-To: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> References: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> Message-ID: <057.4d54a2378050d6fc3c79947ef42bb1dc@haskell.org> #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 (CodeGen) | Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: T13658 at runtime | T14779a T14779b T14868 debug | parsing001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4654 Wiki Page: | -------------------------------------+------------------------------------- Comment (by YitzGale): According to reports on the [https://github.com/commercialhaskell/stack/issues/4019 stack github issue], this now appears to be far less common than originally thought. It only occurs if {{{-g}}} is set AND stripping is not enabled, and stack enables both of those by default. So the issue does not affect most stack users. It only affects those who explicitly disable stripping. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 13 17:34:45 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 May 2018 17:34:45 -0000 Subject: [GHC] #15145: Emit info-level log message when package environments have been picked up In-Reply-To: <042.c53199cdee50c6795e3e80c97a39de2b@haskell.org> References: <042.c53199cdee50c6795e3e80c97a39de2b@haskell.org> Message-ID: <057.0def6706a258290bb5c358110570b35e@haskell.org> #15145: Emit info-level log message when package environments have been picked up -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: feature request | Status: patch Priority: high | Milestone: 8.4.3 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4689 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"00049e2dce93b1e468c3fde3287371eb988aafdc/ghc" 00049e2d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="00049e2dce93b1e468c3fde3287371eb988aafdc" Emit info-level log message when package envs are loaded A common complaint with the new package environment files feature is that it's not obvious when package environments have been picked up. This patch applies the same strategy that was already used for `.ghci` files (which exhibit similar potential for confusion, c.f. #11389) to package environment files. For instance, this new notification looks like below for a GHCi invocation which loads both, a GHCi configuration as well as a package environment: GHCi, version 8.5.20180512: http://www.haskell.org/ghc/ :? for help Loaded package environment from /tmp/parsec-3.1.13.0/.ghc.environment.x86_64-linux-8.5.20180512 Loaded GHCi configuration from /home/hvr/.ghci Prelude> Addresses #15145 Reviewed By: bgamari, angerman GHC Trac Issues: #15145 Differential Revision: https://phabricator.haskell.org/D4689 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 13 17:34:45 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 May 2018 17:34:45 -0000 Subject: [GHC] #11389: Print a message when loading a .ghci file In-Reply-To: <047.1d63cb35ff6f4d0a115e374b02190353@haskell.org> References: <047.1d63cb35ff6f4d0a115e374b02190353@haskell.org> Message-ID: <062.4a011aff9b98296154bcd7c0cd320ec2@haskell.org> #11389: Print a message when loading a .ghci file -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: kseo Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.8.4 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"00049e2dce93b1e468c3fde3287371eb988aafdc/ghc" 00049e2d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="00049e2dce93b1e468c3fde3287371eb988aafdc" Emit info-level log message when package envs are loaded A common complaint with the new package environment files feature is that it's not obvious when package environments have been picked up. This patch applies the same strategy that was already used for `.ghci` files (which exhibit similar potential for confusion, c.f. #11389) to package environment files. For instance, this new notification looks like below for a GHCi invocation which loads both, a GHCi configuration as well as a package environment: GHCi, version 8.5.20180512: http://www.haskell.org/ghc/ :? for help Loaded package environment from /tmp/parsec-3.1.13.0/.ghc.environment.x86_64-linux-8.5.20180512 Loaded GHCi configuration from /home/hvr/.ghci Prelude> Addresses #15145 Reviewed By: bgamari, angerman GHC Trac Issues: #15145 Differential Revision: https://phabricator.haskell.org/D4689 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 13 17:36:41 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 May 2018 17:36:41 -0000 Subject: [GHC] #15145: Emit info-level log message when package environments have been picked up In-Reply-To: <042.c53199cdee50c6795e3e80c97a39de2b@haskell.org> References: <042.c53199cdee50c6795e3e80c97a39de2b@haskell.org> Message-ID: <057.b1c406b4daa24706b832f5eec374823e@haskell.org> #15145: Emit info-level log message when package environments have been picked up -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: feature request | Status: merge Priority: high | Milestone: 8.4.3 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4689 Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * status: patch => merge Comment: I'll mark this tentatively as merge to GHC 8.4.x as I have the impression this is highly demanded feature; the decision ultimately rests with Ben as the release manager -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 13 19:12:31 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 May 2018 19:12:31 -0000 Subject: [GHC] #14502: Build Alpine Linux binary distributions In-Reply-To: <046.7faa39537281abdbe7789c4ce9416be8@haskell.org> References: <046.7faa39537281abdbe7789c4ce9416be8@haskell.org> Message-ID: <061.f44a56ff82ed344f419d64c9a39ba08e@haskell.org> #14502: Build Alpine Linux binary distributions -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Continuous | Version: 8.2.1 Integration | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 14057 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mitchty): Note, for 8.4.2 or anything using llvm as the backend, you'll need to adjust the llvm-targets like so: https://github.com/alpinelinux/aports/pull/4255/commits/adc976d03f8101300f2f4d73b782859edb4b3c1f #diff-8ac9400d01cb6d2dd0f7486ac80d2ec4R103 Basically: sed -i -e 's/unknown-linux-gnueabihf/alpine-linux/g' llvm-targets sed -i -e 's/unknown-linux-gnueabi/alpine-linux/g' llvm-targets sed -i -e 's/unknown-linux-gnu/alpine-linux/g' llvm-targets The llvm triples that are in place for alpine linux are different from the defaults expected. Most other changes for alpine linux have been merged upstream into ghc so the base source is mostly there. I remember asking in the ghc irc channel that depending on the llvm triples should go away entirely. I'd be all for that in this case for 8.6! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 13 20:10:56 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 May 2018 20:10:56 -0000 Subject: [GHC] #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) In-Reply-To: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> References: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> Message-ID: <057.cd9896e6ccfcb88efc0a09af838cb76d@haskell.org> #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.4.3 Component: Compiler | Version: 8.4.1 (CodeGen) | Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: T13658 at runtime | T14779a T14779b T14868 debug | parsing001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4654 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.6.1 => 8.4.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 13 21:22:29 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 May 2018 21:22:29 -0000 Subject: [GHC] #11066: Inacessible branch should be warning - otherwise breaks type soundness? In-Reply-To: <047.0785946e31f05741dc32414264d84d16@haskell.org> References: <047.0785946e31f05741dc32414264d84d16@haskell.org> Message-ID: <062.00faf05dbe468bee0dbc4692fd636108@haskell.org> #11066: Inacessible branch should be warning - otherwise breaks type soundness? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #8128, #8740 | Differential Rev(s): Phab:D1454 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Turning the error into a warning causes a few regressions, e.g. T3651: {{{ {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeFamilies #-} module T3651 where data Z a where U :: Z () B :: Z Bool unsafe1 :: Z a -> Z a -> a unsafe1 B U = () unsafe2 :: a ~ b => Z b -> Z a -> a unsafe2 B U = () unsafe3 :: a ~ b => Z a -> Z b -> a unsafe3 B U = True }}} This program previously failed with this exact error, and of course changing it into a warning makes it compile. Other regressions are: - {{{concurrent/prog001/concprog001.run concprog001 [bad exit code] (threaded2)}}} - {{{gadt/T3651.run T3651 [stderr mismatch] (normal)}}} - {{{gadt/T7293.run T7293 [exit code 0] (normal)}}} - {{{gadt/T7294.run T7294 [stderr mismatch] (normal)}}} - {{{gadt/T7558.run T7558 [stderr mismatch] (normal)}}} - {{{ghci/scripts/Defer02.run Defer02 [bad stderr] (ghci)}}} - {{{typecheck/should_fail/tcfail167.run tcfail167 [exit code 0] (normal)}}} - {{{typecheck/should_fail/FrozenErrorTests.run FrozenErrorTests [stderr mismatch] (normal)}}} - {{{typecheck/should_run/Typeable1.run Typeable1 [exit code 0] (normal)}}} I will look into these, but I suspect that most of them are exactly what we'd expect. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 13 22:08:20 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 May 2018 22:08:20 -0000 Subject: [GHC] #15040: DTrace enabled GHC does not work as a bootstrap compiler on FreeBSD In-Reply-To: <046.4248b292a38cdda9701c70fc8d24c20a@haskell.org> References: <046.4248b292a38cdda9701c70fc8d24c20a@haskell.org> Message-ID: <061.f56e2a0166bdbb015b6e45ff3c09592a@haskell.org> #15040: DTrace enabled GHC does not work as a bootstrap compiler on FreeBSD -------------------------------------+------------------------------------- Reporter: raichoo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.2 Component: Build System | Version: 8.4.1 Resolution: | Keywords: dtrace Operating System: FreeBSD | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): A workaround was merged for 8.4.2 with ab458df61bd792654322fd6b20b1ac42e17f3f81. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 13 22:08:33 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 May 2018 22:08:33 -0000 Subject: [GHC] #15040: DTrace enabled GHC does not work as a bootstrap compiler on FreeBSD In-Reply-To: <046.4248b292a38cdda9701c70fc8d24c20a@haskell.org> References: <046.4248b292a38cdda9701c70fc8d24c20a@haskell.org> Message-ID: <061.c392bc9b73062193790592d6ef4c1512@haskell.org> #15040: DTrace enabled GHC does not work as a bootstrap compiler on FreeBSD -------------------------------------+------------------------------------- Reporter: raichoo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Build System | Version: 8.4.1 Resolution: | Keywords: dtrace Operating System: FreeBSD | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.4.2 => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 13 22:08:56 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 May 2018 22:08:56 -0000 Subject: [GHC] #15010: Application (warp) server crashing periodically with "TSO object entered" In-Reply-To: <047.a86a5c0a290e1c542e4015a537513efc@haskell.org> References: <047.a86a5c0a290e1c542e4015a537513efc@haskell.org> Message-ID: <062.25a4109d3e593b86210c80d3fdec4842@haskell.org> #15010: Application (warp) server crashing periodically with "TSO object entered" -------------------------------------+------------------------------------- Reporter: ramirez7 | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => infoneeded * milestone: 8.4.3 => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 13 22:10:10 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 May 2018 22:10:10 -0000 Subject: [GHC] #15145: Emit info-level log message when package environments have been picked up In-Reply-To: <042.c53199cdee50c6795e3e80c97a39de2b@haskell.org> References: <042.c53199cdee50c6795e3e80c97a39de2b@haskell.org> Message-ID: <057.b963cee376f16e99331fad41b5a605ae@haskell.org> #15145: Emit info-level log message when package environments have been picked up -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: feature request | Status: merge Priority: high | Milestone: 8.4.3 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4689 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): This sounds reasonable enough to me in light of the recent discussion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 13 22:14:45 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 May 2018 22:14:45 -0000 Subject: [GHC] #15147: Type checker plugin receives Wanteds that are not completely unflattened Message-ID: <046.7de470c11f4eabed34171ca75a3b8063@haskell.org> #15147: Type checker plugin receives Wanteds that are not completely unflattened -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 (Type checker) | Keywords: type checker | Operating System: Unknown/Multiple plugins | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- With the following, a plugin will receive a wanted constraint that includes a `fsk` flattening skolem. {{{ -- "Reduced" via the plugin type family F u v where {} type family G a b where {} data D p where DC :: (p ~ F x (G () ())) => D p }}} (Please ignore the apparent ambiguity regarding `x`; the goal is for the plugin to eliminate any ambiguity.) A do-nothing plugin that merely logs its inputs gives the following for the ambiguity check on DC. {{{ given [G] $d~_a4oh {0}:: (p_a4o2[sk:2] :: *) ~ (p_a4o2[sk:2] :: *) (CDictCan) [G] $d~~_a4oi {0}:: (p_a4o2[sk:2] :: *) ~~ (p_a4o2[sk:2] :: *) (CDictCan) [G] co_a4od {0}:: (G () () :: *) ~# (fsk_a4oc[fsk:0] :: *) (CFunEqCan) [G] co_a4of {0}:: (F x_a4o3[sk:2] fsk_a4oc[fsk:0] :: *) ~# (fsk_a4oe[fsk:0] :: *) (CFunEqCan) [G] co_a4og {1}:: (fsk_a4oe[fsk:0] :: *) ~# (p_a4o2[sk:2] :: *) (CTyEqCan) derived wanted [WD] hole{co_a4or} {3}:: (F x_a4o6[tau:2] fsk_a4oc[fsk:0] :: *) ~# (p_a4o2[sk:2] :: *) (CNonCanonical) untouchables [fsk_a4oe[fsk:0], fsk_a4oc[fsk:0], x_a4o3[sk:2], p_a4o2[sk:2]] }}} Note the `fsk_a4oc[fsk:0]` tyvar in the Wanted constraint, which is why I'm opening this ticket. Its presence contradicts the "The wanteds will be unflattened and zonked" claim from https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker#Callingpluginsfromthetypechecker section. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 13 22:15:40 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 May 2018 22:15:40 -0000 Subject: [GHC] #15147: Type checker plugin receives Wanteds that are not completely unflattened In-Reply-To: <046.7de470c11f4eabed34171ca75a3b8063@haskell.org> References: <046.7de470c11f4eabed34171ca75a3b8063@haskell.org> Message-ID: <061.3ed029f9d5556b53bbfc667a96f23400@haskell.org> #15147: Type checker plugin receives Wanteds that are not completely unflattened -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.1 checker) | Keywords: type checker Resolution: | plugins Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nfrisby): Looking at `-ddump-tc-trace`, the compiler flattens the wanteds and then zonks them before passing them to the plugin. However, the zonking pass makes a substitution that re-introduces the fsk var. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 13 22:30:54 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 May 2018 22:30:54 -0000 Subject: [GHC] #14078: -ddump-json doesn't work well with GHCi In-Reply-To: <050.a3c1661fff8336ca3c521994e1a88d18@haskell.org> References: <050.a3c1661fff8336ca3c521994e1a88d18@haskell.org> Message-ID: <065.f0f1088073dd83d2771903ecde571c2b@haskell.org> #14078: -ddump-json doesn't work well with GHCi -------------------------------------+------------------------------------- Reporter: dramforever | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.1 Resolution: | Keywords: JSON Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"6ab7cf995dafcc9196e87bbde76b4f6937507592/ghc" 6ab7cf9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6ab7cf995dafcc9196e87bbde76b4f6937507592" Simplify -ddump-json implementation This patch takes the much simpler route of whenever the compiler tries to output something. We just dump a JSON document there and then. I think this should be sufficient to work with and anything more refined quickly got complicated as it was necessary to demarcate message scopes and so on. Reviewers: bgamari, dfeuer Reviewed By: bgamari Subscribers: Phyx, dfeuer, rwbarton, thomie, carter GHC Trac Issues: #14078 Differential Revision: https://phabricator.haskell.org/D4532 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 13 22:31:09 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 May 2018 22:31:09 -0000 Subject: [GHC] #15115: `Numeric.showEFloat` does not honor precision with 0 digits In-Reply-To: <045.cd71602cfa60bbc0128fc78c2d018224@haskell.org> References: <045.cd71602cfa60bbc0128fc78c2d018224@haskell.org> Message-ID: <060.5d353c7d263e35bc702a7d68262fa080@haskell.org> #15115: `Numeric.showEFloat` does not honor precision with 0 digits -------------------------------------+------------------------------------- Reporter: guibou | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: libraries/base | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | libraries/base/tests/Numeric/num008 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4665 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"9039f847a568ac69436d449b9fe090ecd03b9e06/ghc" 9039f847/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9039f847a568ac69436d449b9fe090ecd03b9e06" base: Fix handling of showEFloat (Just 0) Previously `showEFloat (Just 0) pi ""` would produce `3.0e0`. Of course, this blatantly disrespects the user's request to print with zero digits of precision. Fix this. This is tested by base's `num008` testcase. Test Plan: Validate Reviewers: hvr Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15115 Differential Revision: https://phabricator.haskell.org/D4665 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 13 22:31:24 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 May 2018 22:31:24 -0000 Subject: [GHC] #15067: When Typeable and unboxed sums collide, GHC panics In-Reply-To: <050.61b6b35d8587a28e0de8c6a6604fc205@haskell.org> References: <050.61b6b35d8587a28e0de8c6a6604fc205@haskell.org> Message-ID: <065.6fea3b5c7e02187c72f4efbeb7defa79@haskell.org> #15067: When Typeable and unboxed sums collide, GHC panics -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.1 checker) | Keywords: Typeable, Resolution: | UnboxedSums Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13276 | Differential Rev(s): Phab:D4622, Wiki Page: | Phab:D4623 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"f0212a93a2f3d4fb564c1025cca0dfd3050487e4/ghc" f0212a93/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f0212a93a2f3d4fb564c1025cca0dfd3050487e4" TcInteract: Ensure that tycons have representations before solving for Typeable Summary: This fixes #15067. Test Plan: Validate Subscribers: thomie, carter, RyanGlScott GHC Trac Issues: #15067 Differential Revision: https://phabricator.haskell.org/D4623 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 13 22:32:49 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 May 2018 22:32:49 -0000 Subject: [GHC] #14078: -ddump-json doesn't work well with GHCi In-Reply-To: <050.a3c1661fff8336ca3c521994e1a88d18@haskell.org> References: <050.a3c1661fff8336ca3c521994e1a88d18@haskell.org> Message-ID: <065.6d27e3384cdba0e0959ef244cd2fcd79@haskell.org> #14078: -ddump-json doesn't work well with GHCi -------------------------------------+------------------------------------- Reporter: dramforever | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.1 Resolution: fixed | Keywords: JSON Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 14 01:44:51 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 May 2018 01:44:51 -0000 Subject: [GHC] #15147: Type checker plugin receives Wanteds that are not completely unflattened In-Reply-To: <046.7de470c11f4eabed34171ca75a3b8063@haskell.org> References: <046.7de470c11f4eabed34171ca75a3b8063@haskell.org> Message-ID: <061.a7ef4fa5a9a17bbcba4a61d1b569a980@haskell.org> #15147: Type checker plugin receives Wanteds that are not completely unflattened -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.1 checker) | Keywords: type checker Resolution: | plugins Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nfrisby): Actually, I'm starting to suspect that my plugin would be best off if GHC neither unflattened nor zonked the wanteds before invoking the plugin. Does that sound unreasonable? If not, let me know and I'll try to prepare a feature request ticket. Perhaps we could add an option to the API for a plugin to request that sort of treatment. Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 14 02:50:49 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 May 2018 02:50:49 -0000 Subject: [GHC] #14875: -ddump-splices pretty-printing oddities with case statements In-Reply-To: <050.0e58dfe7bbe09336b7902dab619fac86@haskell.org> References: <050.0e58dfe7bbe09336b7902dab619fac86@haskell.org> Message-ID: <065.04ae581adef0dbd87d6f2635760ccfbf@haskell.org> #14875: -ddump-splices pretty-printing oddities with case statements -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Debugging | Unknown/Multiple information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4688 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 14 02:51:37 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 May 2018 02:51:37 -0000 Subject: [GHC] #15055: ghci - improve error on hidden package In-Reply-To: <043.0e347aaf83f899bb699c91fa0da78884@haskell.org> References: <043.0e347aaf83f899bb699c91fa0da78884@haskell.org> Message-ID: <058.eb75975e67298f3123b614d8e7ea3d60@haskell.org> #15055: ghci - improve error on hidden package -------------------------------------+------------------------------------- Reporter: akfp | Owner: ckoparkar Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.2 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4621, Wiki Page: | Phab:D4669 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"30c887d3b176a36b7affc27b118e0450d115df0c/ghc" 30c887d3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="30c887d3b176a36b7affc27b118e0450d115df0c" GHCi: Include a note in the hint to expose a hidden package Test Plan: validate Reviewers: bgamari, RyanGlScott, osa1 Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15055 Differential Revision: https://phabricator.haskell.org/D4669 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 14 02:51:47 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 May 2018 02:51:47 -0000 Subject: [GHC] #15021: ghc-pkg list crashes on Windows when unicode character is in the path In-Reply-To: <042.26589a8b8ccb1785877bd8d707d56c92@haskell.org> References: <042.26589a8b8ccb1785877bd8d707d56c92@haskell.org> Message-ID: <057.595ef5798a15be5ad5c2f0e26eda29c3@haskell.org> #15021: ghc-pkg list crashes on Windows when unicode character is in the path -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: ghc-pkg | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: GHC doesn't work | Unknown/Multiple at all | Test Case: Blocked By: | Blocking: Related Tickets: #10762, #15096 | Differential Rev(s): Phab:D4642 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Done. Thanks for your help, lehins! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 14 02:52:21 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 May 2018 02:52:21 -0000 Subject: [GHC] #14875: -ddump-splices pretty-printing oddities with case statements In-Reply-To: <050.0e58dfe7bbe09336b7902dab619fac86@haskell.org> References: <050.0e58dfe7bbe09336b7902dab619fac86@haskell.org> Message-ID: <065.790e341b52e1229edb46291d79e79a5b@haskell.org> #14875: -ddump-splices pretty-printing oddities with case statements -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Debugging | Unknown/Multiple information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4688 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"21e1a00c0ccf3072ccc04cd1acfc541c141189d2/ghc" 21e1a00c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="21e1a00c0ccf3072ccc04cd1acfc541c141189d2" Fix #14875 by introducing PprPrec, and using it Trying to determine when to insert parentheses during TH conversion is a bit of a mess. There is an assortment of functions that try to detect this, such as: * `hsExprNeedsParens` * `isCompoundHsType` * `hsPatNeedsParens` * `isCompoundPat` * etc. To make things worse, each of them have slightly different semantics. Plus, they don't work well in the presence of explicit type signatures, as #14875 demonstrates. All of these problems can be alleviated with the use of an explicit precedence argument (much like what `showsPrec` currently does). To accomplish this, I introduce a new `PprPrec` data type, and define standard predences for things like function application, infix operators, function arrows, and explicit type signatures (that last one is new). I then added `PprPrec` arguments to the various `-NeedsParens` functions, and use them to make smarter decisions about when things need to be parenthesized. A nice side effect is that functions like `isCompoundHsType` are now completely unneeded, since they're simply aliases for `hsTypeNeedsParens appPrec`. As a result, I did a bit of refactoring to remove these sorts of functions. I also did a pass over various utility functions in GHC for constructing AST forms and used more appropriate precedences where convenient. Along the way, I also ripped out the existing `TyPrec` data type (which was tailor-made for pretty-printing `Type`s) and replaced it with `PprPrec` for consistency. Test Plan: make test TEST=T14875 Reviewers: alanz, goldfire, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14875 Differential Revision: https://phabricator.haskell.org/D4688 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 14 02:52:37 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 May 2018 02:52:37 -0000 Subject: [GHC] #10762: On Windows, out-of-codepage characters can cause GHC build to fail In-Reply-To: <047.594293f39928454a6845b64e2efaf718@haskell.org> References: <047.594293f39928454a6845b64e2efaf718@haskell.org> Message-ID: <062.4eb2f2d27bc589193e258d71b925c3b1@haskell.org> #10762: On Windows, out-of-codepage characters can cause GHC build to fail ----------------------------------+-------------------------------------- Reporter: snoyberg | Owner: snoyberg Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #6037, #15021 | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Comment (by Ben Gamari ): In [changeset:"cf88c2b109a9f36d151af7fa0e542c48c98115fa/ghc" cf88c2b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="cf88c2b109a9f36d151af7fa0e542c48c98115fa" ghc-pkg: Configure handle encodings This fixes #15021 using a the same approach as was used to fix the issue in ghc (#10762). Test Plan: Validate on Windows as user whose username contains non-ASCII characters Reviewers: simonmar Reviewed By: simonmar Subscribers: lehins, thomie, carter GHC Trac Issues: #15021 Differential Revision: https://phabricator.haskell.org/D4642 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 14 02:52:37 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 May 2018 02:52:37 -0000 Subject: [GHC] #15021: ghc-pkg list crashes on Windows when unicode character is in the path In-Reply-To: <042.26589a8b8ccb1785877bd8d707d56c92@haskell.org> References: <042.26589a8b8ccb1785877bd8d707d56c92@haskell.org> Message-ID: <057.f856e7d984222ec4723a9e79c62acefb@haskell.org> #15021: ghc-pkg list crashes on Windows when unicode character is in the path -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: ghc-pkg | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: GHC doesn't work | Unknown/Multiple at all | Test Case: Blocked By: | Blocking: Related Tickets: #10762, #15096 | Differential Rev(s): Phab:D4642 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"cf88c2b109a9f36d151af7fa0e542c48c98115fa/ghc" cf88c2b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="cf88c2b109a9f36d151af7fa0e542c48c98115fa" ghc-pkg: Configure handle encodings This fixes #15021 using a the same approach as was used to fix the issue in ghc (#10762). Test Plan: Validate on Windows as user whose username contains non-ASCII characters Reviewers: simonmar Reviewed By: simonmar Subscribers: lehins, thomie, carter GHC Trac Issues: #15021 Differential Revision: https://phabricator.haskell.org/D4642 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 14 02:52:52 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 May 2018 02:52:52 -0000 Subject: [GHC] #13753: Improve GHC's ghc package environment lookup logic In-Reply-To: <042.2a208789b5cdf0bbb17f300eaf094b7c@haskell.org> References: <042.2a208789b5cdf0bbb17f300eaf094b7c@haskell.org> Message-ID: <057.f5b1d2fe14d7e5e7fa466240e62e90b4@haskell.org> #13753: Improve GHC's ghc package environment lookup logic -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4690 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"8f3c149d94814e4f278b08c562f06fc257eb3c43/ghc" 8f3c149/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8f3c149d94814e4f278b08c562f06fc257eb3c43" Add support for opting out of package environments This implements the first part proposed in #13753: Define a special magic "null" environment, which instructs GHC to ignore any package environment files. To this end, I propose to use the name `-` (i.e. a single dash), as that is more portable than using the empty string for environment variables. In other words, a - `-package-env -` CLI flag, or a - `GHC_ENVIRONMENT=-` env var (unless a `-package-env` flag is present) would inhibit GHC from looking up and interpreting any package environment files from the filesystem; this is the equivalent of `-ignore-dot-ghci` for package environment files. Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #13753 Differential Revision: https://phabricator.haskell.org/D4690 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 14 02:53:06 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 May 2018 02:53:06 -0000 Subject: [GHC] #14890: Make Linux slow validate green In-Reply-To: <046.a107a76cbb0183d36ada5ee5738b1b26@haskell.org> References: <046.a107a76cbb0183d36ada5ee5738b1b26@haskell.org> Message-ID: <061.6c7fd78d12576800cab34c98f843ea27@haskell.org> #14890: Make Linux slow validate green -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alpmestan Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D4546 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"ca3d3039386b145ae2835ca563b4c5a3497c25c9/ghc" ca3d3039/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ca3d3039386b145ae2835ca563b4c5a3497c25c9" Fix another batch of `./validate --slow` failures A rather detailed summary can be found at: https://gist.github.com/alpmestan/be82b47bb88b7dc9ff84105af9b1bb82 This doesn't fix all expectation mismatches yet, but we're down to about 20 mismatches with my previous patch and this one, as opposed to ~150 when I got started. Test Plan: ./validate --slow Reviewers: bgamari, erikd, simonmar Reviewed By: simonmar Subscribers: thomie, carter GHC Trac Issues: #14890 Differential Revision: https://phabricator.haskell.org/D4636 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 14 04:07:56 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 May 2018 04:07:56 -0000 Subject: [GHC] #15131: Speed up certain Foldable NonEmpty methods In-Reply-To: <045.a14e4452f4631f3337e0e1509638b7cc@haskell.org> References: <045.a14e4452f4631f3337e0e1509638b7cc@haskell.org> Message-ID: <060.5008e86eb55cfec391c0d68deb88b033@haskell.org> #15131: Speed up certain Foldable NonEmpty methods -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4677 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"b7139869c3c42c778fa9eb90058439323f548ec2/ghc" b7139869/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b7139869c3c42c778fa9eb90058439323f548ec2" Improve some Foldable methods for NonEmpty * `length` is improved by using the default definition, while `foldr1` is improved by using a custom one. * Several methods had useless lazy pattern matches (i.e., the functions were actually strict in those arguments). Remove `~`s to clarify. Reviewers: hvr, bgamari, mpickering, nomeata Reviewed By: bgamari Subscribers: ygale, rwbarton, thomie, carter GHC Trac Issues: #15131 Differential Revision: https://phabricator.haskell.org/D4677 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 14 05:38:00 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 May 2018 05:38:00 -0000 Subject: [GHC] #8400: Migrate the RTS to use libuv (or libev, or libevent) In-Reply-To: <046.b38bad0bbb5fef315e7819ac07954a6b@haskell.org> References: <046.b38bad0bbb5fef315e7819ac07954a6b@haskell.org> Message-ID: <061.969048f50848f166bf64b3adb6db06ad@haskell.org> #8400: Migrate the RTS to use libuv (or libev, or libevent) -------------------------------------+------------------------------------- Reporter: schyler | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 635, 7353 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by maoe): * cc: maoe (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 14 07:47:38 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 May 2018 07:47:38 -0000 Subject: [GHC] #13167: GC and weak reference finalizers and exceptions In-Reply-To: <044.f73010a4958317dc6bb4779ffc938be2@haskell.org> References: <044.f73010a4958317dc6bb4779ffc938be2@haskell.org> Message-ID: <059.9494a41fb73ffbbf027d4dcd4ce25509@haskell.org> #13167: GC and weak reference finalizers and exceptions -------------------------------------+------------------------------------- Reporter: Yuras | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * cc: Phyx- (added) Comment: Replying to [comment:2 simonmar]: > Yes, this is technically a bug. We could have `runFinalizerBatch` catch and discard exceptions (or print them to stdout; it's really a bug if a finalizer throws an exception). Any suggestions on how? the I/O manager seems to rely on using finalizers to flush buffers, however for some reason my new I/O manager's finalizers never get called. I assume because something else threw an exception. I've modified `runFinalizerBatch` to handle exceptions (unless I misunderstood the code) {{{ runFinalizerBatch :: Int -> Array# (State# RealWorld -> State# RealWorld) -> IO () runFinalizerBatch (I# n) arr = let go m = IO $ \s -> case m of 0# -> (# s, () #) _ -> let !m' = m -# 1# in case indexArray# arr m' of { (# io #) -> case catch# (\p -> (# io p, () #)) (\_ s'' -> (# s'', () #)) s of { (# s', _ #) -> unIO (go m') s' }} in go n }}} With `mio` the output varies between `..` and `....`, so not very deterministic. with `winio` none of it ever runs... Any ideas what else might be making these handlers not run at all? or how I can debug this? for `winio` I can imagine one of the finalizers deadlocking, an ffi call maybe. But the mio output is strange. If we're going to rely on them for managing handles and buffers they would ideally be a bit more robust... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 14 07:54:52 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 May 2018 07:54:52 -0000 Subject: [GHC] #14068: Loopification using join points In-Reply-To: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> References: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> Message-ID: <061.70f15c89650f3831efa7ac892e8ae7be@haskell.org> #14068: Loopification using join points -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13966 #14067 | Differential Rev(s): Phab:D3811 #14827 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > If these were fixed we would get rid of some of the SpecConstr related regressions introduced by loopification – but still not all of them, I fear, and there will be more to be tracked down. But these are good things to track, more generally. A program might be loopified by hand, so making loopification be non-regressive should benefit all programs. Another possible thing to try is to loopify after !SpecConstr; that is, treat loopificaiton as an optimisation whose main payoff is in the back end. (One reason I am keen to move forward with loopificaion is because then we can remove some rather ad-hoc loopification code in the code generator.) But I don't have a clear picture of where the wins from loopification come. Maybe there are benefits earlier in the pipeline. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 14 07:56:18 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 May 2018 07:56:18 -0000 Subject: [GHC] #13167: GC and weak reference finalizers and exceptions In-Reply-To: <044.f73010a4958317dc6bb4779ffc938be2@haskell.org> References: <044.f73010a4958317dc6bb4779ffc938be2@haskell.org> Message-ID: <059.3f928385ff2e857668dea59be0447d72@haskell.org> #13167: GC and weak reference finalizers and exceptions -------------------------------------+------------------------------------- Reporter: Yuras | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): The example program in the description doesn't wait for the finalizer threads to complete, so it might exit while there are still finalizers alive. This is why you don't see deterministic output. Probably adding a `threadDelay 1000000` at the end would be enough. A deadlock sounds like a plausible explanation for the behaviour you're seeing. The fix to `runFinalizerBatch` looks good - we should probably do that anyway (I'm sure you could construct a test case to demonstrate the problem that it fixes). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 14 08:10:00 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 May 2018 08:10:00 -0000 Subject: [GHC] #13167: GC and weak reference finalizers and exceptions In-Reply-To: <044.f73010a4958317dc6bb4779ffc938be2@haskell.org> References: <044.f73010a4958317dc6bb4779ffc938be2@haskell.org> Message-ID: <059.fd9c0556aac6c07201be1170eeaf6830@haskell.org> #13167: GC and weak reference finalizers and exceptions -------------------------------------+------------------------------------- Reporter: Yuras | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): ah indeed, `threadDelay` worked! Ok I'll whip up a testcase and patch. I'll see if I can't add some debug code to figure out which finalizer is deadlocking. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 14 10:47:18 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 May 2018 10:47:18 -0000 Subject: [GHC] #15148: Allow setting of custom alignments Message-ID: <047.65d79bc1b0303b6249ecd616495d5687@haskell.org> #15148: Allow setting of custom alignments -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 (NCG) | Keywords: CodeGen | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #15124 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Alignment can introduce a bias to benchmarking results which isn't obvious. To help deal with that I want to add some options adjusting alignment for generated code. To give one example I came across while looking into #15124: Padding a function that **is not even called** in nofib/real/eff/FS by multiples of 8 bytes gave runtimes of ~240ms, ~220ms and ~210ms depending on the padding. At 64 byte it seems to loop around (size of a cache line). At a minimum it should be possible to specify alignment of functions. Potentially we could also consider: * Padding for sections. * Padding for functions * Alignment for info tables. * Padding for info tables. * Alignment for Data The cases where this could have benefits: ---- Problem: We optimize one subroutine changing it's size. This leads to alignment changes for the following functions making overall performance potentially worse. Here aligning functions along cache lines would make benchmarks more resilient against accidental alignment changes. ---- Problem: We might try to optimize code based on a specific benchmark. Going purely by performance of this benchmark we might end up optimizing our code for this specific benchmark instead of the general case. Varying the alignment would to check if our code simply found a optimum for the alignment caused by this benchmark or if it is generally better. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 14 10:56:15 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 May 2018 10:56:15 -0000 Subject: [GHC] #15149: Identical distinct type family fields miscompiled Message-ID: <051.0ce70e3fb52ab219faaf194260ba75f3@haskell.org> #15149: Identical distinct type family fields miscompiled -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Keywords: | 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: -------------------------------------+------------------------------------- Given the code: {{{#!hs -- An.hs {-# LANGUAGE TypeFamilies #-} module An where data family An c :: * -- AnInt.hs {-# LANGUAGE TypeFamilies #-} module AnInt where import An data instance An Int = AnInt {an :: Int} deriving Show -- AnDouble.hs {-# LANGUAGE TypeFamilies #-} module AnDouble where import An data instance An Double = AnDouble {an :: Double} deriving Show -- Main.hs {-# LANGUAGE DisambiguateRecordFields #-} module Main where import AnInt import AnDouble main = print (AnDouble{an=1}, AnInt{an=1}) }}} I would expect this code to work. In reality it fails at runtime with GHC 8.2.2: {{{ Main.hs:4:15-28: warning: [-Wmissing-fields] * Fields of `AnDouble' not initialised: an * In the expression: AnDouble {an = 1} In the first argument of `print', namely `(AnDouble {an = 1}, AnInt {an = 1})' In the expression: print (AnDouble {an = 1}, AnInt {an = 1}) | 6 | main = print (AnDouble{an=1}, AnInt{an=1}) | ^^^^^^^^^^^^^^ *** Exception: Main.hs:4:15-28: Missing field in record construction an }}} And fails at compile time in GHC 8.4.2: {{{ Main.hs:4:31-41: error: * Constructor `AnInt' does not have field `an' * In the expression: AnInt {an = 1} In the first argument of `print', namely `(AnDouble {an = 1}, AnInt {an = 1})' In the expression: print (AnDouble {an = 1}, AnInt {an = 1}) | 6 | main = print (AnDouble{an=1}, AnInt{an=1}) | ^^^^^^^^^^^ }}} This code was extracted from a real example, where this bug is pretty fatal, as I haven't been able to find any workarounds (without just avoiding clashing record fields). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 14 12:12:14 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 May 2018 12:12:14 -0000 Subject: [GHC] #15112: ghc 8.4.2 on OS X: clang: warning: argument unused during compilation: '-nopie' In-Reply-To: <047.e2e05ed138c24fadcd4842fa8e08b91d@haskell.org> References: <047.e2e05ed138c24fadcd4842fa8e08b91d@haskell.org> Message-ID: <062.f308a10215936c0e2159e65c7449126a@haskell.org> #15112: ghc 8.4.2 on OS X: clang: warning: argument unused during compilation: '-nopie' ---------------------------------+---------------------------------------- Reporter: elaforge | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by niteria): I couldn't build GHC HEAD with GHC 8.2.2 because of this error. Modifying `/usr/local/lib/ghc-8.2.2/settings` to: {{{ ... ("C compiler supports -no-pie", "NO"), ... }}} worked it around for me. Perhaps a reinstall works as well, I haven't tried. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 14 12:13:12 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 May 2018 12:13:12 -0000 Subject: [GHC] #15149: Identical distinct type family fields miscompiled In-Reply-To: <051.0ce70e3fb52ab219faaf194260ba75f3@haskell.org> References: <051.0ce70e3fb52ab219faaf194260ba75f3@haskell.org> Message-ID: <066.ba8be5ddd1a536e1e4ad320fbc34bbfa@haskell.org> #15149: Identical distinct type family fields miscompiled -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: ORF 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => ORF -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 14 12:19:12 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 May 2018 12:19:12 -0000 Subject: [GHC] #15067: When Typeable and unboxed sums collide, GHC panics In-Reply-To: <050.61b6b35d8587a28e0de8c6a6604fc205@haskell.org> References: <050.61b6b35d8587a28e0de8c6a6604fc205@haskell.org> Message-ID: <065.b9a45e6b84a5cf7ff6469fa7e2aa86e2@haskell.org> #15067: When Typeable and unboxed sums collide, GHC panics -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.1 checker) | Keywords: Typeable, Resolution: fixed | UnboxedSums Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | typecheck/should_fail/T15067 Blocked By: | Blocking: Related Tickets: #13276 | Differential Rev(s): Phab:D4622, Wiki Page: | Phab:D4623 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => typecheck/should_fail/T15067 * status: patch => closed * resolution: => fixed Comment: Thanks, Ben! #13276 tracks the remaining issue of making unboxed sum type/data constructors `Typeable`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 14 12:27:13 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 May 2018 12:27:13 -0000 Subject: [GHC] #15142: GHC HEAD regression: tcTyVarDetails In-Reply-To: <050.e98a1ae073f44bf5c57814edebb43575@haskell.org> References: <050.e98a1ae073f44bf5c57814edebb43575@haskell.org> Message-ID: <065.7747dd598d9c60f13df980cfb84b839e@haskell.org> #15142: GHC HEAD regression: tcTyVarDetails -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: TypeInType, Resolution: | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Further observations: * `MultiParamTypeClasses` is also important to triggering this, since this panics: {{{#!hs {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind class C (a :: Type) (b :: k) where type T b }}} But not this: {{{#!hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind class C (b :: k) where type T b }}} * The order of arguments to `C`, as well as the exact kind signatures given to them, also appears to be important, as none of the following panics: {{{#!hs {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind class C1 (b :: k) (a :: Type) where type T1 b class C2 b (a :: Type) where type T2 b class C3 b a where type T3 b class C4 (b :: k) a where type T4 b class C5 a (b :: k) where type T5 b class C6 (a :: Type) b where type T6 b class C7 a b where type T7 b }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 14 12:44:06 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 May 2018 12:44:06 -0000 Subject: [GHC] #15144: Type inference regression between GHC 8.0.2 and 8.2.2 In-Reply-To: <050.be8ee3d4bba9d11a883dc98882f5b18d@haskell.org> References: <050.be8ee3d4bba9d11a883dc98882f5b18d@haskell.org> Message-ID: <065.b2644912e195c68806cf298014819e92@haskell.org> #15144: Type inference regression between GHC 8.0.2 and 8.2.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): What's odd is that things work out alright if I write an explicit type signature: {{{#!hs g :: Coercible (F a) b => Proxy a -> F a -> b g p x = f p x }}} It's only when the type is inferred that it becomes less general. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 14 12:50:03 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 May 2018 12:50:03 -0000 Subject: [GHC] #14973: Location in GHCi debugger prompt printed twice when default prompt is used In-Reply-To: <043.77b079247cf81e1c9a49efb3c90c1743@haskell.org> References: <043.77b079247cf81e1c9a49efb3c90c1743@haskell.org> Message-ID: <058.a0d47a2464385366deea334d8b9d6e00@haskell.org> #14973: Location in GHCi debugger prompt printed twice when default prompt is used -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.5 Resolution: | Keywords: debugger Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4661 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"e408d03b512f353067879ecdb5be4b6e48cf0431/ghc" e408d03b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e408d03b512f353067879ecdb5be4b6e48cf0431" Fix #14973 Reviewers: bgamari Reviewed By: bgamari Subscribers: thomie, carter Differential Revision: https://phabricator.haskell.org/D4661 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 14 13:06:36 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 May 2018 13:06:36 -0000 Subject: [GHC] #11066: Inacessible branch should be warning - otherwise breaks type soundness? In-Reply-To: <047.0785946e31f05741dc32414264d84d16@haskell.org> References: <047.0785946e31f05741dc32414264d84d16@haskell.org> Message-ID: <062.f7e8739ec070abbb42119f4ff3fd5f75@haskell.org> #11066: Inacessible branch should be warning - otherwise breaks type soundness? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #8128, #8740 | Differential Rev(s): Phab:D1454 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): It turns out that `T3651` doesn't fail the right way if we turn this error into a warning and then compile with `-Werror`, because the core linter errors out first, so instead of the errorized warning, we see the core linter failure. Manually compiling with just `-Werror` (but not `-dcore- lint`) does produce the desired behavior. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 14 13:08:15 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 May 2018 13:08:15 -0000 Subject: [GHC] #15150: Difference between 'libicuio' and 'icuio' in the 'extra-libraries' field Message-ID: <048.c7f9cdf75d4b8994697a313f39fc3697@haskell.org> #15150: Difference between 'libicuio' and 'icuio' in the 'extra-libraries' field --------------------------------------+------------------------------- Reporter: Darwin226 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.2 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+------------------------------- I'm on Windows and I've recently updated my msys packages. One of them was libicu which I updated from version 58 to version 61. This caused one of my projects to stop building. I've managed to reproduce the problem by just cloning the text-icu package and trying to open the repl in it. This is the error I get: {{{ GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help ghc.EXE: | C:\Users\darwi\Projects\text-icu\.stack- work\dist\5c8418a7\build\cbits\text_icu.o: unknown symbol `ucnv_getMaxCharSize_61' linking extra libraries/objects failed }}} A similar error used to happen with icu 58, but I've "fixed" it (see this pull request https://github.com/bos/text-icu/pull/36). This time, however, adding `icuio` to `extra-libraries` doesn't cut it. But adding `libicuio` does the trick! I'm opening a ticket here because I assume both of those should behave the same. It's worth noting that if this is a bug, it's not just a GHCi issue. My other project that depends on text-icu just doesn't build (the same error happens during compilation). Unfortunately I can't test on 8.4 right now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 14 13:27:26 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 May 2018 13:27:26 -0000 Subject: [GHC] #15019: Fix performance regressions from #14737 In-Reply-To: <047.36d31dd41a03f5d1b4531d3b52b0f31a@haskell.org> References: <047.36d31dd41a03f5d1b4531d3b52b0f31a@haskell.org> Message-ID: <062.117780075ed94b6f2e2530bc173fb452@haskell.org> #15019: Fix performance regressions from #14737 -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #14737 | Differential Rev(s): phab:D4635 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"d92c7556501a4cdeb7d269c4624992c94d9b3b8b/ghc" d92c755/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d92c7556501a4cdeb7d269c4624992c94d9b3b8b" Fix performance regressions from #14737 See #15019. When removing an unnecessary type equality check in #14737, several regression tests failed. The cause was that some coercions that are actually Refl coercions weren't passed in as such, which made the equality check needlessly complex (Refl coercions can be discarded in this particular check immediately, without inspecting the types at all). We fix that, and get additional performance improvements for free. Reviewers: goldfire, bgamari, simonpj Reviewed By: bgamari, simonpj Subscribers: simonpj, thomie, carter Differential Revision: https://phabricator.haskell.org/D4635 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 14 13:27:26 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 May 2018 13:27:26 -0000 Subject: [GHC] #14737: Improve performance of Simplify.simplCast In-Reply-To: <047.69092b5e7fccc6314d7cb05c5e8b2174@haskell.org> References: <047.69092b5e7fccc6314d7cb05c5e8b2174@haskell.org> Message-ID: <062.d9cd4affc88e7e30fe0f476af70a9619@haskell.org> #14737: Improve performance of Simplify.simplCast -------------------------------------+------------------------------------- Reporter: tdammers | Owner: goldfire Type: bug | Status: patch Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #11735 #14683 | Differential Rev(s): Phab:D4385 Wiki Page: | Phab:D4568 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"d92c7556501a4cdeb7d269c4624992c94d9b3b8b/ghc" d92c755/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d92c7556501a4cdeb7d269c4624992c94d9b3b8b" Fix performance regressions from #14737 See #15019. When removing an unnecessary type equality check in #14737, several regression tests failed. The cause was that some coercions that are actually Refl coercions weren't passed in as such, which made the equality check needlessly complex (Refl coercions can be discarded in this particular check immediately, without inspecting the types at all). We fix that, and get additional performance improvements for free. Reviewers: goldfire, bgamari, simonpj Reviewed By: bgamari, simonpj Subscribers: simonpj, thomie, carter Differential Revision: https://phabricator.haskell.org/D4635 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 14 13:28:55 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 May 2018 13:28:55 -0000 Subject: [GHC] #15151: Better Interaction Specialization and GND Message-ID: <049.4c9d715f37d1146ca95fc1f1e65b6621@haskell.org> #15151: Better Interaction Specialization and GND -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- Let us consider the following code: {{{ -- Sort.hs sort :: (Prim a, Ord a) => MutablePrimArray s a -> ST s () sort mutArr = ... {-# SPECIALIZE sort :: MutablePrimArray s Int -> ST s () -#} {-# SPECIALIZE sort :: MutablePrimArray s Int8 -> ST s () -#} {-# SPECIALIZE sort :: MutablePrimArray s Word8 -> ST s () -#} ... }}} For reference, a `MutablePrimArray` is a `MutableByteArray` with a phantom type variable to tag the element type. This sorting algorithm may be implemented in any number of ways, and the implementation is unimportant here. The specialize pragmas are intended to capture a number of common use cases. Here's where a problem arises: {{{ -- Example.hs newtype PersonId = PersonId Int deriving (Eq,Ord,Prim) sortPeople :: MutablePrimArray s PersonId -> MutablePrimArray s PersonId sortPeople x = sort x }}} There isn't a rewrite rule that specializes the `sort` function when we are dealing with `PersonId`. So, we end up with a slower version of the code that explicitly passes all the dictionaries. One solution would be to just use `INLINABLE` instead. Then we don't have to try to list every type, and we just let the specialization be generate at the call site. But this isn't totally satisfying. There are a lot of types that are just newtype wrappers around `Int`. Why should we have an extra copy of the same code for each of them? (Even without newtypes, `INLINABLE` can still result in duplication if neither of the modules that needs a specialization transitively imports the other). What I'm suggesting is that rewrite rules (like those generated by `SPECIALIZE`) could target not just the given type but also any newtype around it, provided that all typeclass instances required by the function were the result of GND. The only situations where this is unsound are situations where the user was already doing something unsound with rewrite rules. There are several implementation difficulties: * In core, there is no good way to tell that a typeclass instance dictionary was the result of GND. I'm not sure how to work around this. * `Eq` and `Ord` usually aren't handled by the `newtype` deriving strategy. They are handled by the `stock` strategy, which produces code with equivalent behavior but is nevertheless different code. * The rewrite rule would need to look at additional arguments beyond the type arguments. I suspect that these difficulties would make such this feature difficult to implement, but this feature would help me with some of my libraries and applications. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 14 13:28:59 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 May 2018 13:28:59 -0000 Subject: [GHC] #14381: Consider making ghc-pkg fill in abi-depends based on depends In-Reply-To: <045.a757b4d974e51bd6ab6f6869ba65de4c@haskell.org> References: <045.a757b4d974e51bd6ab6f6869ba65de4c@haskell.org> Message-ID: <060.75c8243402523a704ad507dd55774479@haskell.org> #14381: Consider making ghc-pkg fill in abi-depends based on depends -------------------------------------+------------------------------------- Reporter: ezyang | Owner: tdammers Type: bug | Status: new Priority: highest | Milestone: 8.4.2 Component: ghc-pkg | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4159 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: thoughtpolice => tdammers Comment: Tobias will have a look at this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 14 13:29:11 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 May 2018 13:29:11 -0000 Subject: [GHC] #15151: Better Interaction Between Specialization and GND (was: Better Interaction Specialization and GND) In-Reply-To: <049.4c9d715f37d1146ca95fc1f1e65b6621@haskell.org> References: <049.4c9d715f37d1146ca95fc1f1e65b6621@haskell.org> Message-ID: <064.28867f8d8756443174215833732a8b0b@haskell.org> #15151: Better Interaction Between Specialization and GND -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 14 13:31:50 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 May 2018 13:31:50 -0000 Subject: [GHC] #15131: Speed up certain Foldable NonEmpty methods In-Reply-To: <045.a14e4452f4631f3337e0e1509638b7cc@haskell.org> References: <045.a14e4452f4631f3337e0e1509638b7cc@haskell.org> Message-ID: <060.40f3b9d8cc5e58ea28ccd1c1222316a3@haskell.org> #15131: Speed up certain Foldable NonEmpty methods -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4677 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 14 13:33:29 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 May 2018 13:33:29 -0000 Subject: [GHC] #15150: Difference between 'libicuio' and 'icuio' in the 'extra-libraries' field In-Reply-To: <048.c7f9cdf75d4b8994697a313f39fc3697@haskell.org> References: <048.c7f9cdf75d4b8994697a313f39fc3697@haskell.org> Message-ID: <063.81283135808d918da701166be4ff897f@haskell.org> #15150: Difference between 'libicuio' and 'icuio' in the 'extra-libraries' field -------------------------------+-------------------------------------- Reporter: Darwin226 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Comment (by Phyx-): Would you be using Windows 10? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 14 13:37:56 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 May 2018 13:37:56 -0000 Subject: [GHC] #15150: Difference between 'libicuio' and 'icuio' in the 'extra-libraries' field In-Reply-To: <048.c7f9cdf75d4b8994697a313f39fc3697@haskell.org> References: <048.c7f9cdf75d4b8994697a313f39fc3697@haskell.org> Message-ID: <063.34e2e239f5ee42857b59e916db873af2@haskell.org> #15150: Difference between 'libicuio' and 'icuio' in the 'extra-libraries' field -------------------------------+-------------------------------------- Reporter: Darwin226 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Comment (by Darwin226): Indeed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 14 13:40:53 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 May 2018 13:40:53 -0000 Subject: [GHC] #15019: Fix performance regressions from #14737 In-Reply-To: <047.36d31dd41a03f5d1b4531d3b52b0f31a@haskell.org> References: <047.36d31dd41a03f5d1b4531d3b52b0f31a@haskell.org> Message-ID: <062.4accfff42d60f1b8f98d46da48e389de@haskell.org> #15019: Fix performance regressions from #14737 -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #14737 | Differential Rev(s): phab:D4635 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): The patch in comment:23 (hooray) claims to fix three perf regressions, and get other improvement for free. Yet the patch only changes one perf number in `perf/compiler/all.T`, plus (oddly) one other comment. What's up here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 14 13:53:43 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 May 2018 13:53:43 -0000 Subject: [GHC] #15019: Fix performance regressions from #14737 In-Reply-To: <047.36d31dd41a03f5d1b4531d3b52b0f31a@haskell.org> References: <047.36d31dd41a03f5d1b4531d3b52b0f31a@haskell.org> Message-ID: <062.bfc4da33ac4362b396e47d66f9f6530e@haskell.org> #15019: Fix performance regressions from #14737 -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #14737 | Differential Rev(s): phab:D4635 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Hmm, the comment change was due to my conflict resolution. For better or worse the numbers currently in `all.T` passed validation locally, so I can only guess that some of the numbers are now marginal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 14 14:00:33 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 May 2018 14:00:33 -0000 Subject: [GHC] #15019: Fix performance regressions from #14737 In-Reply-To: <047.36d31dd41a03f5d1b4531d3b52b0f31a@haskell.org> References: <047.36d31dd41a03f5d1b4531d3b52b0f31a@haskell.org> Message-ID: <062.3f52e1e5f02fb8cfa3ba31ee44ec0110@haskell.org> #15019: Fix performance regressions from #14737 -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #14737 | Differential Rev(s): phab:D4635 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): T12425 at least does not look like it could possibly have become marginal. We went from 141952368 after #14747 (non-marginally up) to 130646336 in #15019 (non-marginally down), and now back up to 150743648 in this patch, which is even higher than the original value post-#14747. So this is somewhat curious IMO. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 14 14:27:41 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 May 2018 14:27:41 -0000 Subject: [GHC] #15151: Better Interaction Between Specialization and GND In-Reply-To: <049.4c9d715f37d1146ca95fc1f1e65b6621@haskell.org> References: <049.4c9d715f37d1146ca95fc1f1e65b6621@haskell.org> Message-ID: <064.5cae016e7d6147a52643c8ca0a9834a5@haskell.org> #15151: Better Interaction Between Specialization and GND -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I'm afraid I don't quite understand what you're proposing. Can you provide an example of the code that is currently generated, and an example of the code you wish would be generated? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 14 14:34:02 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 May 2018 14:34:02 -0000 Subject: [GHC] #15150: Difference between 'libicuio' and 'icuio' in the 'extra-libraries' field In-Reply-To: <048.c7f9cdf75d4b8994697a313f39fc3697@haskell.org> References: <048.c7f9cdf75d4b8994697a313f39fc3697@haskell.org> Message-ID: <063.05b3f11b81e55871867f50e8580ec296@haskell.org> #15150: Difference between 'libicuio' and 'icuio' in the 'extra-libraries' field -------------------------------+-------------------------------------- Reporter: Darwin226 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.2 Resolution: duplicate | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: 14456 | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Changes (by Phyx-): * status: new => closed * cc: bgamari (added) * resolution: => duplicate * related: => 14456 Comment: This is a duplicate of #14456, you're hitting an issue where Microsoft has started shipping `icuuc` in Windows. GHCi is picking up this version but the version doesn't seem usable due to different symbol names. It's been fixed in 8.4. using `lib` is explicitly forcing it to pick the `import library, libicuio.dll.a` which directs it to the right dll. Under normal circumstances, those (libicuio vs icuio) two are *roughly* equivalent. There are some diffences but it should all work out to the same if you have your environment correct. I'm closing it as a duplicate. I'm not sure the release manager would agree that this should be backported into the up and coming ghc 8.4.3 bug- fix release for ubuntu. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 14 14:46:21 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 May 2018 14:46:21 -0000 Subject: [GHC] #11066: Inacessible branch should be warning - otherwise breaks type soundness? In-Reply-To: <047.0785946e31f05741dc32414264d84d16@haskell.org> References: <047.0785946e31f05741dc32414264d84d16@haskell.org> Message-ID: <062.e1115e6f07503465435fa6432790d145@haskell.org> #11066: Inacessible branch should be warning - otherwise breaks type soundness? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #8128, #8740 | Differential Rev(s): Phab:D1454 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): The following patch turns the "Inaccessible" error into a warning: {{{ commit f4f9c0fc9564f17339718378e9fea3bd186fff96 Author: Tobias Dammers Date: Tue May 8 13:54:28 2018 +0200 [WIP] turn "inaccessible code" error into a warning (#11066) diff --git a/compiler/typecheck/TcErrors.hs b/compiler/typecheck/TcErrors.hs index dde7c3c75a..2d3af68008 100644 --- a/compiler/typecheck/TcErrors.hs +++ b/compiler/typecheck/TcErrors.hs @@ -708,7 +708,7 @@ mkGivenErrorReporter implic ctxt cts Nothing ty1 ty2 ; traceTc "mkGivenErrorReporter" (ppr ct) - ; maybeReportError ctxt err } + ; reportWarning NoReason err } where (ct : _ ) = cts -- Never empty (ty1, ty2) = getEqPredTys (ctPred ct) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 14 15:00:38 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 May 2018 15:00:38 -0000 Subject: [GHC] #15152: Core Lint error in ill-typed GADT code Message-ID: <047.18c2cbc6ba40b8b60bd69a6b876e50e1@haskell.org> #15152: Core Lint error in ill-typed GADT code -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #11066 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following program: {{{ {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeFamilies #-} module T3651 where data Z a where U :: Z () B :: Z Bool unsafe2 :: a ~ b => Z b -> Z a -> a unsafe2 B U = () }}} On current GHC HEAD, this fails with an "Inaccessible branch" error. However, if we turn this error into a warning, e.g. using the following patch: {{{ --- a/compiler/typecheck/TcErrors.hs +++ b/compiler/typecheck/TcErrors.hs @@ -708,7 +708,7 @@ mkGivenErrorReporter implic ctxt cts Nothing ty1 ty2 ; traceTc "mkGivenErrorReporter" (ppr ct) - ; maybeReportError ctxt err } + ; reportWarning NoReason err } where (ct : _ ) = cts -- Never empty (ty1, ty2) = getEqPredTys (ctPred ct) }}} ...and then compile with `-dcore-lint -Werror`, the program gets rejected with a core lint error: {{{ [1 of 1] Compiling T3651 ( minimal.hs, minimal.o ) *** Core Lint errors : in result of Desugar (before optimization) *** : warning: In a case alternative: (U co_a1ri :: (a_a1rd :: *) ~# (() :: *)) Unfilled coercion hole: {co_a1rw} : warning: In a case alternative: (U co_a1ri :: (a_a1rd :: *) ~# (() :: *)) co_a1rw :: (() :: *) ~# (Bool :: *) [LclId[CoVarId]] is out of scope *** Offending Program *** Rec { $tcZ :: TyCon [LclIdX] $tcZ = TyCon 5287023927886307113## 7998054209879401454## $trModule (TrNameS "Z"#) 0# krep$*Arr* $tc'U :: TyCon [LclIdX] $tc'U = TyCon 5625905484817226555## 8662083060712566586## $trModule (TrNameS "'U"#) 0# $krep_a1sr $tc'B :: TyCon [LclIdX] $tc'B = TyCon 477146386442824276## 11145321492051770584## $trModule (TrNameS "'B"#) 0# $krep_a1st $krep_a1sr [InlPrag=NOUSERINLINE[~]] :: KindRep [LclId] $krep_a1sr = KindRepTyConApp $tcZ (: @ KindRep $krep_a1ss ([] @ KindRep)) $krep_a1st [InlPrag=NOUSERINLINE[~]] :: KindRep [LclId] $krep_a1st = KindRepTyConApp $tcZ (: @ KindRep $krep_a1su ([] @ KindRep)) $krep_a1ss [InlPrag=NOUSERINLINE[~]] :: KindRep [LclId] $krep_a1ss = KindRepTyConApp $tc() ([] @ KindRep) $krep_a1su [InlPrag=NOUSERINLINE[~]] :: KindRep [LclId] $krep_a1su = KindRepTyConApp $tcBool ([] @ KindRep) $trModule :: Module [LclIdX] $trModule = Module (TrNameS "main"#) (TrNameS "T3651"#) unsafe2 :: forall a b. ((a :: *) ~ (b :: *)) => Z b -> Z a -> a [LclIdX] unsafe2 = \ (@ a_a1rd) (@ b_a1re) ($d~_a1rg :: (a_a1rd :: *) ~ (b_a1re :: *)) -> let { $d~~_a1ro :: (a_a1rd :: *) ~~ (b_a1re :: *) [LclId] $d~~_a1ro = $p1~ @ * @ a_a1rd @ b_a1re $d~_a1rg } in case heq_sel @ * @ * @ a_a1rd @ b_a1re $d~~_a1ro of co_a1rp { __DEFAULT -> \ (ds_d1sv :: Z b_a1re) (ds_d1sw :: Z a_a1rd) -> let { fail_d1tc :: Void# -> a_a1rd [LclId] fail_d1tc = \ (ds_d1td [OS=OneShot] :: Void#) -> patError @ 'LiftedRep @ a_a1rd "minimal.hs:12:1-16|function unsafe2"# } in case ds_d1sv of wild_00 { __DEFAULT -> fail_d1tc void#; B co_a1rh -> let { co_a1ru :: (a_a1rd :: *) ~# (Bool :: *) [LclId[CoVarId]] co_a1ru = CO: co_a1rp ; co_a1rh } in case ds_d1sw of wild_00 { __DEFAULT -> fail_d1tc void#; U co_a1ri -> () `cast` (Sub ({co_a1rw} ; Sym co_a1ru) :: (() :: *) ~R# (a_a1rd[sk:2] :: *)) } } } end Rec } *** End of Offense *** : error: Compilation had errors }}} However, without core linting, the correct errors appear: {{{ [1 of 1] Compiling T3651 ( minimal.hs, minimal.o ) minimal.hs:12:1: error: [-Woverlapping-patterns, -Werror=overlapping- patterns] Pattern match has inaccessible right hand side In an equation for ‘unsafe2’: unsafe2 B U = ... | 12 | unsafe2 B U = () | ^^^^^^^^^^^^^^^^ minimal.hs:12:11: error: [-Werror] • Couldn't match type ‘Bool’ with ‘()’ Inaccessible code in a pattern with constructor: U :: Z (), in an equation for ‘unsafe2’ • In the pattern: U In an equation for ‘unsafe2’: unsafe2 B U = () | 12 | unsafe2 B U = () | ^ }}} Without either core linting or `-Werror`, GHC just emits the warnings, and then falls into a hole: {{{ [1 of 1] Compiling T3651 ( minimal.hs, minimal.o ) minimal.hs:12:1: warning: [-Woverlapping-patterns] Pattern match has inaccessible right hand side In an equation for ‘unsafe2’: unsafe2 B U = ... | 12 | unsafe2 B U = () | ^^^^^^^^^^^^^^^^ minimal.hs:12:11: warning: • Couldn't match type ‘Bool’ with ‘()’ Inaccessible code in a pattern with constructor: U :: Z (), in an equation for ‘unsafe2’ • In the pattern: U In an equation for ‘unsafe2’: unsafe2 B U = () | 12 | unsafe2 B U = () | ^ ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.5.20180508 for x86_64-unknown-linux): opt_univ fell into a hole {co_a1rw} Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1162:37 in ghc:Outputable pprPanic, called at compiler/types/OptCoercion.hs:242:5 in ghc:OptCoercion Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 14 15:02:52 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 May 2018 15:02:52 -0000 Subject: [GHC] #15152: Core Lint error in ill-typed GADT code In-Reply-To: <047.18c2cbc6ba40b8b60bd69a6b876e50e1@haskell.org> References: <047.18c2cbc6ba40b8b60bd69a6b876e50e1@haskell.org> Message-ID: <062.94749a9959e3d72cf8fff6215dcb8a9d@haskell.org> #15152: Core Lint error in ill-typed GADT code -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11066 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: simonpj (added) Old description: > Consider the following program: > > {{{ > {-# LANGUAGE GADTs #-} > {-# LANGUAGE TypeFamilies #-} > > module T3651 where > > data Z a where > U :: Z () > B :: Z Bool > > unsafe2 :: a ~ b => Z b -> Z a -> a > unsafe2 B U = () > }}} > > On current GHC HEAD, this fails with an "Inaccessible branch" error. > However, if we turn this error into a warning, e.g. using the following > patch: > > {{{ > --- a/compiler/typecheck/TcErrors.hs > +++ b/compiler/typecheck/TcErrors.hs > @@ -708,7 +708,7 @@ mkGivenErrorReporter implic ctxt cts > Nothing ty1 ty2 > > ; traceTc "mkGivenErrorReporter" (ppr ct) > - ; maybeReportError ctxt err } > + ; reportWarning NoReason err } > where > (ct : _ ) = cts -- Never empty > (ty1, ty2) = getEqPredTys (ctPred ct) > }}} > > ...and then compile with `-dcore-lint -Werror`, the program gets rejected > with a core lint error: > > {{{ > [1 of 1] Compiling T3651 ( minimal.hs, minimal.o ) > *** Core Lint errors : in result of Desugar (before optimization) *** > : warning: > In a case alternative: (U co_a1ri :: (a_a1rd :: *) ~# (() :: *)) > Unfilled coercion hole: {co_a1rw} > : warning: > In a case alternative: (U co_a1ri :: (a_a1rd :: *) ~# (() :: *)) > co_a1rw :: (() :: *) ~# (Bool :: *) > [LclId[CoVarId]] is out of scope > *** Offending Program *** > Rec { > $tcZ :: TyCon > [LclIdX] > $tcZ > = TyCon > 5287023927886307113## > 7998054209879401454## > $trModule > (TrNameS "Z"#) > 0# > krep$*Arr* > > $tc'U :: TyCon > [LclIdX] > $tc'U > = TyCon > 5625905484817226555## > 8662083060712566586## > $trModule > (TrNameS "'U"#) > 0# > $krep_a1sr > > $tc'B :: TyCon > [LclIdX] > $tc'B > = TyCon > 477146386442824276## > 11145321492051770584## > $trModule > (TrNameS "'B"#) > 0# > $krep_a1st > > $krep_a1sr [InlPrag=NOUSERINLINE[~]] :: KindRep > [LclId] > $krep_a1sr > = KindRepTyConApp $tcZ (: @ KindRep $krep_a1ss ([] @ KindRep)) > > $krep_a1st [InlPrag=NOUSERINLINE[~]] :: KindRep > [LclId] > $krep_a1st > = KindRepTyConApp $tcZ (: @ KindRep $krep_a1su ([] @ KindRep)) > > $krep_a1ss [InlPrag=NOUSERINLINE[~]] :: KindRep > [LclId] > $krep_a1ss = KindRepTyConApp $tc() ([] @ KindRep) > > $krep_a1su [InlPrag=NOUSERINLINE[~]] :: KindRep > [LclId] > $krep_a1su = KindRepTyConApp $tcBool ([] @ KindRep) > > $trModule :: Module > [LclIdX] > $trModule = Module (TrNameS "main"#) (TrNameS "T3651"#) > > unsafe2 :: forall a b. ((a :: *) ~ (b :: *)) => Z b -> Z a -> a > [LclIdX] > unsafe2 > = \ (@ a_a1rd) > (@ b_a1re) > ($d~_a1rg :: (a_a1rd :: *) ~ (b_a1re :: *)) -> > let { > $d~~_a1ro :: (a_a1rd :: *) ~~ (b_a1re :: *) > [LclId] > $d~~_a1ro = $p1~ @ * @ a_a1rd @ b_a1re $d~_a1rg } in > case heq_sel @ * @ * @ a_a1rd @ b_a1re $d~~_a1ro of co_a1rp > { __DEFAULT -> > \ (ds_d1sv :: Z b_a1re) (ds_d1sw :: Z a_a1rd) -> > let { > fail_d1tc :: Void# -> a_a1rd > [LclId] > fail_d1tc > = \ (ds_d1td [OS=OneShot] :: Void#) -> > patError > @ 'LiftedRep @ a_a1rd "minimal.hs:12:1-16|function > unsafe2"# } in > case ds_d1sv of wild_00 { > __DEFAULT -> fail_d1tc void#; > B co_a1rh -> > let { > co_a1ru :: (a_a1rd :: *) ~# (Bool :: *) > [LclId[CoVarId]] > co_a1ru = CO: co_a1rp ; co_a1rh } in > case ds_d1sw of wild_00 { > __DEFAULT -> fail_d1tc void#; > U co_a1ri -> > () > `cast` (Sub ({co_a1rw} ; Sym co_a1ru) > :: (() :: *) ~R# (a_a1rd[sk:2] :: *)) > } > } > } > end Rec } > > *** End of Offense *** > > : error: > Compilation had errors > > }}} > > However, without core linting, the correct errors appear: > > {{{ > [1 of 1] Compiling T3651 ( minimal.hs, minimal.o ) > > minimal.hs:12:1: error: [-Woverlapping-patterns, -Werror=overlapping- > patterns] > Pattern match has inaccessible right hand side > In an equation for ‘unsafe2’: unsafe2 B U = ... > | > 12 | unsafe2 B U = () > | ^^^^^^^^^^^^^^^^ > > minimal.hs:12:11: error: [-Werror] > • Couldn't match type ‘Bool’ with ‘()’ > Inaccessible code in > a pattern with constructor: U :: Z (), in an equation for > ‘unsafe2’ > • In the pattern: U > In an equation for ‘unsafe2’: unsafe2 B U = () > | > 12 | unsafe2 B U = () > | ^ > }}} > > Without either core linting or `-Werror`, GHC just emits the warnings, > and then falls into a hole: > > {{{ > [1 of 1] Compiling T3651 ( minimal.hs, minimal.o ) > > minimal.hs:12:1: warning: [-Woverlapping-patterns] > Pattern match has inaccessible right hand side > In an equation for ‘unsafe2’: unsafe2 B U = ... > | > 12 | unsafe2 B U = () > | ^^^^^^^^^^^^^^^^ > > minimal.hs:12:11: warning: > • Couldn't match type ‘Bool’ with ‘()’ > Inaccessible code in > a pattern with constructor: U :: Z (), in an equation for > ‘unsafe2’ > • In the pattern: U > In an equation for ‘unsafe2’: unsafe2 B U = () > | > 12 | unsafe2 B U = () > | ^ > ghc-stage2: panic! (the 'impossible' happened) > (GHC version 8.5.20180508 for x86_64-unknown-linux): > opt_univ fell into a hole > {co_a1rw} > Call stack: > CallStack (from HasCallStack): > callStackDoc, called at compiler/utils/Outputable.hs:1162:37 in > ghc:Outputable > pprPanic, called at compiler/types/OptCoercion.hs:242:5 in > ghc:OptCoercion > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} New description: Consider the following program: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeFamilies #-} module T3651 where data Z a where U :: Z () B :: Z Bool unsafe2 :: a ~ b => Z b -> Z a -> a unsafe2 B U = () }}} On current GHC HEAD, this fails with an "Inaccessible branch" error. However, if we turn this error into a warning, e.g. using the following patch: {{{#!patch --- a/compiler/typecheck/TcErrors.hs +++ b/compiler/typecheck/TcErrors.hs @@ -708,7 +708,7 @@ mkGivenErrorReporter implic ctxt cts Nothing ty1 ty2 ; traceTc "mkGivenErrorReporter" (ppr ct) - ; maybeReportError ctxt err } + ; reportWarning NoReason err } where (ct : _ ) = cts -- Never empty (ty1, ty2) = getEqPredTys (ctPred ct) }}} ...and then compile with `-dcore-lint -Werror`, the program gets rejected with a core lint error: {{{ [1 of 1] Compiling T3651 ( minimal.hs, minimal.o ) *** Core Lint errors : in result of Desugar (before optimization) *** : warning: In a case alternative: (U co_a1ri :: (a_a1rd :: *) ~# (() :: *)) Unfilled coercion hole: {co_a1rw} : warning: In a case alternative: (U co_a1ri :: (a_a1rd :: *) ~# (() :: *)) co_a1rw :: (() :: *) ~# (Bool :: *) [LclId[CoVarId]] is out of scope *** Offending Program *** Rec { $tcZ :: TyCon [LclIdX] $tcZ = TyCon 5287023927886307113## 7998054209879401454## $trModule (TrNameS "Z"#) 0# krep$*Arr* $tc'U :: TyCon [LclIdX] $tc'U = TyCon 5625905484817226555## 8662083060712566586## $trModule (TrNameS "'U"#) 0# $krep_a1sr $tc'B :: TyCon [LclIdX] $tc'B = TyCon 477146386442824276## 11145321492051770584## $trModule (TrNameS "'B"#) 0# $krep_a1st $krep_a1sr [InlPrag=NOUSERINLINE[~]] :: KindRep [LclId] $krep_a1sr = KindRepTyConApp $tcZ (: @ KindRep $krep_a1ss ([] @ KindRep)) $krep_a1st [InlPrag=NOUSERINLINE[~]] :: KindRep [LclId] $krep_a1st = KindRepTyConApp $tcZ (: @ KindRep $krep_a1su ([] @ KindRep)) $krep_a1ss [InlPrag=NOUSERINLINE[~]] :: KindRep [LclId] $krep_a1ss = KindRepTyConApp $tc() ([] @ KindRep) $krep_a1su [InlPrag=NOUSERINLINE[~]] :: KindRep [LclId] $krep_a1su = KindRepTyConApp $tcBool ([] @ KindRep) $trModule :: Module [LclIdX] $trModule = Module (TrNameS "main"#) (TrNameS "T3651"#) unsafe2 :: forall a b. ((a :: *) ~ (b :: *)) => Z b -> Z a -> a [LclIdX] unsafe2 = \ (@ a_a1rd) (@ b_a1re) ($d~_a1rg :: (a_a1rd :: *) ~ (b_a1re :: *)) -> let { $d~~_a1ro :: (a_a1rd :: *) ~~ (b_a1re :: *) [LclId] $d~~_a1ro = $p1~ @ * @ a_a1rd @ b_a1re $d~_a1rg } in case heq_sel @ * @ * @ a_a1rd @ b_a1re $d~~_a1ro of co_a1rp { __DEFAULT -> \ (ds_d1sv :: Z b_a1re) (ds_d1sw :: Z a_a1rd) -> let { fail_d1tc :: Void# -> a_a1rd [LclId] fail_d1tc = \ (ds_d1td [OS=OneShot] :: Void#) -> patError @ 'LiftedRep @ a_a1rd "minimal.hs:12:1-16|function unsafe2"# } in case ds_d1sv of wild_00 { __DEFAULT -> fail_d1tc void#; B co_a1rh -> let { co_a1ru :: (a_a1rd :: *) ~# (Bool :: *) [LclId[CoVarId]] co_a1ru = CO: co_a1rp ; co_a1rh } in case ds_d1sw of wild_00 { __DEFAULT -> fail_d1tc void#; U co_a1ri -> () `cast` (Sub ({co_a1rw} ; Sym co_a1ru) :: (() :: *) ~R# (a_a1rd[sk:2] :: *)) } } } end Rec } *** End of Offense *** : error: Compilation had errors }}} However, without core linting, the correct errors appear: {{{ [1 of 1] Compiling T3651 ( minimal.hs, minimal.o ) minimal.hs:12:1: error: [-Woverlapping-patterns, -Werror=overlapping- patterns] Pattern match has inaccessible right hand side In an equation for ‘unsafe2’: unsafe2 B U = ... | 12 | unsafe2 B U = () | ^^^^^^^^^^^^^^^^ minimal.hs:12:11: error: [-Werror] • Couldn't match type ‘Bool’ with ‘()’ Inaccessible code in a pattern with constructor: U :: Z (), in an equation for ‘unsafe2’ • In the pattern: U In an equation for ‘unsafe2’: unsafe2 B U = () | 12 | unsafe2 B U = () | ^ }}} Without either core linting or `-Werror`, GHC just emits the warnings, and then falls into a hole: {{{ [1 of 1] Compiling T3651 ( minimal.hs, minimal.o ) minimal.hs:12:1: warning: [-Woverlapping-patterns] Pattern match has inaccessible right hand side In an equation for ‘unsafe2’: unsafe2 B U = ... | 12 | unsafe2 B U = () | ^^^^^^^^^^^^^^^^ minimal.hs:12:11: warning: • Couldn't match type ‘Bool’ with ‘()’ Inaccessible code in a pattern with constructor: U :: Z (), in an equation for ‘unsafe2’ • In the pattern: U In an equation for ‘unsafe2’: unsafe2 B U = () | 12 | unsafe2 B U = () | ^ ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.5.20180508 for x86_64-unknown-linux): opt_univ fell into a hole {co_a1rw} Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1162:37 in ghc:Outputable pprPanic, called at compiler/types/OptCoercion.hs:242:5 in ghc:OptCoercion Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 14 15:08:04 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 May 2018 15:08:04 -0000 Subject: [GHC] #11066: Inacessible branch should be warning - otherwise breaks type soundness? In-Reply-To: <047.0785946e31f05741dc32414264d84d16@haskell.org> References: <047.0785946e31f05741dc32414264d84d16@haskell.org> Message-ID: <062.927a5998f6ed80dae27296123f2a6dad@haskell.org> #11066: Inacessible branch should be warning - otherwise breaks type soundness? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #8128, #8740 | Differential Rev(s): Phab:D1454 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Core lint error may actually be an orthogonal issue; moved that part to #15152. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 14 15:14:45 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 May 2018 15:14:45 -0000 Subject: [GHC] #15150: Difference between 'libicuio' and 'icuio' in the 'extra-libraries' field In-Reply-To: <048.c7f9cdf75d4b8994697a313f39fc3697@haskell.org> References: <048.c7f9cdf75d4b8994697a313f39fc3697@haskell.org> Message-ID: <063.c6cee020ef8ce155b31771b6f4a075af@haskell.org> #15150: Difference between 'libicuio' and 'icuio' in the 'extra-libraries' field -------------------------------+-------------------------------------- Reporter: Darwin226 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.2 Resolution: duplicate | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: 14456 | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Comment (by Darwin226): Well, I'm stuck using my fork anyways since `text-icu` is not really maintained so adding an extra workaround isn't a problem. Thank you for the info! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 14 16:14:17 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 May 2018 16:14:17 -0000 Subject: [GHC] #15150: Difference between 'libicuio' and 'icuio' in the 'extra-libraries' field In-Reply-To: <048.c7f9cdf75d4b8994697a313f39fc3697@haskell.org> References: <048.c7f9cdf75d4b8994697a313f39fc3697@haskell.org> Message-ID: <063.673010462a9764aafa87490f85d37d96@haskell.org> #15150: Difference between 'libicuio' and 'icuio' in the 'extra-libraries' field -------------------------------+-------------------------------------- Reporter: Darwin226 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.2 Resolution: duplicate | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: 14456 | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Comment (by Phyx-): lol, It's already been fix in 8.4, nothing to backport here. Sorry @bgamari, brainfart... I think (not sure which version we've started doing it) but for sure 8.4 should be tracing dependencies automatically. So you shouldn't need that patch to `text-icu` with it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 14 19:55:33 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 May 2018 19:55:33 -0000 Subject: [GHC] #11295: Figure out what LLVM passes are fruitful In-Reply-To: <046.97e900ad29a1522a4b7374676cc6de7a@haskell.org> References: <046.97e900ad29a1522a4b7374676cc6de7a@haskell.org> Message-ID: <061.41a3c9214fa5477f1557aa59776692fd@haskell.org> #11295: Figure out what LLVM passes are fruitful -------------------------------------+------------------------------------- Reporter: bgamari | Owner: kavon Type: task | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 14528 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): kavon, any progress on this? It would be great to have something for 8.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 14 19:55:36 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 May 2018 19:55:36 -0000 Subject: [GHC] #14502: Build Alpine Linux binary distributions In-Reply-To: <046.7faa39537281abdbe7789c4ce9416be8@haskell.org> References: <046.7faa39537281abdbe7789c4ce9416be8@haskell.org> Message-ID: <061.fc65a5bfcd76d6092f71275688e3c41b@haskell.org> #14502: Build Alpine Linux binary distributions -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Continuous | Version: 8.2.1 Integration | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 14057 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > I remember asking in the ghc irc channel that depending on the llvm triples should go away entirely. I'd be all for that in this case for 8.6! It's not clear to me how to eliminate the dependency entirely. Unfortunately the only way to accomplish this I can see is to use `clang` instead of `llc`, which would get in the way of #11295. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 14 19:58:13 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 May 2018 19:58:13 -0000 Subject: [GHC] #15146: Documentation: ScopedTypeVariables feature not mentioned/misleadingly described In-Reply-To: <043.d95bdea9ee71d4ecb11e1c8b5424eb30@haskell.org> References: <043.d95bdea9ee71d4ecb11e1c8b5424eb30@haskell.org> Message-ID: <058.c2120c05cd58356947ea44ec62201561@haskell.org> #15146: Documentation: ScopedTypeVariables feature not mentioned/misleadingly described -------------------------------------+------------------------------------- Reporter: AntC | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Documentation | Version: 8.2.2 Resolution: | Keywords: newcomer, | ScopedTypeVariables Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: ScopedTypeVariables => newcomer, ScopedTypeVariables Comment: It would be great if someone could offer a patch for this. Misleading documentation is in many ways worse than no documentation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 14 20:27:39 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 May 2018 20:27:39 -0000 Subject: [GHC] #15095: pretty-show's literate haskell Setup.lhs failed on 32-bit windows In-Reply-To: <047.ddb6b51a929af36b051e0a4d3e1515c5@haskell.org> References: <047.ddb6b51a929af36b051e0a4d3e1515c5@haskell.org> Message-ID: <062.6f100c972a3535f6b82a3d7290486457@haskell.org> #15095: pretty-show's literate haskell Setup.lhs failed on 32-bit windows -------------------------------------+------------------------------------- Reporter: simonmic | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: GHC rejects | Test Case: valid program | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: Phyx- (added) Comment: Interesting; this seems to be a very difficult error code to find useful information about. I wasn't even able to find a conclusive description of its meaning in my brief Googling. Phyx, does this look familiar to you? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 14 20:33:47 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 May 2018 20:33:47 -0000 Subject: [GHC] #12463: SPECIALIZABLE pragma? In-Reply-To: <046.92ae6c231572298cabf5e2202d74c32b@haskell.org> References: <046.92ae6c231572298cabf5e2202d74c32b@haskell.org> Message-ID: <061.6166fafde58501b1c303053052cb9cc9@haskell.org> #12463: SPECIALIZABLE pragma? -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 14917 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by andrewthad): * related: => 14917 Comment: I added a related ticket. Although it is under the guise of loosening restrictions around levity polymorphism, it's in part a request for the same thing: a guarantee that specialization will happen. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 14 20:45:15 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 May 2018 20:45:15 -0000 Subject: [GHC] #15095: pretty-show's literate haskell Setup.lhs failed on 32-bit windows In-Reply-To: <047.ddb6b51a929af36b051e0a4d3e1515c5@haskell.org> References: <047.ddb6b51a929af36b051e0a4d3e1515c5@haskell.org> Message-ID: <062.65f957dfb54addd03d04f31a29d43483@haskell.org> #15095: pretty-show's literate haskell Setup.lhs failed on 32-bit windows -------------------------------------+------------------------------------- Reporter: simonmic | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: GHC rejects | Test Case: valid program | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): It's the exit code for segfault, it's supposed to be an unsigned number but it's printed as a signed one due to Haskell's `ExitFailure` taking a signed number. the unsigned representation is `0xc0000005`. which is the NTSTATUS code for `STATUS_ACCESS_VIOLATION`. [1] [1] https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel /using-ntstatus-values -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 14 20:51:38 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 May 2018 20:51:38 -0000 Subject: [GHC] #5928: INLINABLE fails to specialize in presence of simple wrapper In-Reply-To: <044.f94356cf74dc801e8fb7c76a9eaeb24d@haskell.org> References: <044.f94356cf74dc801e8fb7c76a9eaeb24d@haskell.org> Message-ID: <059.f297462d2e48daac12fd82b9932e17a0@haskell.org> #5928: INLINABLE fails to specialize in presence of simple wrapper -------------------------------------+------------------------------------- Reporter: tibbe | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Inlining, | Specialise 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: | -------------------------------------+------------------------------------- Comment (by andrewthad): I don't know when this was fixed, but I just tried the attached reproducible case with GHC 8.2.2, and specialization occurs as expected. This came up because I was working on another project and realized that inlining did not block specialization like this comment:19 suggested it would. I think this ticket should be marked as resolved. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 14 21:00:32 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 May 2018 21:00:32 -0000 Subject: [GHC] #15038: Memory Corruption (strange closure type) In-Reply-To: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> References: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> Message-ID: <064.c1379ef01acdb8b3b7b6a60c71d86fbb@haskell.org> #15038: Memory Corruption (strange closure type) -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.4.3 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #9718 | Differential Rev(s): Phab:D4680 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Sergei Trofimovich ): In [changeset:"79bbb23fd3085c3dc52497175e9e74f73f7f6b68/ghc" 79bbb23/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="79bbb23fd3085c3dc52497175e9e74f73f7f6b68" rts: export new absentSumFieldError from base commit b2ff5dde399cd012218578945ada1d9ff68daa35 "Fix #15038" added new stable closure 'absentSumFieldError_closure' to base package. This closure is used in rts package. Unfortunately the symbol was not explicitly exported and build failed on windows as: ``` "inplace/bin/ghc-stage1" -o ...hsc2hs.exe ... rts/dist/build/libHSrts.a(RtsStartup.o): In function `hs_init_ghc': rts/RtsStartup.c:272:0: error: undefined reference to `base_ControlziExceptionziBase_absentSumFieldError_closure' | 272 | getStablePtr((StgPtr)absentSumFieldError_closure); | ^ ``` This change adds 'absentSumFieldError_closure' to explicit export into libHSbase.def. Signed-off-by: Sergei Trofimovich }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 14 21:00:38 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 May 2018 21:00:38 -0000 Subject: [GHC] #13167: GC and weak reference finalizers and exceptions In-Reply-To: <044.f73010a4958317dc6bb4779ffc938be2@haskell.org> References: <044.f73010a4958317dc6bb4779ffc938be2@haskell.org> Message-ID: <059.5d8291e0d94d8ff1f4edd3f906b20614@haskell.org> #13167: GC and weak reference finalizers and exceptions -------------------------------------+------------------------------------- Reporter: Yuras | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4693 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => patch * differential: => Phab:D4693 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 14 21:05:00 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 May 2018 21:05:00 -0000 Subject: [GHC] #5928: INLINABLE fails to specialize in presence of simple wrapper In-Reply-To: <044.f94356cf74dc801e8fb7c76a9eaeb24d@haskell.org> References: <044.f94356cf74dc801e8fb7c76a9eaeb24d@haskell.org> Message-ID: <059.c7f32571998eb27498601adbfcd8d681@haskell.org> #5928: INLINABLE fails to specialize in presence of simple wrapper -------------------------------------+------------------------------------- Reporter: tibbe | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Inlining, | Specialise 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: | -------------------------------------+------------------------------------- Comment (by simonpj): Great! By "the attached reproducible case" do you mean the one right at the top (from tibbe)? I'd like to add something as a regression test before closing, to make sure it stays fixed. Omer/Tobias, might you do that? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 14 21:19:24 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 May 2018 21:19:24 -0000 Subject: [GHC] #15095: pretty-show's literate haskell Setup.lhs failed on 32-bit windows In-Reply-To: <047.ddb6b51a929af36b051e0a4d3e1515c5@haskell.org> References: <047.ddb6b51a929af36b051e0a4d3e1515c5@haskell.org> Message-ID: <062.01e6d8d6f99d2d85e6d1efff89d0df2d@haskell.org> #15095: pretty-show's literate haskell Setup.lhs failed on 32-bit windows -------------------------------------+------------------------------------- Reporter: simonmic | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: GHC rejects | Test Case: valid program | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): I can't reproduce it, I've seen such reports before for `AppVeyor`. My guess is something is on their environment interfering with `unlit`. I'd need a core dump or memory dump to be able to figure it out. AppVeyor has gdb, so a core dump from gdb or procdump would suffice. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 14 21:19:47 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 May 2018 21:19:47 -0000 Subject: [GHC] #15095: pretty-show's literate haskell Setup.lhs failed on 32-bit windows In-Reply-To: <047.ddb6b51a929af36b051e0a4d3e1515c5@haskell.org> References: <047.ddb6b51a929af36b051e0a4d3e1515c5@haskell.org> Message-ID: <062.97c0370302e8b8eaff3bb5c6d12af4a5@haskell.org> #15095: pretty-show's literate haskell Setup.lhs failed on 32-bit windows -------------------------------------+------------------------------------- Reporter: simonmic | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: GHC rejects | Test Case: valid program | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 14 22:52:15 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 May 2018 22:52:15 -0000 Subject: [GHC] #15136: High CPU when asynchronous exception and unblocking retry on TVar raced In-Reply-To: <047.29d934aee302d96a63fcdabcdc59c0f2@haskell.org> References: <047.29d934aee302d96a63fcdabcdc59c0f2@haskell.org> Message-ID: <062.ae5a14aff1ecc3c507d6f19ede43ebe8@haskell.org> #15136: High CPU when asynchronous exception and unblocking retry on TVar raced -------------------------------------+------------------------------------- Reporter: nshimaza | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Thanks for the small repro! Indeed I am able to easily reproduce this. The racing threads look like this, {{{ Thread 8 (LWP 25960): #0 0x000000000049c0df in stmCommitTransaction () #1 0x00000000004a9de4 in stg_atomically_frame_info () #2 0x0000000000000000 in ?? () Thread 1 (LWP 25948): #0 0x000000000049b290 in lock_tvar () #1 0x000000000049b559 in remove_watch_queue_entries_for_trec () #2 0x000000000049b95b in stmAbortTransaction () #3 0x000000000049984c in raiseAsync () #4 0x0000000000499ba3 in throwToMsg () #5 0x0000000000499e82 in throwTo () #6 0x00000000004a6aac in stg_killThreadzh () #7 0x0000000000000000 in ?? () }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 14 23:40:58 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 May 2018 23:40:58 -0000 Subject: [GHC] #11295: Figure out what LLVM passes are fruitful In-Reply-To: <046.97e900ad29a1522a4b7374676cc6de7a@haskell.org> References: <046.97e900ad29a1522a4b7374676cc6de7a@haskell.org> Message-ID: <061.33324ea7db7cc4dd76955dd304fb673e@haskell.org> #11295: Figure out what LLVM passes are fruitful -------------------------------------+------------------------------------- Reporter: bgamari | Owner: kavon Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (LLVM) | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 14528 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by kavon): * milestone: => 8.6.1 Comment: I'll definitely get something in for 8.6, whether auto-generated or hand- crafted. I've had some good hand-crafted pass sequences sitting around for a while now. Progress on the autotuner has stalled because (1) it finds weird bugs in LLVM sometimes, and I should just fix them instead of trying to avoid them, (2) I'll be working with some people this summer to create a proper autotuner for LLVM, so we can hopefully use that instead of what I hacked together. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 15 10:42:10 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 May 2018 10:42:10 -0000 Subject: [GHC] #15153: GHC uses O_NONBLOCK on regular files, which has no effect, and blocks the runtime Message-ID: <042.2f3205a88421ca45196ab3bf4e5a61ff@haskell.org> #15153: GHC uses O_NONBLOCK on regular files, which has no effect, and blocks the runtime -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime | Version: 8.2.2 System | Keywords: | Operating System: Linux Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is the outcome of https://mail.haskell.org/pipermail/ghc- devs/2018-May/015749.html Reading through the code of [http://hackage.haskell.org/package/base-4.11.1.0/docs/src/GHC.IO.FD.html#readRawBufferPtr readRawBufferPtr] the first line jumped to my eye: {{{ | isNonBlocking fd = unsafe_read -- unsafe is ok, it can't block }}} This looks suspicious. On Linux, if `fd` is a a descriptor to a regular file (on disk, a networked filesystem, or a block device), then `O_NONBLOCK` will have no effect, yet `unsafe_read` is used which will block the running OS thread. You can read more about `O_NONBLOCK` not working on regular files on Linux here: * https://www.nginx.com/blog/thread-pools-boost-performance-9x/ * https://stackoverflow.com/questions/8057892/epoll-on-regular-files * https://jvns.ca/blog/2017/06/03/async-io-on-linux--select--poll--and- epoll/ * https://groups.google.com/forum/#!topic/comp.os.linux.development.system/K -fC-G6P4EA And indeed, the following program does NOT keep printing things in the printing thread, and instead blocks for 30 seconds: {{{ module Main where import Control.Concurrent import Control.Monad import qualified Data.ByteString as BS import System.Environment main :: IO () main = do args <- getArgs case args of [file] -> do forkIO $ forever $ do putStrLn "still running" threadDelay 100000 -- 0.1 s bs <- BS.readFile file putStrLn $ "Read " ++ show (BS.length bs) ++ " bytes" _ -> error "Pass 1 argument (a file)" }}} when compiled with {{{ ~/.stack/programs/x86_64-linux/ghc-8.2.2/bin/ghc --make -O -threaded blocking-regular-file-read-test.hs }}} on my Ubuntu 16.04 and on a 2GB file like {{{ ./blocking-regular-file-read-test /mnt/images/ubuntu-18.04-desktop- amd64.iso }}} And `strace -f -e open,read` on it shows: {{{ open("/mnt/images/ubuntu-18.04-desktop-amd64.iso", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 11 read(11, }}} So GHC is trying to use `O_NONBLOCK` on regular files, which cannot work and will block when used through unsafe foreign calls like that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 15 10:43:52 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 May 2018 10:43:52 -0000 Subject: [GHC] #15153: GHC uses O_NONBLOCK on regular files, which has no effect, and blocks the runtime In-Reply-To: <042.2f3205a88421ca45196ab3bf4e5a61ff@haskell.org> References: <042.2f3205a88421ca45196ab3bf4e5a61ff@haskell.org> Message-ID: <057.a1b0cdc3c4cf4a5e07ae7a21753bab35@haskell.org> #15153: GHC uses O_NONBLOCK on regular files, which has no effect, and blocks the runtime -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.2.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): This is mainly for Linux but may also apply to other OSs. I've read that FreeBSD has a better story for reading files asynchronously, but I don't know whether GHC has any special code to use those features. Input from FreeBSD users would be appreciated. Otherwise, likely the fix to this for Linux will also improve things over the status quo on FreeBSD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 15 10:44:06 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 May 2018 10:44:06 -0000 Subject: [GHC] #15153: GHC uses O_NONBLOCK on regular files, which has no effect, and blocks the runtime In-Reply-To: <042.2f3205a88421ca45196ab3bf4e5a61ff@haskell.org> References: <042.2f3205a88421ca45196ab3bf4e5a61ff@haskell.org> Message-ID: <057.825242897e807d4d144aa2c0606dbcb6@haskell.org> #15153: GHC uses O_NONBLOCK on regular files, which has no effect, and blocks the runtime -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.2.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): Also funny but perhaps not too surprising: If in my code, you replace `forkIO` by e.g. `forkOn 2`, then nondeterministically, sometimes the program hangs and sometimes it works with `+RTS -N2`. The higher you set `-N`, the more likely it is to work. If you put both the putStrLn loop and the readFile into `forkOn 0` and `forkOn 1` each, and run with `+RTS -N3`, then it always works as expected. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 15 10:51:20 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 May 2018 10:51:20 -0000 Subject: [GHC] #11066: Inacessible branch should be warning - otherwise breaks type soundness? In-Reply-To: <047.0785946e31f05741dc32414264d84d16@haskell.org> References: <047.0785946e31f05741dc32414264d84d16@haskell.org> Message-ID: <062.db50ec48102effbf01b63dc510d8afed@haskell.org> #11066: Inacessible branch should be warning - otherwise breaks type soundness? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #8128, #8740 | Differential Rev(s): Phab:D1454 Wiki Page: | -------------------------------------+------------------------------------- Comment (by adamgundry): @tdammers I don't think this is as straightforward as simply switching the error into a warning. Have you looked at Phab:D1454 and the associated discussion? Indeed GHC doesn't currently produce correct Core under inaccessible branches, and doing so would probably require extending Core. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 15 12:35:53 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 May 2018 12:35:53 -0000 Subject: [GHC] #15154: Segmentation fault of ghc-pkg.exe from 32-bit distribution of ghc-8.2.2 on Windows 7 Message-ID: <048.2e4683ede5797175b196c3bdda927d9f@haskell.org> #15154: Segmentation fault of ghc-pkg.exe from 32-bit distribution of ghc-8.2.2 on Windows 7 -------------------------------------+------------------------------------- Reporter: ki11men0w | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: ghc-pkg | Version: 8.2.2 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: Compile-time | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- On `Windows 7` call of `ghc-pkg` utility from `32-bit` `ghc-8.2.2` distribution is always ended with `Segmentation fault` error. With use of `Cygwin` the error can be reproduced this way: run `cmd.exe` and in the appeared console window execute the following commands {{{#!bash c:\Users\user.name\wrk> bash $ mkdir ghc-pkg-check $ cd ghc-pkg-check $ curl https://downloads.haskell.org/~ghc/8.2.2/ghc-8.2.2-i386-unknown- mingw32.tar.xz > ghc-8.2.2-i386-unknown-mingw32.tar.xz % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 163M 100 163M 0 0 3669k 0 0:00:45 0:00:45 --:--:-- 4776k $ xz -dc ghc-8.2.2-i386-unknown-mingw32.tar.xz | tar -xf - $ cd ghc-8.2.2/bin/ $ ./ghc-pkg.exe --version GHC package manager version 8.2.2 Segmentation fault }}} The error arises irrespective of how and with what arguments to call `ghc- pkg` utility. For example, firstly I has faced the problem using `stack` from Windows console: {{{#!bat > stack build --arch=i386 --resolver=11.9 }}} I checked another distributions of GHC for presence of this bug on `Windows 7`. 64-bit version of ghc-8.2.2, 32-bit and 64-bit versions of ghc-8.0.2 and ghc-8.4.2 are free of the problem. I **did not check** the problem **on another versions** of MS Windows. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 15 12:46:55 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 May 2018 12:46:55 -0000 Subject: [GHC] #15155: How untagged pointers sneak into banged fields Message-ID: <048.7d229d504bd9df060a5294d6d9eccfdc@haskell.org> #15155: How untagged pointers sneak into banged fields -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: 14677 | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- (''N.B.'' I am writing this up from memory, and cannot verify it just now, maybe someone can lend a hand, otherwise I'll do it ASAP!) Here is a way how untagged pointers to strict data can be created in banged (strict) constructor fields. This reproduction recipe **depends on the patch from #14677 applied**. We have 3 modules `A`, `B` and `C`: {{{#!hs module A where data A = X | Y | Z a = Z }}} {{{#!hs module B where import A newtype B = B A b = B a }}} {{{#!hs {-# language MagicHash #-} module C where import A import B import GHC.Exts data C = C !B c = C b main = do print (I# (reallyUnsafePtrEquality# a (coerce b))) -- prints 0, b is softlink print (I# (dataToTag# c)) -- prints 0: not entered yet print (case c of C b' -> I# (dataToTag# b')) -- prints 0? print (case c of C (B a') -> I# (dataToTag# a')) -- prints 3 }}} ------------------- == Why this happens `B.b` is a newtype to `A.a` so one would expect that both alias the same memory location (a ''hardlink'' in filesystem parlance). But currently reexports are implemented with a special type of closure `IND_STATIC` (a ''softlink'') which needs to be entered to obtain the actual (tagged pointer). The `IND_STATIC` closure's pointer is never tagged (otherwise it would never be entered, instead interpreted as a honest-to-goodness `A.A`, which causes the symptoms seen in #14677). With #14677 applied to GHC, the unfolding of `B.b` is correctly read when compiling `C` (with `-O1` and better) and thus the compiler knows that it should be a tagged pointer value. Thus the construction of `C.c` shortcuts the entering of `B.b` when filling the strict field, and (because `B.b` being a softlink, thus untagged) the field ends up carrying a 0 tag. ------------------------- == How can this be fixed? I see two possibilities one conservative and one invasive. === Conservative When seeing a coercion unfolding of a tagged value being used to initialise a strict field, do not skip the evaluatedness check, but cater for the possibility of an `IND_STATIC` closure. Check the closure type, and if confirmed, steal the pointee and use that. === Invasive Get rid of the `IND_STATIC` closures altogether. For ''intra-module'' softlinks we can have proper hardlinks (assembler `.equiv` directives, or LLVM `alias`es). ''Inter-module'' softlinks can also be eliminated by linker scripts. This would however cause more build artifacts, so I don't know how hairy it would turn out. OTOH, it would reduce binary size by eliminating indirection closures and potential dereferencing code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 15 13:02:59 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 May 2018 13:02:59 -0000 Subject: [GHC] #15151: Better Interaction Between Specialization and GND In-Reply-To: <049.4c9d715f37d1146ca95fc1f1e65b6621@haskell.org> References: <049.4c9d715f37d1146ca95fc1f1e65b6621@haskell.org> Message-ID: <064.480ec0e57dfd71ef63bc9cb44f1c8b26@haskell.org> #15151: Better Interaction Between Specialization and GND -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: infoneeded Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 15 13:30:13 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 May 2018 13:30:13 -0000 Subject: [GHC] #15152: Core Lint error in ill-typed GADT code In-Reply-To: <047.18c2cbc6ba40b8b60bd69a6b876e50e1@haskell.org> References: <047.18c2cbc6ba40b8b60bd69a6b876e50e1@haskell.org> Message-ID: <062.7b6256e30ba7d09418c978b97dd8f672@haskell.org> #15152: Core Lint error in ill-typed GADT code -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11066 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by tdammers: Old description: > Consider the following program: > > {{{#!hs > {-# LANGUAGE GADTs #-} > {-# LANGUAGE TypeFamilies #-} > > module T3651 where > > data Z a where > U :: Z () > B :: Z Bool > > unsafe2 :: a ~ b => Z b -> Z a -> a > unsafe2 B U = () > }}} > > On current GHC HEAD, this fails with an "Inaccessible branch" error. > However, if we turn this error into a warning, e.g. using the following > patch: > > {{{#!patch > --- a/compiler/typecheck/TcErrors.hs > +++ b/compiler/typecheck/TcErrors.hs > @@ -708,7 +708,7 @@ mkGivenErrorReporter implic ctxt cts > Nothing ty1 ty2 > > ; traceTc "mkGivenErrorReporter" (ppr ct) > - ; maybeReportError ctxt err } > + ; reportWarning NoReason err } > where > (ct : _ ) = cts -- Never empty > (ty1, ty2) = getEqPredTys (ctPred ct) > }}} > > ...and then compile with `-dcore-lint -Werror`, the program gets rejected > with a core lint error: > > {{{ > [1 of 1] Compiling T3651 ( minimal.hs, minimal.o ) > *** Core Lint errors : in result of Desugar (before optimization) *** > : warning: > In a case alternative: (U co_a1ri :: (a_a1rd :: *) ~# (() :: *)) > Unfilled coercion hole: {co_a1rw} > : warning: > In a case alternative: (U co_a1ri :: (a_a1rd :: *) ~# (() :: *)) > co_a1rw :: (() :: *) ~# (Bool :: *) > [LclId[CoVarId]] is out of scope > *** Offending Program *** > Rec { > $tcZ :: TyCon > [LclIdX] > $tcZ > = TyCon > 5287023927886307113## > 7998054209879401454## > $trModule > (TrNameS "Z"#) > 0# > krep$*Arr* > > $tc'U :: TyCon > [LclIdX] > $tc'U > = TyCon > 5625905484817226555## > 8662083060712566586## > $trModule > (TrNameS "'U"#) > 0# > $krep_a1sr > > $tc'B :: TyCon > [LclIdX] > $tc'B > = TyCon > 477146386442824276## > 11145321492051770584## > $trModule > (TrNameS "'B"#) > 0# > $krep_a1st > > $krep_a1sr [InlPrag=NOUSERINLINE[~]] :: KindRep > [LclId] > $krep_a1sr > = KindRepTyConApp $tcZ (: @ KindRep $krep_a1ss ([] @ KindRep)) > > $krep_a1st [InlPrag=NOUSERINLINE[~]] :: KindRep > [LclId] > $krep_a1st > = KindRepTyConApp $tcZ (: @ KindRep $krep_a1su ([] @ KindRep)) > > $krep_a1ss [InlPrag=NOUSERINLINE[~]] :: KindRep > [LclId] > $krep_a1ss = KindRepTyConApp $tc() ([] @ KindRep) > > $krep_a1su [InlPrag=NOUSERINLINE[~]] :: KindRep > [LclId] > $krep_a1su = KindRepTyConApp $tcBool ([] @ KindRep) > > $trModule :: Module > [LclIdX] > $trModule = Module (TrNameS "main"#) (TrNameS "T3651"#) > > unsafe2 :: forall a b. ((a :: *) ~ (b :: *)) => Z b -> Z a -> a > [LclIdX] > unsafe2 > = \ (@ a_a1rd) > (@ b_a1re) > ($d~_a1rg :: (a_a1rd :: *) ~ (b_a1re :: *)) -> > let { > $d~~_a1ro :: (a_a1rd :: *) ~~ (b_a1re :: *) > [LclId] > $d~~_a1ro = $p1~ @ * @ a_a1rd @ b_a1re $d~_a1rg } in > case heq_sel @ * @ * @ a_a1rd @ b_a1re $d~~_a1ro of co_a1rp > { __DEFAULT -> > \ (ds_d1sv :: Z b_a1re) (ds_d1sw :: Z a_a1rd) -> > let { > fail_d1tc :: Void# -> a_a1rd > [LclId] > fail_d1tc > = \ (ds_d1td [OS=OneShot] :: Void#) -> > patError > @ 'LiftedRep @ a_a1rd "minimal.hs:12:1-16|function > unsafe2"# } in > case ds_d1sv of wild_00 { > __DEFAULT -> fail_d1tc void#; > B co_a1rh -> > let { > co_a1ru :: (a_a1rd :: *) ~# (Bool :: *) > [LclId[CoVarId]] > co_a1ru = CO: co_a1rp ; co_a1rh } in > case ds_d1sw of wild_00 { > __DEFAULT -> fail_d1tc void#; > U co_a1ri -> > () > `cast` (Sub ({co_a1rw} ; Sym co_a1ru) > :: (() :: *) ~R# (a_a1rd[sk:2] :: *)) > } > } > } > end Rec } > > *** End of Offense *** > > : error: > Compilation had errors > > }}} > > However, without core linting, the correct errors appear: > > {{{ > [1 of 1] Compiling T3651 ( minimal.hs, minimal.o ) > > minimal.hs:12:1: error: [-Woverlapping-patterns, -Werror=overlapping- > patterns] > Pattern match has inaccessible right hand side > In an equation for ‘unsafe2’: unsafe2 B U = ... > | > 12 | unsafe2 B U = () > | ^^^^^^^^^^^^^^^^ > > minimal.hs:12:11: error: [-Werror] > • Couldn't match type ‘Bool’ with ‘()’ > Inaccessible code in > a pattern with constructor: U :: Z (), in an equation for > ‘unsafe2’ > • In the pattern: U > In an equation for ‘unsafe2’: unsafe2 B U = () > | > 12 | unsafe2 B U = () > | ^ > }}} > > Without either core linting or `-Werror`, GHC just emits the warnings, > and then falls into a hole: > > {{{ > [1 of 1] Compiling T3651 ( minimal.hs, minimal.o ) > > minimal.hs:12:1: warning: [-Woverlapping-patterns] > Pattern match has inaccessible right hand side > In an equation for ‘unsafe2’: unsafe2 B U = ... > | > 12 | unsafe2 B U = () > | ^^^^^^^^^^^^^^^^ > > minimal.hs:12:11: warning: > • Couldn't match type ‘Bool’ with ‘()’ > Inaccessible code in > a pattern with constructor: U :: Z (), in an equation for > ‘unsafe2’ > • In the pattern: U > In an equation for ‘unsafe2’: unsafe2 B U = () > | > 12 | unsafe2 B U = () > | ^ > ghc-stage2: panic! (the 'impossible' happened) > (GHC version 8.5.20180508 for x86_64-unknown-linux): > opt_univ fell into a hole > {co_a1rw} > Call stack: > CallStack (from HasCallStack): > callStackDoc, called at compiler/utils/Outputable.hs:1162:37 in > ghc:Outputable > pprPanic, called at compiler/types/OptCoercion.hs:242:5 in > ghc:OptCoercion > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} New description: Consider the following program: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeFamilies #-} module T3651 where data Z a where U :: Z () B :: Z Bool unsafe2 :: a ~ b => Z b -> Z a -> a unsafe2 B U = () }}} On current GHC HEAD, this fails with an "Inaccessible branch" error. However, if we turn this error into a warning, e.g. using the following patch: {{{#!patch --- a/compiler/typecheck/TcErrors.hs +++ b/compiler/typecheck/TcErrors.hs @@ -708,7 +708,7 @@ mkGivenErrorReporter implic ctxt cts Nothing ty1 ty2 ; traceTc "mkGivenErrorReporter" (ppr ct) - ; maybeReportError ctxt err } + ; reportWarning NoReason err } where (ct : _ ) = cts -- Never empty (ty1, ty2) = getEqPredTys (ctPred ct) }}} ...and then compile with `-dcore-lint -Werror`, the program gets rejected with a core lint error: {{{ [1 of 1] Compiling T3651 ( minimal.hs, minimal.o ) *** Core Lint errors : in result of Desugar (before optimization) *** : warning: In a case alternative: (U co_a1ri :: (a_a1rd :: *) ~# (() :: *)) Unfilled coercion hole: {co_a1rw} : warning: In a case alternative: (U co_a1ri :: (a_a1rd :: *) ~# (() :: *)) co_a1rw :: (() :: *) ~# (Bool :: *) [LclId[CoVarId]] is out of scope *** Offending Program *** Rec { $tcZ :: TyCon [LclIdX] $tcZ = TyCon 5287023927886307113## 7998054209879401454## $trModule (TrNameS "Z"#) 0# krep$*Arr* $tc'U :: TyCon [LclIdX] $tc'U = TyCon 5625905484817226555## 8662083060712566586## $trModule (TrNameS "'U"#) 0# $krep_a1sr $tc'B :: TyCon [LclIdX] $tc'B = TyCon 477146386442824276## 11145321492051770584## $trModule (TrNameS "'B"#) 0# $krep_a1st $krep_a1sr [InlPrag=NOUSERINLINE[~]] :: KindRep [LclId] $krep_a1sr = KindRepTyConApp $tcZ (: @ KindRep $krep_a1ss ([] @ KindRep)) $krep_a1st [InlPrag=NOUSERINLINE[~]] :: KindRep [LclId] $krep_a1st = KindRepTyConApp $tcZ (: @ KindRep $krep_a1su ([] @ KindRep)) $krep_a1ss [InlPrag=NOUSERINLINE[~]] :: KindRep [LclId] $krep_a1ss = KindRepTyConApp $tc() ([] @ KindRep) $krep_a1su [InlPrag=NOUSERINLINE[~]] :: KindRep [LclId] $krep_a1su = KindRepTyConApp $tcBool ([] @ KindRep) $trModule :: Module [LclIdX] $trModule = Module (TrNameS "main"#) (TrNameS "T3651"#) unsafe2 :: forall a b. ((a :: *) ~ (b :: *)) => Z b -> Z a -> a [LclIdX] unsafe2 = \ (@ a_a1rd) (@ b_a1re) ($d~_a1rg :: (a_a1rd :: *) ~ (b_a1re :: *)) -> let { $d~~_a1ro :: (a_a1rd :: *) ~~ (b_a1re :: *) [LclId] $d~~_a1ro = $p1~ @ * @ a_a1rd @ b_a1re $d~_a1rg } in case heq_sel @ * @ * @ a_a1rd @ b_a1re $d~~_a1ro of co_a1rp { __DEFAULT -> \ (ds_d1sv :: Z b_a1re) (ds_d1sw :: Z a_a1rd) -> let { fail_d1tc :: Void# -> a_a1rd [LclId] fail_d1tc = \ (ds_d1td [OS=OneShot] :: Void#) -> patError @ 'LiftedRep @ a_a1rd "minimal.hs:12:1-16|function unsafe2"# } in case ds_d1sv of wild_00 { __DEFAULT -> fail_d1tc void#; B co_a1rh -> let { co_a1ru :: (a_a1rd :: *) ~# (Bool :: *) [LclId[CoVarId]] co_a1ru = CO: co_a1rp ; co_a1rh } in case ds_d1sw of wild_00 { __DEFAULT -> fail_d1tc void#; U co_a1ri -> () `cast` (Sub ({co_a1rw} ; Sym co_a1ru) :: (() :: *) ~R# (a_a1rd[sk:2] :: *)) } } } end Rec } *** End of Offense *** : error: Compilation had errors }}} However, without core linting, the correct errors appear: {{{ [1 of 1] Compiling T3651 ( minimal.hs, minimal.o ) minimal.hs:12:1: error: [-Woverlapping-patterns, -Werror=overlapping- patterns] Pattern match has inaccessible right hand side In an equation for ‘unsafe2’: unsafe2 B U = ... | 12 | unsafe2 B U = () | ^^^^^^^^^^^^^^^^ minimal.hs:12:11: error: [-Werror] • Couldn't match type ‘Bool’ with ‘()’ Inaccessible code in a pattern with constructor: U :: Z (), in an equation for ‘unsafe2’ • In the pattern: U In an equation for ‘unsafe2’: unsafe2 B U = () | 12 | unsafe2 B U = () | ^ }}} Without either core linting or `-Werror`, GHC just emits the warnings, and then falls into a hole: {{{ [1 of 1] Compiling T3651 ( minimal.hs, minimal.o ) minimal.hs:12:1: warning: [-Woverlapping-patterns] Pattern match has inaccessible right hand side In an equation for ‘unsafe2’: unsafe2 B U = ... | 12 | unsafe2 B U = () | ^^^^^^^^^^^^^^^^ minimal.hs:12:11: warning: • Couldn't match type ‘Bool’ with ‘()’ Inaccessible code in a pattern with constructor: U :: Z (), in an equation for ‘unsafe2’ • In the pattern: U In an equation for ‘unsafe2’: unsafe2 B U = () | 12 | unsafe2 B U = () | ^ ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.5.20180508 for x86_64-unknown-linux): opt_univ fell into a hole {co_a1rw} Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1162:37 in ghc:Outputable pprPanic, called at compiler/types/OptCoercion.hs:242:5 in ghc:OptCoercion Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} This behavior also appears in the following test cases from the GHC test suite: - `gadt/T3651` - `gadt/T7558` -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 15 13:51:50 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 May 2018 13:51:50 -0000 Subject: [GHC] #11066: Inacessible branch should be warning - otherwise breaks type soundness? In-Reply-To: <047.0785946e31f05741dc32414264d84d16@haskell.org> References: <047.0785946e31f05741dc32414264d84d16@haskell.org> Message-ID: <062.06cc94783ea0228c095ea8ca77905040@haskell.org> #11066: Inacessible branch should be warning - otherwise breaks type soundness? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #8128, #8740 | Differential Rev(s): Phab:D1454 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Hmm. I don't think I agree, Adam. GHC currently simply doesn't use insoluble inert constraints, so it won't make use of `Int ~ Bool`. Would you like to offer an example where we don't produce correct Core under inaccessible branches? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 15 14:21:29 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 May 2018 14:21:29 -0000 Subject: [GHC] #15155: How untagged pointers sneak into banged fields In-Reply-To: <048.7d229d504bd9df060a5294d6d9eccfdc@haskell.org> References: <048.7d229d504bd9df060a5294d6d9eccfdc@haskell.org> Message-ID: <063.de3afd233602c433e11814174a88cce3@haskell.org> #15155: How untagged pointers sneak into banged fields -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 14677 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm lost in a maze of twisty passages. We have * #14677 Code generator does not correctly tag a pointer. I'm not sure if this is a serious bug, or just the loss of a potential optimisation. (I think the latter.) * #14626 No need to enter a scrutinised value. Apparently blocked on #14677 * #14373 Introduce PTR-tagging for big constructor families. This has Phab:D4267. I think it may be blocked (in some way) on #15155. * #15155 (this ticket). I'm not sure how these tickets inter-relate beyond the blocking notes I've put here. Which is most urgent? Gabor, are you actively working on any of them? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 15 14:23:23 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 May 2018 14:23:23 -0000 Subject: [GHC] #15152: Core Lint error in ill-typed GADT code In-Reply-To: <047.18c2cbc6ba40b8b60bd69a6b876e50e1@haskell.org> References: <047.18c2cbc6ba40b8b60bd69a6b876e50e1@haskell.org> Message-ID: <062.803cf6cb4e295eec329f8bf1678326d2@haskell.org> #15152: Core Lint error in ill-typed GADT code -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11066 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): The discussion in this earlier attempt at solving #11066 might prove relevant also: https://phabricator.haskell.org/D1454#42098? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 15 14:29:52 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 May 2018 14:29:52 -0000 Subject: [GHC] #15152: Core Lint error in ill-typed GADT code In-Reply-To: <047.18c2cbc6ba40b8b60bd69a6b876e50e1@haskell.org> References: <047.18c2cbc6ba40b8b60bd69a6b876e50e1@haskell.org> Message-ID: <062.0d4be56bf85a2c4956504787dd910da8@haskell.org> #15152: Core Lint error in ill-typed GADT code -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11066 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"f49f90bb84b12515366de9b8184644b5c3798901/ghc" f49f90b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f49f90bb84b12515366de9b8184644b5c3798901" Tidy up error suppression Trac #15152 showed that when a flag turned an error into a warning, we were still (alas) suppressing subequent errors; includign their essential addTcEvBind. That led (rightly) to a Lint error. This patch fixes it, and incidentally tidies up an ad-hoc special case of out-of-scope variables (see the old binding for 'out_of_scope_killer' in 'tryReporters'). No test, because the problem was only shown up when turning inaccessible code into a warning. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 15 15:10:11 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 May 2018 15:10:11 -0000 Subject: [GHC] #15155: How untagged pointers sneak into banged fields In-Reply-To: <048.7d229d504bd9df060a5294d6d9eccfdc@haskell.org> References: <048.7d229d504bd9df060a5294d6d9eccfdc@haskell.org> Message-ID: <063.5e7961dd794d24d5fac4e453f7963dd2@haskell.org> #15155: How untagged pointers sneak into banged fields -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 14677 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by heisenbug): Replying to [comment:1 simonpj]: > I'm lost in a maze of twisty passages. We have Sorry, but this was how the story unfolded with time. Believe me, I am also starting to get lost. Will try to clarify the relations, to my best knowledge, below. > > * #14677 Code generator does not correctly tag a pointer. I'm not sure if this is a serious bug, or just the loss of a potential optimisation. (I think the latter.) Performance-only bug. Leads to unnecessarily generated code and extra runtime because closures are entered redundantly. > > * #14626 No need to enter a scrutinised value. Apparently blocked on #14677 Does not seem to block #14373 but could make it more effective. > > * #14373 Introduce PTR-tagging for big constructor families. This has Phab:D4267. I think it may be blocked (in some way) on #15155. All the above is about making pointer tagging more expressive and reducing closure entries. The very bottom of this stack is * #13861 Take more advantage of STG representation invariance (follows up #9291) > > * #15155 (this ticket). > > I'm not sure how these tickets inter-relate beyond the blocking notes I've put here. Which is most urgent? Gabor, are you actively working on any of them? I think #15155 (this ticket) is the one that needs to be resolved first, so that #14677 can land. Then #14626 and #14373 can be resolved, unless new problems surface. #13861 has a proof-of-concept implementation, which will need some love, but with extended PTR-tagging (#14373) it'd cover more cases. Since I dreamed up the "conservative" solution just last night, I have no fix for this one yet, but could start with an implementation in early June latest. (In January I implemented intra-module "hardlinks" in the NCG.) I think it would be nice to have a discussion about `IND_STATIC` closures too, resp. their elimination. Overall I think it is worrisome that strict fields get initialised with non-tagged pointers, even if the compiler statically knows that the corresponding data is in WHNF. TL/DR: This is a stack of mostly dependent tickets (newer ones need to be resolved before older ones), each unlocking a new optimisation in its own right. Hopefully no more monsters lurking. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 15 16:24:16 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 May 2018 16:24:16 -0000 Subject: [GHC] #913: instance Ord (StableName a) In-Reply-To: <047.0416f6faa91e0e6311d64f6160f1532a@haskell.org> References: <047.0416f6faa91e0e6311d64f6160f1532a@haskell.org> Message-ID: <062.aa2d09bd7b54f13e96aa06cb1b7ee38e@haskell.org> #913: instance Ord (StableName a) -------------------------------------+------------------------------------- Reporter: ekarttun | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 6.10 branch Component: libraries/base | Version: 6.4.2 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by andrewthad): * failure: => None/Unknown Comment: Is there a reason this is currently marked as wontfix? It seems like adding a `compareStableNames#` primop would be easy and would solve this issue. I might be able to figure out how to do this and would be happy to give it a try if I knew it would be accepted. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 15 16:37:12 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 May 2018 16:37:12 -0000 Subject: [GHC] #7414: plugins always trigger recompilation In-Reply-To: <045.791037be90cd943b6dd26df93dd060d8@haskell.org> References: <045.791037be90cd943b6dd26df93dd060d8@haskell.org> Message-ID: <060.76d52c00daa3766c7a1024133ced61aa@haskell.org> #7414: plugins always trigger recompilation -------------------------------------+------------------------------------- Reporter: jwlato | Owner: (none) Type: feature request | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: plugin, | RecompilationCheck Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12567 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Patch: https://phabricator.haskell.org/D4366 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 15 17:05:41 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 May 2018 17:05:41 -0000 Subject: [GHC] #15072: Teach the testsuite driver about response files In-Reply-To: <046.77942c6e24b9dfca972cf55cbeb07713@haskell.org> References: <046.77942c6e24b9dfca972cf55cbeb07713@haskell.org> Message-ID: <061.9ae9ec02081fd93ed5018f5728c3b793@haskell.org> #15072: Teach the testsuite driver about response files -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Test Suite | Version: 8.2.2 Resolution: | Keywords: ci-breakage Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"af986f9dfb49db5544e4d670cde9a9a70a9a1223/ghc" af986f9d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="af986f9dfb49db5544e4d670cde9a9a70a9a1223" testsuite: Disable T14697 on Windows Test Plan: Validate on Windows Subscribers: thomie, carter GHC Trac Issues: #14697, #15072 Differential Revision: https://phabricator.haskell.org/D4619 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 15 17:05:41 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 May 2018 17:05:41 -0000 Subject: [GHC] #14697: Redundant computation in fingerprintDynFlags when compiling many modules In-Reply-To: <046.c781f4e812a45b7f1a7576c9d7db1ab8@haskell.org> References: <046.c781f4e812a45b7f1a7576c9d7db1ab8@haskell.org> Message-ID: <061.94a84360778c980259cd86dd14cfdc21@haskell.org> #14697: Redundant computation in fingerprintDynFlags when compiling many modules -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: Resolution: fixed | 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): phab:D4445 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"af986f9dfb49db5544e4d670cde9a9a70a9a1223/ghc" af986f9d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="af986f9dfb49db5544e4d670cde9a9a70a9a1223" testsuite: Disable T14697 on Windows Test Plan: Validate on Windows Subscribers: thomie, carter GHC Trac Issues: #14697, #15072 Differential Revision: https://phabricator.haskell.org/D4619 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 15 17:05:56 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 May 2018 17:05:56 -0000 Subject: [GHC] #12012: Socket operations on Windows check errno instead of calling WSAGetLastError() In-Reply-To: <045.1d8b8b19fc3bbac40a93311c1ba3456a@haskell.org> References: <045.1d8b8b19fc3bbac40a93311c1ba3456a@haskell.org> Message-ID: <060.c8a57a46e9dad29b62a5275f3e61d51a@haskell.org> #12012: Socket operations on Windows check errno instead of calling WSAGetLastError() -------------------------------------+------------------------------------- Reporter: enolan | Owner: Azel Type: bug | Status: patch Priority: normal | Milestone: Component: Core Libraries | Version: Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4639 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"01b15b88639443bec12415b6b0d906261bd6c047/ghc" 01b15b88/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="01b15b88639443bec12415b6b0d906261bd6c047" Calling GetLastError() on Windows for socket IO (trac issue #12012) For the threaded RTS, putting a private copy of the throwErrno series in GHC.IO.FD which gets if the operation was on a socket, so that we can call c_maperrno if need be. For the non-threaded RTS, if memory serves we call GetLastError() in case of an error on socket IO. However, we don't do the translation ErrCode ↔ Errno currently (and besides, it's a primop) so we do it if needed through c_maperrno_func in the asynchronous read/write functions. Signed-off-by: ARJANEN Loïc Jean David Reviewers: ekmett, hvr, bgamari Reviewed By: bgamari Subscribers: thomie, carter GHC Trac Issues: #12012 Differential Revision: https://phabricator.haskell.org/D4639 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 15 17:14:32 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 May 2018 17:14:32 -0000 Subject: [GHC] #7414: plugins always trigger recompilation In-Reply-To: <045.791037be90cd943b6dd26df93dd060d8@haskell.org> References: <045.791037be90cd943b6dd26df93dd060d8@haskell.org> Message-ID: <060.b1d1a76bf8f9b077313d892b211aeb8c@haskell.org> #7414: plugins always trigger recompilation -------------------------------------+------------------------------------- Reporter: jwlato | Owner: (none) Type: feature request | Status: patch Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: plugin, | RecompilationCheck Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12567 | Differential Rev(s): Phab:D4366 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D4366 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 15 17:16:19 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 May 2018 17:16:19 -0000 Subject: [GHC] #913: instance Ord (StableName a) In-Reply-To: <047.0416f6faa91e0e6311d64f6160f1532a@haskell.org> References: <047.0416f6faa91e0e6311d64f6160f1532a@haskell.org> Message-ID: <062.989d256ef79586900cf81ed44230a3ae@haskell.org> #913: instance Ord (StableName a) -------------------------------------+------------------------------------- Reporter: ekarttun | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: libraries/base | Version: 6.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: core-libraries-committee@… (added) * status: closed => new * resolution: wontfix => Comment: It sounds like we just weren't sure whether this was a desireable feature. Indeed this is a bit of a tricky question as it to some extent commits other implementations to also offer this functionality. Let's see what the Core Libraries Committee says. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 15 17:18:30 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 May 2018 17:18:30 -0000 Subject: [GHC] #12012: Socket operations on Windows check errno instead of calling WSAGetLastError() In-Reply-To: <045.1d8b8b19fc3bbac40a93311c1ba3456a@haskell.org> References: <045.1d8b8b19fc3bbac40a93311c1ba3456a@haskell.org> Message-ID: <060.87036ab8ec3c728a90828f3535950c14@haskell.org> #12012: Socket operations on Windows check errno instead of calling WSAGetLastError() -------------------------------------+------------------------------------- Reporter: enolan | Owner: Azel Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4639 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 15 17:45:12 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 May 2018 17:45:12 -0000 Subject: [GHC] #913: instance Ord (StableName a) In-Reply-To: <047.0416f6faa91e0e6311d64f6160f1532a@haskell.org> References: <047.0416f6faa91e0e6311d64f6160f1532a@haskell.org> Message-ID: <062.fff0b4ea7592ff1628dae3379235305d@haskell.org> #913: instance Ord (StableName a) -------------------------------------+------------------------------------- Reporter: ekarttun | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: libraries/base | Version: 6.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): When you say that it "to some extend commits other implementations to also offer this functionality", how do you mean that? StableName isn't part of the Haskell Report. But yes, I agree that checking with the CLC is a good step. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 15 18:59:25 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 May 2018 18:59:25 -0000 Subject: [GHC] #913: instance Ord (StableName a) In-Reply-To: <047.0416f6faa91e0e6311d64f6160f1532a@haskell.org> References: <047.0416f6faa91e0e6311d64f6160f1532a@haskell.org> Message-ID: <062.9bbe307ea59e21a87765576b1ae43d9a@haskell.org> #913: instance Ord (StableName a) -------------------------------------+------------------------------------- Reporter: ekarttun | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: libraries/base | Version: 6.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Ahh, right, of course. I don't know why I thought it was in the Report. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 15 20:35:42 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 May 2018 20:35:42 -0000 Subject: [GHC] #913: instance Ord (StableName a) In-Reply-To: <047.0416f6faa91e0e6311d64f6160f1532a@haskell.org> References: <047.0416f6faa91e0e6311d64f6160f1532a@haskell.org> Message-ID: <062.cd645a0fdf9883abcd28c0540a2eac90@haskell.org> #913: instance Ord (StableName a) -------------------------------------+------------------------------------- Reporter: ekarttun | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: libraries/base | Version: 6.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): Up until now the fact that you can't care about the arbitrary ordering that the `StableName`s have has been viewed as a feature. Pragmatically, if you need to use them as keys in a container `unordered-containers` should properly treat them as `Hashable`, and rather explicitly considers the container "unordered". That said, one could argue that the same reasoning should apply to `Data.Unique` in that it should be `Hashable`/`Eq` only, and not provide the `Ord` instance it already does, so to your point there is at least an appearance of inconsistency between these two positions. There is some difference between those two scenarios though. It is worth noting that nothing in our current API says a `StableName#` gets any sort of actual _unique_ integer assigned to it during creation. It just lives on the heap. Pretending we can gives me pause. You can't compare pointers to them using an ordering, any more than you can compare `MutVar#`'s for `Ord` because GC can change the relative position of them, and we don't want to inflate them with a superfluous costs to support an operation that isn't fundamental to their existence. Now, we do have a `stableNameToInt#` operation, but it rather carefully doesn't claim to produce a unique name. Mind you it doesn't make this claim largely due to concerns about GC happening in the meantime, but we've had this degree of freedom for a long time, and could abuse it more in the internals without anybody actually being able to care. @simonmar's initial suggestion that we can use the `Ord` on the `stableNameToInt#` used by `hashStableName` to compare `StableName#`s seems a little racy to me: the integer isn't guaranteed to be unique due to the fact that `StableName` IDs can be reused, but due to the fact that I could construct two stable names, converting one to an integer through `stableNameToInt#`, have a gc happen in which the now 'dead' `StableName` gets recollected, have someone else get assigned to the same id, then force another stablename that was constructed in the meantime, which might resolve to the same id. While it seems like a reasonably far fetched scenario that that might go wrong, the chain of reasoning to prove that it always goes right is delicate. e.g. I don't see what prevents you from constructing the second stable name using an `unsafePerformIO` in between the unwrapping of the first and unwrapping the second, it would be constructed by the act of forcing the `StableName` data constructor. Do I think this will really happen in user code? Maybe not, but the fact that I could even see a path towards it, and Jan-Willem's experience report, combined with my previous efforts along these lines building the `intern` library and basically giving up on the cleanup once problems get large enough due to issues of this sort, gives me a great deal of pause. But there isn't really any particular reason other than the current implementation why these Ids are small unique numbers. In a different world, they could just be heap objects with some ID created during initialization, say, based on their initial allocation address. They could then be "moved" like any other heap object. The current API doesn't require uniqueness of keys, so this would pass everything about the `StableName` API, much like how my [https://github.com/ekmett/unique/blob/master/src/Control/Concurrent/Unique.hs#L38 Control.Concurrent.Unique] matches the shape of the `Data.Unique` API, but can only supply `Hashable`, not `Ord`, as the integer of initial allocation location associated with each `Unique` value could be shared across several such `Unique` values. This has the benefit of avoiding _any_ coordination during allocation of these identifiers across threads and so scales better than our current `Data.Unique` system. I could see a world in which we'd want to refactor the internals of `System.Mem.StableName` at some point to offer a more efficient construction. The current API offers a lot of possible implementation approaches. Adding an `Ord` constraint limits those choices, and reasoning about its soundness takes us into relatively dubious territory as seen above. On a more theoretical basis, to phrase this another way, not everything that can be broken into equivalence classes breaks up into _ordered_ equivalence classes. If these were merely unique objects on the heap, then merely being able to compare these for equality vs. having the power to sort them is analogous to the problem of 'pointer discrimination' mentioned by Fritz Henglein in [https://pdfs.semanticscholar.org/f425/7af9221ca7fe21dc84a049a8545a28a874ae.pdf Generic Top-down Discrimination for Sorting and Partitioning in Linear Time]. All of these issues taken together leaves me inclined to let the old `wontfix` status of this issue stand. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 15 21:47:43 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 May 2018 21:47:43 -0000 Subject: [GHC] #8763: forM_ [1..N] does not get fused (10 times slower than go function) In-Reply-To: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> References: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> Message-ID: <057.62542ac8f9fa9fccaf20c3677063c347@haskell.org> #8763: forM_ [1..N] does not get fused (10 times slower than go function) -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #7206 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"bb338f2eb706a3137bf6675e3ddbf96d4fe4f4aa/ghc" bb338f2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bb338f2eb706a3137bf6675e3ddbf96d4fe4f4aa" Algebraically simplify add/sub with carry/overflow Previously, the `{add,sub}{Int,Word}C#` PrimOps weren't handled in PrelRules (constant folding and algebraic simplification) at all. This implements the necessary logic, so that using these primitives isn't too punishing compared to their well-optimised, overflow-unaware counterparts. This is so that using these primitives in `enumFromThenTo @Int` can be optimized by constant folding, reducing closure sizes. Reviewers: bgamari, simonpj, hsyl20 Reviewed By: bgamari, simonpj Subscribers: AndreasK, thomie, carter GHC Trac Issues: #8763 Differential Revision: https://phabricator.haskell.org/D4605 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 15 22:00:44 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 May 2018 22:00:44 -0000 Subject: [GHC] #15039: Bizarre pretty-printing of inferred Coercible constraint in partial type signature In-Reply-To: <050.aaadeac0c3786f879c5b76ef15d4ae09@haskell.org> References: <050.aaadeac0c3786f879c5b76ef15d4ae09@haskell.org> Message-ID: <065.ad693bb006f176ad2df1ccae61846d9c@haskell.org> #15039: Bizarre pretty-printing of inferred Coercible constraint in partial type signature -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.1 checker) | Keywords: Resolution: | PartialTypeSignatures, TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4696 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D4696 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 15 22:02:41 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 May 2018 22:02:41 -0000 Subject: [GHC] #15124: Improve block layout for the NCG In-Reply-To: <047.b2a760b384d29a2bc137285a934c2d79@haskell.org> References: <047.b2a760b384d29a2bc137285a934c2d79@haskell.org> Message-ID: <062.970cce392ef87ba8f023e41bbf6f9346@haskell.org> #15124: Improve block layout for the NCG -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (NCG) | Version: 8.2.2 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8082 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * owner: (none) => AndreasK -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 15 22:08:18 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 May 2018 22:08:18 -0000 Subject: [GHC] #11066: Inacessible branch should be warning - otherwise breaks type soundness? In-Reply-To: <047.0785946e31f05741dc32414264d84d16@haskell.org> References: <047.0785946e31f05741dc32414264d84d16@haskell.org> Message-ID: <062.7b3dffb695462baf64e2816f7a13bd0e@haskell.org> #11066: Inacessible branch should be warning - otherwise breaks type soundness? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #8128, #8740 | Differential Rev(s): Phab:D1454 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I fixed #15152, so that may unblock progress here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 15 22:08:42 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 May 2018 22:08:42 -0000 Subject: [GHC] #15152: Core Lint error in ill-typed GADT code In-Reply-To: <047.18c2cbc6ba40b8b60bd69a6b876e50e1@haskell.org> References: <047.18c2cbc6ba40b8b60bd69a6b876e50e1@haskell.org> Message-ID: <062.dbb0c250ac58c9731b98ae49a0be4cda@haskell.org> #15152: Core Lint error in ill-typed GADT code -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11066 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 15 22:24:12 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 May 2018 22:24:12 -0000 Subject: [GHC] #15133: Make `nofib` work with Hadrian In-Reply-To: <047.3debb5e25137f26bba1d26ebffe5dbd6@haskell.org> References: <047.3debb5e25137f26bba1d26ebffe5dbd6@haskell.org> Message-ID: <062.9089e590d77b57dd95099094a68704be@haskell.org> #15133: Make `nofib` work with Hadrian -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.6.1 Component: NoFib benchmark | Version: suite | Resolution: fixed | Keywords: hadrian Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alpmestan): * status: new => closed * resolution: => fixed Comment: This was due to me trying to run nofib against a `quickest`-flavoured GHC built (by Hadrian). When I run nofib against a `perf` GHC, it runs to completion. When I run nofib against a `quickest`-flavoured GHC built by the Make build system, I get the error from my previous comment. I'm also introducing a `nofib` rule in [https://github.com/snowleopard/hadrian/pull/599 this PR] which records the log under `/nofib-log` (so `_build/nofib-log` by default, if you don't specify your own `--build-root`). It's not merged yet but will likely be under a few days. That rule just runs `make clean ; make WithNofibHc=/stage1/bin/ghc PERL= boot ; make WithNofibHc=/stage1/bin/ghc PERL=`, recording stdout/stderr just for that last `make` command, to mirror the benchmarking workflow described [https://ghc.haskell.org/trac/ghc/wiki/Building/RunningNoFib on this trac page]. You can run these commands manually or wait for my patch to land. Closing this ticket, given that we can now run nofib with hadrian-built GHCs, and soon directly with hadrian. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 15 23:33:31 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 May 2018 23:33:31 -0000 Subject: [GHC] #913: instance Ord (StableName a) In-Reply-To: <047.0416f6faa91e0e6311d64f6160f1532a@haskell.org> References: <047.0416f6faa91e0e6311d64f6160f1532a@haskell.org> Message-ID: <062.75063eebfd95aa4ee66c765c529bd359@haskell.org> #913: instance Ord (StableName a) -------------------------------------+------------------------------------- Reporter: ekarttun | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: libraries/base | Version: 6.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): I agree with your concern that an Ord instance limits future possibilities to modify the implementation. I disagree with the concern about soundness. As you point out, using hashStableName to implement an Ord instance is unsound. We do not use it in the Eq instance, and it would be every bit as unsound in an Ord instance. The path forward to implementing an Ord instance would be to introduce a new primop for comparing StableName#. It would basically be the same thing as eqStableName#. After all, eqStableName# is basically ( in the current implementation) two calls to stableNameToInt# with the guarantee that garbage collection cannot happen between them. And this guarantee that garbage collection doesn’t happen between the two calls is exactly what you make the implementation you discuss above sound. But yes, it does constrain the possible available implementations. I certainly agree with that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 15 23:37:44 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 May 2018 23:37:44 -0000 Subject: [GHC] #14391: Make the simplifier independent of the typechecker In-Reply-To: <046.0a550c305c7e5731d1526aa1438cdf9f@haskell.org> References: <046.0a550c305c7e5731d1526aa1438cdf9f@haskell.org> Message-ID: <061.e471118954ad4a41cce0e9055eb00a2c@haskell.org> #14391: Make the simplifier independent of the typechecker -------------------------------------+------------------------------------- Reporter: nomeata | Owner: ulysses4ever Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4503 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"bb3fa2d18686d0c08b57c66a90a9ea1b4e4482ee/ghc" bb3fa2d1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bb3fa2d18686d0c08b57c66a90a9ea1b4e4482ee" Less Tc inside simplCore (Phase 1 for #14391) Simplifier depends on typechecker in two points: `thNameToGhcName` (`lookupThName_maybe`, in particular) and `lookupGlobal`. We want to cut the ties in two steps. 1. (Presented in this commit), reimplement both functions in a way that doesn't use typechecker. 2. (Should follow), do code moving: a) `lookupGlobal` should go in some typechecker-free place; b) `thNameToGhcName` should leave simplifier, because it is not used there at all (probably, it should be placed somewhere where `GhcPlugins` can see it -- this is suggested by Joachim on Trac). Details ======= We redesigned lookup interface a bit so that it exposes some `IO`-equivalents of `Tc`-features in use. First, `CoreMonad.hs` still calls `lookupGlobal` which is no longer bound to the typechecker monad, but still resides in `TcEnv.hs` — it should be moved out of Tc-land at some point (“Phase 2”) in the future in order to achieve its part of the #14391's goal. Second, `lookupThName_maybe` is eliminated from `CoreMonad.hs` completely; this already achieves its part of the goal of #14391. Its client, though, `thNameToGhcName`, is better to be moved in the future also, for it is not used in the `CoreMonad.hs` (or anywhere else) anyway. Joachim suggested “any module reexported by GhcPlugins (or maybe even that module itself)”. As a side goal, we removed `initTcForLookup` which was instrumental for the past version of `lookupGlobal`. This, in turn, called for pushing some more parts of the lookup interface from the `Tc`-monad to `IO`, most notably, adding `IO`-version of `lookupOrig` and pushing `dataConInfoPtrToName` to `IO`. The `lookupOrig` part, in turn, triggered a slight redesign of name cache updating interface: we now have both, `updNameCacheIO` and `updNameCacheTc`, both accepting `mod` and `occ` to force them inside, instead of more error-prone outside before. But all these hardly have to do anything with #14391, mere refactoring. Reviewers: simonpj, nomeata, bgamari, hvr Reviewed By: simonpj, bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14391 Differential Revision: https://phabricator.haskell.org/D4503 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 16 00:04:17 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 May 2018 00:04:17 -0000 Subject: [GHC] #8089: Implementation of GHC.Event.Poll.poll is broken due to bad coercion In-Reply-To: <045.7e2f7bf1f77ecf8607cd3966531ffeb1@haskell.org> References: <045.7e2f7bf1f77ecf8607cd3966531ffeb1@haskell.org> Message-ID: <060.bd14c84972a40ebea006feb9b267fdb6@haskell.org> #8089: Implementation of GHC.Event.Poll.poll is broken due to bad coercion -------------------------------------+------------------------------------- Reporter: merijn | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D407 Wiki Page: | -------------------------------------+------------------------------------- Comment (by alpmestan): Ben: any suggestion for what we should do with these failures? I'm still seeing them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 16 01:19:40 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 May 2018 01:19:40 -0000 Subject: [GHC] #8089: Implementation of GHC.Event.Poll.poll is broken due to bad coercion In-Reply-To: <045.7e2f7bf1f77ecf8607cd3966531ffeb1@haskell.org> References: <045.7e2f7bf1f77ecf8607cd3966531ffeb1@haskell.org> Message-ID: <060.28ace66f466a208bfcba2aea44f04aae@haskell.org> #8089: Implementation of GHC.Event.Poll.poll is broken due to bad coercion -------------------------------------+------------------------------------- Reporter: merijn | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D407 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Hmm, let's open a new ticket so we can investigate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 16 02:01:03 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 May 2018 02:01:03 -0000 Subject: [GHC] #2207: Load the interface details for GHC.* even without -O In-Reply-To: <046.c160dd85a0a0b0a47d62c75151b28378@haskell.org> References: <046.c160dd85a0a0b0a47d62c75151b28378@haskell.org> Message-ID: <061.5c0d83ae2d3e4531ef8271df703dafd6@haskell.org> #2207: Load the interface details for GHC.* even without -O -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Azel Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.8.2 Resolution: | Keywords: newcomers Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Azel): * owner: (none) => Azel -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 16 02:06:47 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 May 2018 02:06:47 -0000 Subject: [GHC] #15078: base: Customary type class laws (e.g. for Eq) and non-abiding instances (e.g. Float) should be documented In-Reply-To: <046.a4c8c72c9e9d68a07b93ce24b1eed9ca@haskell.org> References: <046.a4c8c72c9e9d68a07b93ce24b1eed9ca@haskell.org> Message-ID: <061.fdf0b8b1f98576ddf2ce4b0792110ce6@haskell.org> #15078: base: Customary type class laws (e.g. for Eq) and non-abiding instances (e.g. Float) should be documented -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: Azel Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.4.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Azel): * owner: (none) => Azel -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 16 02:08:01 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 May 2018 02:08:01 -0000 Subject: [GHC] #15134: enumFrom... aren't really documented. In-Reply-To: <045.101e34e5570fe8f6e2839dfe4e91d13c@haskell.org> References: <045.101e34e5570fe8f6e2839dfe4e91d13c@haskell.org> Message-ID: <060.648fa679cc0d60bd323fdbc4b4f8a3e5@haskell.org> #15134: enumFrom... aren't really documented. -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Azel Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Azel): * owner: (none) => Azel -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 16 03:20:24 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 May 2018 03:20:24 -0000 Subject: [GHC] #913: instance Ord (StableName a) In-Reply-To: <047.0416f6faa91e0e6311d64f6160f1532a@haskell.org> References: <047.0416f6faa91e0e6311d64f6160f1532a@haskell.org> Message-ID: <062.92e4334d8659e31264a2fba45eb1d02f@haskell.org> #913: instance Ord (StableName a) -------------------------------------+------------------------------------- Reporter: ekarttun | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: libraries/base | Version: 6.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): Implemented as a custom prim so there is no risk of the gc gap? That'd fix the soundness concern. I'd for some reason mentally parsed Simon's suggestion as happening in "user land" as it were but that fixes it. I still think it falls into wontfix territory for the other reasons specified; I don't particularly _like_ our current implementation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 16 04:03:08 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 May 2018 04:03:08 -0000 Subject: [GHC] #15156: Show instances for types exported from the ghc package Message-ID: <046.d248f2a97f701c87f9f099e5928dbc28@haskell.org> #15156: Show instances for types exported from the ghc package -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- In order to test and debug code that depends on the `ghc` package, it would be nice to have `Show` instances for the types it exports. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 16 04:19:34 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 May 2018 04:19:34 -0000 Subject: [GHC] #15157: Use a better string type (ByteString?!) for HsDocString Message-ID: <046.8bb89a9e841d6d5ba281eb5787d40851@haskell.org> #15157: Use a better string type (ByteString?!) for HsDocString -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- `HsDocString` is currently defined as {{{ newtype HsDocString = HsDocString FastString }}} Alex Biehl and hvr mentioned that due to `FastString`'s (interning?) overhead it's not a good type to store haddocks. They suggested using `ByteString` instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 16 04:28:20 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 May 2018 04:28:20 -0000 Subject: [GHC] #15156: Show instances for types exported from the ghc package In-Reply-To: <046.d248f2a97f701c87f9f099e5928dbc28@haskell.org> References: <046.d248f2a97f701c87f9f099e5928dbc28@haskell.org> Message-ID: <061.d71911754f4407278e1bc01cff82a56e@haskell.org> #15156: Show instances for types exported from the ghc package -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alexbiehl): While 'show' would be nice for now you can use 'ppr' and 'showSDocUnsafe' from 'Outputable'. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 16 05:03:29 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 May 2018 05:03:29 -0000 Subject: [GHC] #15156: Show instances for types exported from the ghc package In-Reply-To: <046.d248f2a97f701c87f9f099e5928dbc28@haskell.org> References: <046.d248f2a97f701c87f9f099e5928dbc28@haskell.org> Message-ID: <061.97ce6fbc1160c07a2dc1b441d4850239@haskell.org> #15156: Show instances for types exported from the ghc package -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sjakobi): Replying to [comment:1 alexbiehl]: > While 'show' would be nice for now you can use 'ppr' and 'showSDocUnsafe' from 'Outputable'. Thanks for the tip, Alex! I had come accross `showSDocUnsafe` before, but was scared off by its documentation: {{{ -- showSDocUnsafe is unsafe, because `unsafeGlobalDynFlags` might not be -- initialised yet. }}} I felt like I had no reason to assume that `unsafeGlobalDynFlags` was initialised. The function might be less scary if there was a comment explaining under what circumstances `unsafeGlobalDynFlags` ''is'' initialised. For my immediate needs, I made do with a few orphan instances. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 16 07:05:21 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 May 2018 07:05:21 -0000 Subject: [GHC] #11066: Inacessible branch should be warning - otherwise breaks type soundness? In-Reply-To: <047.0785946e31f05741dc32414264d84d16@haskell.org> References: <047.0785946e31f05741dc32414264d84d16@haskell.org> Message-ID: <062.1cf3c595f9e3661bf0fce1019ace4846@haskell.org> #11066: Inacessible branch should be warning - otherwise breaks type soundness? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #8128, #8740 | Differential Rev(s): Phab:D1454 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Replying to [comment:43 simonpj]: > I fixed #15152, so that may unblock progress here. I noticed that, very nice. I've rebased my patch onto this fixed version, and it seems that the lint errors indeed disappear. I'm also seeing the expected failures (provided I change the relevant tests to compile with `-Werror`), however the exact error messages differ slightly, e.g. for T3651: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeFamilies #-} module T3651 where data Z a where U :: Z () B :: Z Bool unsafe1 :: Z a -> Z a -> a unsafe1 B U = () unsafe2 :: a ~ b => Z b -> Z a -> a unsafe2 B U = () unsafe3 :: a ~ b => Z a -> Z b -> a unsafe3 B U = True }}} {{{#!diff commit 89b64708fa2928978c0822b0540977663a4b087d Author: Tobias Dammers Date: Wed May 16 08:49:48 2018 +0200 Make gadt/T3651 pass diff --git a/testsuite/tests/gadt/T3651.stderr b/testsuite/tests/gadt/T3651.stderr index 14216eb149..62e3bf16d7 100644 --- a/testsuite/tests/gadt/T3651.stderr +++ b/testsuite/tests/gadt/T3651.stderr @@ -1,21 +1,14 @@ -T3651.hs:11:11: error: - • Couldn't match type ‘Bool’ with ‘()’ - Inaccessible code in - a pattern with constructor: U :: Z (), in an equation for ‘unsafe1’ - • In the pattern: U +T3651.hs:11:15: error: + • Couldn't match type ‘()’ with ‘Bool’ + Expected type: a + Actual type: () + • In the expression: () In an equation for ‘unsafe1’: unsafe1 B U = () -T3651.hs:14:11: error: - • Couldn't match type ‘Bool’ with ‘()’ - Inaccessible code in - a pattern with constructor: U :: Z (), in an equation for ‘unsafe2’ - • In the pattern: U +T3651.hs:14:15: error: + • Couldn't match type ‘()’ with ‘Bool’ + Expected type: a + Actual type: () + • In the expression: () In an equation for ‘unsafe2’: unsafe2 B U = () - -T3651.hs:17:11: error: - • Couldn't match type ‘Bool’ with ‘()’ - Inaccessible code in - a pattern with constructor: U :: Z (), in an equation for ‘unsafe3’ - • In the pattern: U - In an equation for ‘unsafe3’: unsafe3 B U = True }}} So this means that `unsafe1` and `unsafe2` keep getting rejected, but for a different reason (plain old type mismatch, rather than the "Inaccessible code" warning), and `unsafe3` is now accepted. But that doesn't seem right. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 16 09:03:04 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 May 2018 09:03:04 -0000 Subject: [GHC] #8089: Implementation of GHC.Event.Poll.poll is broken due to bad coercion In-Reply-To: <045.7e2f7bf1f77ecf8607cd3966531ffeb1@haskell.org> References: <045.7e2f7bf1f77ecf8607cd3966531ffeb1@haskell.org> Message-ID: <060.f0385c40b8b0b7d6cf329ca0520fc7cf@haskell.org> #8089: Implementation of GHC.Event.Poll.poll is broken due to bad coercion -------------------------------------+------------------------------------- Reporter: merijn | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D407 Wiki Page: | -------------------------------------+------------------------------------- Comment (by merijn): FWIW, the original test was...rather hacky to begin with. It was basically relying on the test-suite terminating the job after X seconds and producing a timeout, since the original bug caused that program to immediately crash. So prime suspects would be any change in the timeout mechanism of the testsuite producing a different error code. Also, if T8089 terminates when you run it on the commandline something is *obviously* wrong as that program shouldn't exit until, approximately 292,471 years after starting. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 16 10:39:40 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 May 2018 10:39:40 -0000 Subject: [GHC] #10346: Cross-module SpecConstr In-Reply-To: <046.b576f13f2450fed85380ce289fdfae5b@haskell.org> References: <046.b576f13f2450fed85380ce289fdfae5b@haskell.org> Message-ID: <061.d3b05646ab8b9a550f020538d9adfcae@haskell.org> #10346: Cross-module SpecConstr -------------------------------------+------------------------------------- Reporter: simonpj | Owner: ckoparkar Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: SpecConstr, | newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13016 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ckoparkar): Thanks for the explanation sgraf! I did not realize that having exactly same call patterns would triggering this. I'll try out this example later today. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 16 10:50:33 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 May 2018 10:50:33 -0000 Subject: [GHC] #15158: T8089 failing with ghci, threaded1, threaded2, profthreaded Message-ID: <048.e0a32f56c09af74c66cfdba0027fd931@haskell.org> #15158: T8089 failing with ghci, threaded1, threaded2, profthreaded -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.5 libraries/base | Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: T8089 | Blocked By: Blocking: | Related Tickets: #8089 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ =====> T8089(ghci) 17 of 17 [2, 16, 0] cd "/run/user/1001/ghctest-m_wu2f4i/test spaces/../../libraries/base/tests/T8089.run" && "/home/alp/WT/ghc-slow- validate/bindisttest/install dir/bin/ghc" T8089.hs -dcore-lint -dcmm- lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow- warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno- debug-output --interactive -v0 -ignore-dot-ghci -fno-ghci-history +RTS -I0.1 -RTS < T8089.genscript Wrong exit code for T8089(ghci) (expected 99 , actual 0 ) *** unexpected failure for T8089(ghci) =====> T8089(threaded1) 17 of 17 [2, 17, 0] cd "/run/user/1001/ghctest-m_wu2f4i/test spaces/../../libraries/base/tests/T8089.run" && "/home/alp/WT/ghc-slow- validate/bindisttest/install dir/bin/ghc" -o T8089 T8089.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show- caret -dno-debug-output -threaded -debug cd "/run/user/1001/ghctest-m_wu2f4i/test spaces/../../libraries/base/tests/T8089.run" && ./T8089 Wrong exit code for T8089(threaded1)(expected 99 , actual 0 ) *** unexpected failure for T8089(threaded1) =====> T8089(threaded2) 17 of 17 [2, 18, 0] cd "/run/user/1001/ghctest-m_wu2f4i/test spaces/../../libraries/base/tests/T8089.run" && "/home/alp/WT/ghc-slow- validate/bindisttest/install dir/bin/ghc" -o T8089 T8089.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show- caret -dno-debug-output -O -threaded -eventlog cd "/run/user/1001/ghctest-m_wu2f4i/test spaces/../../libraries/base/tests/T8089.run" && ./T8089 +RTS -N2 -ls -RTS Wrong exit code for T8089(threaded2)(expected 99 , actual 0 ) *** unexpected failure for T8089(threaded2) =====> T8089(profthreaded) 17 of 17 [2, 19, 0] cd "/run/user/1001/ghctest-m_wu2f4i/test spaces/../../libraries/base/tests/T8089.run" && "/home/alp/WT/ghc-slow- validate/bindisttest/install dir/bin/ghc" -o T8089 T8089.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show- caret -dno-debug-output -O -prof -static -fprof-auto -threaded cd "/run/user/1001/ghctest-m_wu2f4i/test spaces/../../libraries/base/tests/T8089.run" && ./T8089 +RTS -p -RTS Wrong exit code for T8089(profthreaded)(expected 99 , actual 0 ) *** unexpected failure for T8089(profthreaded) }}} I'm going to write a patch to expect the test to be broken in these ways, but it seems really wrong that the exit code we get is not the same accross all ways. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 16 10:51:29 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 May 2018 10:51:29 -0000 Subject: [GHC] #8089: Implementation of GHC.Event.Poll.poll is broken due to bad coercion In-Reply-To: <045.7e2f7bf1f77ecf8607cd3966531ffeb1@haskell.org> References: <045.7e2f7bf1f77ecf8607cd3966531ffeb1@haskell.org> Message-ID: <060.0229c5fb86134a8c3e293a3cca277556@haskell.org> #8089: Implementation of GHC.Event.Poll.poll is broken due to bad coercion -------------------------------------+------------------------------------- Reporter: merijn | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D407 Wiki Page: | -------------------------------------+------------------------------------- Comment (by alpmestan): These failures will be discussed in #15158. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 16 12:41:56 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 May 2018 12:41:56 -0000 Subject: [GHC] #13167: GC and weak reference finalizers and exceptions In-Reply-To: <044.f73010a4958317dc6bb4779ffc938be2@haskell.org> References: <044.f73010a4958317dc6bb4779ffc938be2@haskell.org> Message-ID: <059.18f84f781ddcfc7c841141a868fb2275@haskell.org> #13167: GC and weak reference finalizers and exceptions -------------------------------------+------------------------------------- Reporter: Yuras | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4693 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"01bb17fd4dc6d92cf08632bbb62656428db6e7fa/ghc" 01bb17fd/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="01bb17fd4dc6d92cf08632bbb62656428db6e7fa" Make finalizers more reliable. Ignore any errors thrown by finalizers when running them. This prevents a faulty finalizer from stopping the rest being called. Test Plan: ./validate, new test T13167 Reviewers: hvr, bgamari, simonmar Reviewed By: bgamari, simonmar Subscribers: rwbarton, thomie, carter GHC Trac Issues: #13167 Differential Revision: https://phabricator.haskell.org/D4693 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 16 12:55:16 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 May 2018 12:55:16 -0000 Subject: [GHC] #11066: Inacessible branch should be warning - otherwise breaks type soundness? In-Reply-To: <047.0785946e31f05741dc32414264d84d16@haskell.org> References: <047.0785946e31f05741dc32414264d84d16@haskell.org> Message-ID: <062.6bbecd669ad05a4a79bbbd41f3dc5c3c@haskell.org> #11066: Inacessible branch should be warning - otherwise breaks type soundness? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #8128, #8740 | Differential Rev(s): Phab:D1454 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > But that doesn't seem right. It seems fine to me, arguably. The equality `a~b` is not needed; running `unsafe3` will never seg-fault. It's not worth losing sleep over this. BTW, if it's now a warning do we have a flag to control whether the warning is enabled? We should. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 16 13:27:43 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 May 2018 13:27:43 -0000 Subject: [GHC] #15126: Opportunity to compress common info table representation. In-Reply-To: <047.6c1989d395bea7068f3a9a80b2222326@haskell.org> References: <047.6c1989d395bea7068f3a9a80b2222326@haskell.org> Message-ID: <062.58061776c189b71a9dda747106dedd3a@haskell.org> #15126: Opportunity to compress common info table representation. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4632 Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * differential: => Phab:D4632 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 16 13:30:19 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 May 2018 13:30:19 -0000 Subject: [GHC] #11066: Inacessible branch should be warning - otherwise breaks type soundness? In-Reply-To: <047.0785946e31f05741dc32414264d84d16@haskell.org> References: <047.0785946e31f05741dc32414264d84d16@haskell.org> Message-ID: <062.c8be82ee3c22cd05961870498afcd7fe@haskell.org> #11066: Inacessible branch should be warning - otherwise breaks type soundness? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #8128, #8740 | Differential Rev(s): Phab:D1454 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Replying to [comment:45 simonpj]: > > But that doesn't seem right. > > It seems fine to me, arguably. The equality `a~b` is not needed; running `unsafe3` will never seg-fault. Right, of course... it's nonsensical code, but it won't blow up. I just found it peculiar that the "Inaccessible code" warning doesn't fire at all anymore. > BTW, if it's now a warning do we have a flag to control whether the warning is enabled? We should. Not yet, but I was going to add one. Just didn't want to put in that effort while it was still unclear whether we go through with this. I would suggest that we turn it on by default though; it's generally a useful warning to have, and disabling it is probably something you'd only want to do when you know what you're doing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 16 13:37:18 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 May 2018 13:37:18 -0000 Subject: [GHC] #15158: T8089 failing with ghci, threaded1, threaded2, profthreaded In-Reply-To: <048.e0a32f56c09af74c66cfdba0027fd931@haskell.org> References: <048.e0a32f56c09af74c66cfdba0027fd931@haskell.org> Message-ID: <063.a0fd2e6802cd6fa3a52c285cc99e2afa@haskell.org> #15158: T8089 failing with ghci, threaded1, threaded2, profthreaded -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: T8089 Blocked By: | Blocking: Related Tickets: #8089, #7325, | Differential Rev(s): #15064 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: #8089 => #8089, #7325, #15064 Comment: #7325 and #15064 are also relevant. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 16 14:25:40 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 May 2018 14:25:40 -0000 Subject: [GHC] #13857: compactAdd doesn't work with SmallArray# In-Reply-To: <049.63d32166f598a80d4ab31076e3e7e75b@haskell.org> References: <049.63d32166f598a80d4ab31076e3e7e75b@haskell.org> Message-ID: <064.d02b05437ab0f5e112cb39034ad160e8@haskell.org> #13857: compactAdd doesn't work with SmallArray# -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Runtime System | Version: 8.2.1-rc2 Resolution: | Keywords: compact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3888 Wiki Page: | -------------------------------------+------------------------------------- Changes (by andrewthad): * status: closed => new * resolution: fixed => Comment: This still doesn't work correctly as noted by rfbacon on a reddit thread: https://www.reddit.com/r/haskell/comments/8juajl/attempt_to_compact_hashmap_results_in_a_crash/ Consider the following example: {{{ import GHC.Compact import Data.Primitive.SmallArray import Control.Monad.ST (runST) main :: IO () main = do _ <- compact (runST (newSmallArray 12 (55 :: Integer) >>= unsafeFreezeSmallArray)) putStrLn "done" }}} This causes the program to crash at runtime with an out of memory error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 16 14:28:31 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 May 2018 14:28:31 -0000 Subject: [GHC] #13167: GC and weak reference finalizers and exceptions In-Reply-To: <044.f73010a4958317dc6bb4779ffc938be2@haskell.org> References: <044.f73010a4958317dc6bb4779ffc938be2@haskell.org> Message-ID: <059.eefbe193f1e0ea9e091d5dc99a122595@haskell.org> #13167: GC and weak reference finalizers and exceptions -------------------------------------+------------------------------------- Reporter: Yuras | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4693 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: patch => closed * resolution: => fixed * milestone: => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 16 14:34:50 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 May 2018 14:34:50 -0000 Subject: [GHC] #13857: compactAdd doesn't work with SmallArray# In-Reply-To: <049.63d32166f598a80d4ab31076e3e7e75b@haskell.org> References: <049.63d32166f598a80d4ab31076e3e7e75b@haskell.org> Message-ID: <064.ffc7cbcdc40fefad23a9c986fda142ca@haskell.org> #13857: compactAdd doesn't work with SmallArray# -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Runtime System | Version: 8.2.1-rc2 Resolution: | Keywords: compact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3888 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Can you verify that the problem is with `SmallArray` and not `Integer`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 16 14:35:28 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 May 2018 14:35:28 -0000 Subject: [GHC] #13857: compactAdd doesn't work with SmallArray# In-Reply-To: <049.63d32166f598a80d4ab31076e3e7e75b@haskell.org> References: <049.63d32166f598a80d4ab31076e3e7e75b@haskell.org> Message-ID: <064.e9b2f2c78ac0c5f0a95f089bb0f469a0@haskell.org> #13857: compactAdd doesn't work with SmallArray# -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Runtime System | Version: 8.2.1-rc2 Resolution: | Keywords: compact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3888 Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): The reason why this wasn't caught earlier is that the test for compacting `SmallArray#` doesn't actually work. From D3888, we have [this test https://phabricator.haskell.org/differential/changeset/?ref=174725&whitespace =ignore-most]: {{{ import GHC.Compact import Data.Primitive.SmallArray main :: IO () main = do arr <- newSmallArray 5 (Just 'a') arr' <- compact arr print $ getCompact arr' }}} However, this fails at runtime with {{{ compact_hash_map: compaction failed: cannot compact mutable objects }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 16 14:36:16 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 May 2018 14:36:16 -0000 Subject: [GHC] #13857: compactAdd doesn't work with SmallArray# In-Reply-To: <049.63d32166f598a80d4ab31076e3e7e75b@haskell.org> References: <049.63d32166f598a80d4ab31076e3e7e75b@haskell.org> Message-ID: <064.d6e13dd19eb4beecfab6a6b3608e66cd@haskell.org> #13857: compactAdd doesn't work with SmallArray# -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Runtime System | Version: 8.2.1-rc2 Resolution: | Keywords: compact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3888 Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): @dfeuer Yes, I get the same problem if I try this with `Int` instead of `Integer`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 16 14:38:50 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 May 2018 14:38:50 -0000 Subject: [GHC] #13857: compactAdd doesn't work with SmallArray# In-Reply-To: <049.63d32166f598a80d4ab31076e3e7e75b@haskell.org> References: <049.63d32166f598a80d4ab31076e3e7e75b@haskell.org> Message-ID: <064.59963ec4ed59b1ceabbb82af1ecff04a@haskell.org> #13857: compactAdd doesn't work with SmallArray# -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Runtime System | Version: 8.2.1-rc2 Resolution: | Keywords: compact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3888 Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): In fact, if we correct the test in GHC's test suite, we can see that it fails as well: {{{ import GHC.Compact import Data.Primitive.SmallArray main :: IO () main = do arr <- newSmallArray 5 (Just 'a') >>= unsafeFreezeSmallArray arr' <- compact arr putStrLn "done" }}} This fails with: {{{ compact_hash_map: out of memory }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 16 14:47:05 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 May 2018 14:47:05 -0000 Subject: [GHC] #15158: T8089 failing with ghci, threaded1, threaded2, profthreaded In-Reply-To: <048.e0a32f56c09af74c66cfdba0027fd931@haskell.org> References: <048.e0a32f56c09af74c66cfdba0027fd931@haskell.org> Message-ID: <063.ed15b57843a185634efb55f9cf599f77@haskell.org> #15158: T8089 failing with ghci, threaded1, threaded2, profthreaded -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: T8089 Blocked By: | Blocking: Related Tickets: #8089, #7325, | Differential Rev(s): #15064 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): It looks to me like there is a bug in the event manager. Specifically, it apparently makes no attempt to handle overflow when computing expiration times. Namely, `GHC.Event.TimerManager.registerTimeout` has: {{{#!hs now <- getMonotonicTimeNSec let expTime = fromIntegral us * 1000 + now }}} Even worse, we currently throw away the delay requested by the user, meaning it is no longer possible to account for overflow after registration. This can be fixed, but will require a bit more allocation in timeout registration. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 16 16:19:24 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 May 2018 16:19:24 -0000 Subject: [GHC] #15158: T8089 failing with ghci, threaded1, threaded2, profthreaded In-Reply-To: <048.e0a32f56c09af74c66cfdba0027fd931@haskell.org> References: <048.e0a32f56c09af74c66cfdba0027fd931@haskell.org> Message-ID: <063.689e648e226137ac2c2be1e1f3b995c0@haskell.org> #15158: T8089 failing with ghci, threaded1, threaded2, profthreaded -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: libraries/base | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: T8089 Blocked By: | Blocking: Related Tickets: #8089, #7325, | Differential Rev(s): Phab:D4700 #15064 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D4700 * milestone: => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 16 16:29:24 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 May 2018 16:29:24 -0000 Subject: [GHC] #14040: Typed holes regression in GHC 8.0.2: No skolem info: z_a1sY[sk:2] In-Reply-To: <050.973ad933fee1878607a6ab042ec05467@haskell.org> References: <050.973ad933fee1878607a6ab042ec05467@haskell.org> Message-ID: <065.733c7158ab496e82ee97b47ec528b3eb@haskell.org> #14040: Typed holes regression in GHC 8.0.2: No skolem info: z_a1sY[sk:2] -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.0.2 checker) | Keywords: TypeInType, Resolution: fixed | TypeFamilies, | PartialTypeSignatures, TypedHoles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: partial- crash or panic | sigs/should_fail/T14040a Blocked By: | Blocking: Related Tickets: #13877, #15076 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): There's still something wrong here, in the original program. Even if we write {{{ elimWeirdList x = error "urk" }}} GHC HEAD still complains mysteriously about the type signature {{{ T14040a.hs:21:18: error: • Couldn't match type ‘k0’ with ‘a’ because type variable ‘a’ would escape its scope This (rigid, skolem) type variable is bound by the type signature for: elimWeirdList :: forall a1 (wl :: WeirdList a1) (p :: forall x. x -> WeirdList x -> *). Sing wl -> (forall y. p k0 w0 'WeirdNil) -> (forall z1 (x :: z1) (xs :: WeirdList (WeirdList z1)). Sing x -> Sing xs -> p k1 w1 xs -> p k2 w2 ('WeirdCons x xs)) -> p k3 w3 wl at T14040a.hs:(21,18)-(28,23) Expected type: Sing wl -> (forall y. p k1 w0 'WeirdNil) -> (forall z1 (x :: z1) (xs :: WeirdList (WeirdList z1)). Sing x -> Sing xs -> p k0 w1 xs -> p k2 w2 ('WeirdCons x xs)) -> p k3 w3 wl Actual type: Sing wl -> (forall y. p k1 w0 'WeirdNil) -> (forall z1 (x :: z1) (xs :: WeirdList (WeirdList z1)). Sing x -> Sing xs -> p k0 w1 xs -> p k2 w2 ('WeirdCons x xs)) -> p k3 w3 wl • In the ambiguity check for ‘elimWeirdList’ To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the type signature: elimWeirdList :: forall (a :: Type) (wl :: WeirdList a) (p :: forall (x :: Type). x -> WeirdList x -> Type). Sing wl -> (forall (y :: Type). p _ WeirdNil) -> (forall (z :: Type) (x :: z) (xs :: WeirdList (WeirdList z)). Sing x -> Sing xs -> p _ xs -> p _ (WeirdCons x xs)) -> p _ wl | 21 | elimWeirdList :: forall (a :: Type) (wl :: WeirdList a) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^... T14040a.hs:29:1: error: Can't quantify over ‘a’ bound by the partial type signature: elimWeirdList :: forall (a :: Type) (wl :: WeirdList a) (p :: forall (x :: Type). x -> WeirdList x -> Type). Sing wl -> (forall (y :: Type). p _ WeirdNil) -> (forall (z :: Type) (x :: z) (xs :: WeirdList (WeirdList z)). Sing x -> Sing xs -> p _ xs -> p _ (WeirdCons x xs)) -> p _ wl | 29 | elimWeirdList x = error "urk" | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ T14040a.hs:29:1: error: Can't quantify over ‘wl’ bound by the partial type signature: elimWeirdList :: forall (a :: Type) (wl :: WeirdList a) (p :: forall (x :: Type). x -> WeirdList x -> Type). Sing wl -> (forall (y :: Type). p _ WeirdNil) -> (forall (z :: Type) (x :: z) (xs :: WeirdList (WeirdList z)). Sing x -> Sing xs -> p _ xs -> p _ (WeirdCons x xs)) -> p _ wl | 29 | elimWeirdList x = error "urk" | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ T14040a.hs:29:1: error: Can't quantify over ‘p’ bound by the partial type signature: elimWeirdList :: forall (a :: Type) (wl :: WeirdList a) (p :: forall (x :: Type). x -> WeirdList x -> Type). Sing wl -> (forall (y :: Type). p _ WeirdNil) -> (forall (z :: Type) (x :: z) (xs :: WeirdList (WeirdList z)). Sing x -> Sing xs -> p _ xs -> p _ (WeirdCons x xs)) -> p _ wl | 29 | elimWeirdList x = error "urk" | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 16 17:55:16 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 May 2018 17:55:16 -0000 Subject: [GHC] #15073: Unable to newtype derive `Prim` via DerivingStrategies In-Reply-To: <047.b85af09eb39d6271dfdb97c1ad8ee86f@haskell.org> References: <047.b85af09eb39d6271dfdb97c1ad8ee86f@haskell.org> Message-ID: <062.83c25c11d2c47567157c516f29429808@haskell.org> #15073: Unable to newtype derive `Prim` via DerivingStrategies -------------------------------------+------------------------------------- Reporter: fosskers | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4620 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I propose some language to clarify this in the users guide in Phab:D4701. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 16 17:58:35 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 May 2018 17:58:35 -0000 Subject: [GHC] #13857: compactAdd doesn't work with SmallArray# In-Reply-To: <049.63d32166f598a80d4ab31076e3e7e75b@haskell.org> References: <049.63d32166f598a80d4ab31076e3e7e75b@haskell.org> Message-ID: <064.16925e60c0fb464e3bff9356e9037e6c@haskell.org> #13857: compactAdd doesn't work with SmallArray# -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Runtime System | Version: 8.2.1-rc2 Resolution: | Keywords: compact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3888 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Whoops, I believe I see the issue. Patch coming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 16 18:05:17 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 May 2018 18:05:17 -0000 Subject: [GHC] #15126: Opportunity to compress common info table representation. In-Reply-To: <047.6c1989d395bea7068f3a9a80b2222326@haskell.org> References: <047.6c1989d395bea7068f3a9a80b2222326@haskell.org> Message-ID: <062.3ab815edff75427cb6cc1c2acdd62e35@haskell.org> #15126: Opportunity to compress common info table representation. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4632 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): Phab:D4634 reduces the size of info tables with an SRT by one word on x86_64, which implements some (but perhaps not all) of the opportunities for savings mentioned here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 16 18:16:13 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 May 2018 18:16:13 -0000 Subject: [GHC] #13857: compactAdd doesn't work with SmallArray# In-Reply-To: <049.63d32166f598a80d4ab31076e3e7e75b@haskell.org> References: <049.63d32166f598a80d4ab31076e3e7e75b@haskell.org> Message-ID: <064.da96bb2b698a23e04eb4c1dacee84657@haskell.org> #13857: compactAdd doesn't work with SmallArray# -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Runtime System | Version: 8.2.1-rc2 Resolution: | Keywords: compact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3888 Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): Thanks! Any chance this will make 8.4.3? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 16 18:45:50 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 May 2018 18:45:50 -0000 Subject: [GHC] #13857: compactAdd doesn't work with SmallArray# In-Reply-To: <049.63d32166f598a80d4ab31076e3e7e75b@haskell.org> References: <049.63d32166f598a80d4ab31076e3e7e75b@haskell.org> Message-ID: <064.9d873e292f576881ca2e130d00f63ad0@haskell.org> #13857: compactAdd doesn't work with SmallArray# -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Runtime System | Version: 8.2.1-rc2 Resolution: | Keywords: compact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3888 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Yes, I think we can sneak it in. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 16 19:40:47 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 May 2018 19:40:47 -0000 Subject: [GHC] #15039: Bizarre pretty-printing of inferred Coercible constraint in partial type signature In-Reply-To: <050.aaadeac0c3786f879c5b76ef15d4ae09@haskell.org> References: <050.aaadeac0c3786f879c5b76ef15d4ae09@haskell.org> Message-ID: <065.476444b97ca602d1ae332c2ecb51fe10@haskell.org> #15039: Bizarre pretty-printing of inferred Coercible constraint in partial type signature -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.1 checker) | Keywords: Resolution: | PartialTypeSignatures, TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4696 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"99f8cc84a5b23878b3b0732955cb651bc973e9f2/ghc" 99f8cc84/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="99f8cc84a5b23878b3b0732955cb651bc973e9f2" Fix #15039 by pretty-printing equalities more systematically GHC previously had a handful of special cases for pretty-printing equalities in a more user-friendly manner, but they were far from comprehensive (see #15039 for an example of where this fell apart). This patch makes the pretty-printing of equalities much more systematic. I've adopted the approach laid out in https://ghc.haskell.org/trac/ghc/ticket/15039#comment:4, and updated `Note [Equality predicates in IfaceType]` accordingly. We are now more careful to respect the properties of the `-fprint-explicit-kinds` and `-fprint-equality-relations` flags, which led to some improvements in error message outputs. Along the way, I also tweaked the error-reporting machinery not to print out the type of a typed hole when the type is an unlifted equality, since it's kind (`TYPE ('TupleRep '[])`) was more confusing than anything. Test Plan: make test TEST="T15039a T15039b T15039c T15039d" Reviewers: simonpj, goldfire, bgamari Reviewed By: simonpj Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15039 Differential Revision: https://phabricator.haskell.org/D4696 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 16 19:40:47 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 May 2018 19:40:47 -0000 Subject: [GHC] #15081: Finite list becomes infinite after maping fractional function for high numbers In-Reply-To: <044.f762bf620383822c5337aa8807210278@haskell.org> References: <044.f762bf620383822c5337aa8807210278@haskell.org> Message-ID: <059.fab14d3cb727f168247e1ec0fd5480e1@haskell.org> #15081: Finite list becomes infinite after maping fractional function for high numbers -------------------------------------+------------------------------------- Reporter: Onsed | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | libraries/base/tests/enumNumeric Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4650 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"4ffaf4b67773af4c72d92bb8b6c87b1a7d34ac0f/ghc" 4ffaf4b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4ffaf4b67773af4c72d92bb8b6c87b1a7d34ac0f" Improve numeric stability of numericEnumFrom for floating numbers Fixes #15081. Test Plan: cd libraries/base && make test TEST="enumNumeric" Reviewers: hvr, bgamari Reviewed By: bgamari Subscribers: dfeuer, simonpj, thomie, carter GHC Trac Issues: #15081 Differential Revision: https://phabricator.haskell.org/D4650 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 16 19:40:47 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 May 2018 19:40:47 -0000 Subject: [GHC] #15073: Unable to newtype derive `Prim` via DerivingStrategies In-Reply-To: <047.b85af09eb39d6271dfdb97c1ad8ee86f@haskell.org> References: <047.b85af09eb39d6271dfdb97c1ad8ee86f@haskell.org> Message-ID: <062.5700606bc540431ab9ba935fbd6d44af@haskell.org> #15073: Unable to newtype derive `Prim` via DerivingStrategies -------------------------------------+------------------------------------- Reporter: fosskers | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4620 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"0c7db226012b5cfafc9a38bfe372661672ec8900/ghc" 0c7db226/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0c7db226012b5cfafc9a38bfe372661672ec8900" Fix #15073 by suggesting UnboxedTuples in an error message Under certain circumstances, `GeneralizedNewtypeDeriving` can emit code which uses unboxed tuple types, but if `UnboxedTuples` wasn't enabled, the error message that GHC gave didn't make it very clear that it could be worked around by explicitly enabling the extension. Easily fixed. Test Plan: make test TEST=T15073 Reviewers: bgamari Reviewed By: bgamari Subscribers: simonpj, thomie, carter GHC Trac Issues: #15073 Differential Revision: https://phabricator.haskell.org/D4620 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 16 19:54:11 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 May 2018 19:54:11 -0000 Subject: [GHC] #15060: outofmem testcase sometimes crashes on i386 In-Reply-To: <046.7122be6c9e363e21e924ee402fc4eb2a@haskell.org> References: <046.7122be6c9e363e21e924ee402fc4eb2a@haskell.org> Message-ID: <061.32a3e05e2ef1d5eb025b5ffb5388461c@haskell.org> #15060: outofmem testcase sometimes crashes on i386 -------------------------------------+----------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.2.2 Resolution: | Keywords: ci-breakage Operating System: Unknown/Multiple | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+----------------------------------- Comment (by bgamari): `gdb` has the following to say, {{{ outofmem: internal error: getMBlock: mmap: Invalid argument (GHC version 8.5.20180516 for i386_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Program received signal SIGABRT, Aborted. 0xf7d8be2c in __GI_raise (sig=sig at entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 0xf7d8be2c in __GI_raise (sig=sig at entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0xf7d8d4b3 in __GI_abort () at abort.c:89 #2 0x08306486 in rtsFatalInternalErrorFn (s=0x833e2dd "getMBlock: mmap: %s", ap=0xffffb4a4 "^\300\350\367\021") at rts/RtsMessages.c:188 #3 0x08306555 in barf (s=0x833e2dd "getMBlock: mmap: %s") at rts/RtsMessages.c:47 #4 0x08310036 in my_mmap_or_barf (addr=0x77900000, size=size at entry=1074790400, operation=3) at rts/posix/OSMem.c:233 #5 0x0831011b in osGetMBlocks (n=1025) at rts/posix/OSMem.c:291 #6 0x08309eb4 in getCommittedMBlocks (n=1025) at rts/sm/MBlock.c:534 #7 getMBlocks (n=1025) at rts/sm/MBlock.c:580 #8 0x0830a2d0 in alloc_mega_group (node=node at entry=0, mblocks=) at rts/sm/BlockAlloc.c:378 #9 0x0830a70a in allocGroupOnNode (node=0, n=262145) at rts/sm/BlockAlloc.c:405 #10 0x0830d12e in allocateMightFail (cap=0x8407600 , n=268435459) at rts/sm/Storage.c:884 #11 0x08314a61 in stg_newByteArrayzh () #12 0x08407600 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) (gdb) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 16 19:54:43 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 May 2018 19:54:43 -0000 Subject: [GHC] #14040: Typed holes regression in GHC 8.0.2: No skolem info: z_a1sY[sk:2] In-Reply-To: <050.973ad933fee1878607a6ab042ec05467@haskell.org> References: <050.973ad933fee1878607a6ab042ec05467@haskell.org> Message-ID: <065.25f8d5c4250f12a68acacb005a979410@haskell.org> #14040: Typed holes regression in GHC 8.0.2: No skolem info: z_a1sY[sk:2] -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.0.2 checker) | Keywords: TypeInType, Resolution: | TypeFamilies, | PartialTypeSignatures, TypedHoles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: partial- crash or panic | sigs/should_fail/T14040a Blocked By: | Blocking: Related Tickets: #13877, #15076 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: closed => new * owner: goldfire => (none) * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 16 20:04:22 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 May 2018 20:04:22 -0000 Subject: [GHC] #13857: compactAdd doesn't work with SmallArray# In-Reply-To: <049.63d32166f598a80d4ab31076e3e7e75b@haskell.org> References: <049.63d32166f598a80d4ab31076e3e7e75b@haskell.org> Message-ID: <064.da45df5412cb26496c25f988a5971079@haskell.org> #13857: compactAdd doesn't work with SmallArray# -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Runtime System | Version: 8.2.1-rc2 Resolution: | Keywords: compact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3888, Wiki Page: | Phab:D4702 -------------------------------------+------------------------------------- Changes (by bgamari): * differential: Phab:D3888 => Phab:D3888, Phab:D4702 Comment: Fix in Phab:D4702. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 16 20:28:08 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 May 2018 20:28:08 -0000 Subject: [GHC] #13857: compactAdd doesn't work with SmallArray# In-Reply-To: <049.63d32166f598a80d4ab31076e3e7e75b@haskell.org> References: <049.63d32166f598a80d4ab31076e3e7e75b@haskell.org> Message-ID: <064.21ee4636e9dcda33b00293891166e9e0@haskell.org> #13857: compactAdd doesn't work with SmallArray# -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.3 Component: Runtime System | Version: 8.2.1-rc2 Resolution: | Keywords: compact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3888, Wiki Page: | Phab:D4702 -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.2 => 8.4.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 16 20:28:26 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 May 2018 20:28:26 -0000 Subject: [GHC] #15060: outofmem testcase sometimes crashes on i386 In-Reply-To: <046.7122be6c9e363e21e924ee402fc4eb2a@haskell.org> References: <046.7122be6c9e363e21e924ee402fc4eb2a@haskell.org> Message-ID: <061.f5090203e077627fbeb7d7b56a83563f@haskell.org> #15060: outofmem testcase sometimes crashes on i386 -------------------------------------+----------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.3 Component: Runtime System | Version: 8.2.2 Resolution: | Keywords: ci-breakage Operating System: Unknown/Multiple | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4704 Wiki Page: | -------------------------------------+----------------------------------- Changes (by bgamari): * differential: => Phab:D4704 * milestone: 8.6.1 => 8.4.3 Comment: Ahh, I see what is happening here. `mmap` returns `ENOMEM` yet then we nevertheless try to `madvise`, which clobbers `errno`, giving us the unexpected `EINVAL` error. Consequently we don't detect this to be an out- of-memory error. Fix in Phab:D4704. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 16 21:03:06 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 May 2018 21:03:06 -0000 Subject: [GHC] #15112: ghc 8.4.2 on OS X: clang: warning: argument unused during compilation: '-nopie' In-Reply-To: <047.e2e05ed138c24fadcd4842fa8e08b91d@haskell.org> References: <047.e2e05ed138c24fadcd4842fa8e08b91d@haskell.org> Message-ID: <062.3d0bc29ac8de04e5f36d82727f5fc248@haskell.org> #15112: ghc 8.4.2 on OS X: clang: warning: argument unused during compilation: '-nopie' ---------------------------------+---------------------------------------- Reporter: elaforge | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by hvr): I investigated a bit, and for those wondering what is going on here, this is caused by a change in Apple's latest Xcode toolchain major version... as usual... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 16 21:15:43 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 May 2018 21:15:43 -0000 Subject: [GHC] #15099: Missing instances for Data.Monoid.Alt In-Reply-To: <045.026b0504cddc6774e706c3e5ef528903@haskell.org> References: <045.026b0504cddc6774e706c3e5ef528903@haskell.org> Message-ID: <060.7faf55593996b58da89bdedc0c4e463b@haskell.org> #15099: Missing instances for Data.Monoid.Alt -------------------------------------+------------------------------------- Reporter: ekmett | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jhenahan): Implemented in https://phabricator.haskell.org/D4698. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 16 22:06:46 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 May 2018 22:06:46 -0000 Subject: [GHC] #15099: Missing instances for Data.Monoid.Alt In-Reply-To: <045.026b0504cddc6774e706c3e5ef528903@haskell.org> References: <045.026b0504cddc6774e706c3e5ef528903@haskell.org> Message-ID: <060.8d50744577706c768aa638ffed35d576@haskell.org> #15099: Missing instances for Data.Monoid.Alt -------------------------------------+------------------------------------- Reporter: ekmett | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4698 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D4698 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 17 01:25:46 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 May 2018 01:25:46 -0000 Subject: [GHC] #14656: Nofib: Ignore cr-lineendings in benchmarks In-Reply-To: <047.9bef567ea530bf2617132f7e80ca6f4e@haskell.org> References: <047.9bef567ea530bf2617132f7e80ca6f4e@haskell.org> Message-ID: <062.4507213476274cd5aad0e0a198096f37@haskell.org> #14656: Nofib: Ignore cr-lineendings in benchmarks -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: NoFib benchmark | Version: 8.2.2 suite | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4705 Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * status: new => patch * differential: => Phab:D4705 Comment: Came across the cause by chance today. Their Makefiles marked the benchmark results as binary data instead of text. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 17 05:26:41 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 May 2018 05:26:41 -0000 Subject: [GHC] #15159: Expand compatibility note for readMVar Message-ID: <045.0a3c0327f2a06472795232fea8be5521@haskell.org> #15159: Expand compatibility note for readMVar -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Core | Version: 8.2.2 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently, the note reads > Compatibility note: Prior to base 4.7, readMVar was a combination of takeMVar and putMVar. This mean that in the presence of other threads attempting to putMVar, readMVar could block. Furthermore, readMVar would not receive the next putMVar if there was already a pending thread blocked on takeMVar. The old behavior can be recovered by [...] I don't think this goes quite far enough. Consider the following scenario: {{{#!hs main = do mv <- newEmptyMVar forkIO $ putMVar mv "a" >> ... >> takeMVar mv >>= ... forkIO $ putMVar mv "b" >> ... >> takeMVar mv >>= ... ... readMVar mv }}} (assume none of the ...s touch `mv`) With the current implementation of `readMVar`, each child thread will put its value in the `MVar` and then take that same value out. They may do so in either order, and the order will determine what value the main thread reads. With the ''old'' implementation of `readMVar`, there are two additional (symmetrical) possibilities. In one, the first child puts `"a"`, the main thread takes `"a"`, the second child puts `"b"`, the first child takes `"b"`, the main thread puts `"a"`, and the second child takes `"a"`. So the old version of `readMVar` could make an interaction between other threads substantially less deterministic. I believe the note should probably reflect that. Its language also could really use some clarification in general. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 17 07:08:41 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 May 2018 07:08:41 -0000 Subject: [GHC] #15160: unregistersied GHC can't be built with ghc-HEAD: has no member named 'srt' Message-ID: <045.14426c2339b49b1c2992c7f23650370f@haskell.org> #15160: unregistersied GHC can't be built with ghc-HEAD: has no member named 'srt' -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Tried to build a few unregisterised targets today. All fail the same as x86_64 unregisterised: {{{ $ ./configure --enable-unregisterised --with-ghc=x86_64-HEAD-linux-gnu-ghc --enable-bootstrap-with-devel-snapshot --disable-ld-override $ make HSC2HS libraries/ghci/dist-boot/build/GHCi/InfoTable.hs In file included from /usr/x86_64-HEAD-linux- gnu/usr/include/bits/_G_config.h:19, from /usr/x86_64-HEAD-linux- gnu/usr/include/bits/libio.h:35, from /usr/x86_64-HEAD-linux-gnu/usr/include/stdio.h:41, from /usr/lib64/x86_64-HEAD-linux-gnu- ghc-8.5.20180509/include/rts/Flags.h:16, from /usr/lib64/x86_64-HEAD-linux-gnu- ghc-8.5.20180509/include/Rts.h:191, from InfoTable.hsc:4: InfoTable.hsc: In function 'main': /home/slyfox/dev/git/ghc-unreg/inplace/lib/template-hsc.h:75:24: error: 'StgInfoTable' {aka 'struct StgInfoTable_'} has no member named 'srt' (long) offsetof (t, f)); ^~~~~~~~ }}} Looks like this code needs an update against '''srt''' / '''has_srt''' (or it's another case of leaking build GHC headers into host ghc?): {{{#!hs peekItbl :: Ptr StgInfoTable -> IO StgInfoTable peekItbl a0 = do #if defined(TABLES_NEXT_TO_CODE) let entry' = Nothing #else entry' <- Just <$> (#peek StgInfoTable, entry) a0 #endif ptrs' <- (#peek StgInfoTable, layout.payload.ptrs) a0 nptrs' <- (#peek StgInfoTable, layout.payload.nptrs) a0 tipe' <- (#peek StgInfoTable, type) a0 #if __GLASGOW_HASKELL__ > 804 srtlen' <- (#peek StgInfoTable, srt) a0 #else srtlen' <- (#peek StgInfoTable, srt_bitmap) a0 #endif return StgInfoTable { entry = entry' , ptrs = ptrs' , nptrs = nptrs' , tipe = tipe' , srtlen = srtlen' , code = Nothing } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 17 08:08:19 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 May 2018 08:08:19 -0000 Subject: [GHC] #15160: unregistersied GHC can't be built with ghc-HEAD: has no member named 'srt' In-Reply-To: <045.14426c2339b49b1c2992c7f23650370f@haskell.org> References: <045.14426c2339b49b1c2992c7f23650370f@haskell.org> Message-ID: <060.695e85c83a34087b62f5cc2f1fd6c4e9@haskell.org> #15160: unregistersied GHC can't be built with ghc-HEAD: has no member named 'srt' -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): What GHC version were you using to bootstrap with? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 17 08:56:18 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 May 2018 08:56:18 -0000 Subject: [GHC] #15160: unregistersied GHC can't be built with ghc-HEAD: has no member named 'srt' In-Reply-To: <045.14426c2339b49b1c2992c7f23650370f@haskell.org> References: <045.14426c2339b49b1c2992c7f23650370f@haskell.org> Message-ID: <060.95e8d4471db0d596b49ce372a6a5948e@haskell.org> #15160: unregistersied GHC can't be built with ghc-HEAD: has no member named 'srt' -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by slyfox): {{{ $ x86_64-HEAD-linux-gnu-ghc --version The Glorious Glasgow Haskell Compilation System, version 8.5.20180509 }}} {{{ $ x86_64-HEAD-linux-gnu-ghc --info [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv -fno-builtin") ,("C compiler command","x86_64-HEAD-linux-gnu-gcc") ,("C compiler flags"," -fno-stack-protector") ,("C compiler link flags"," ") ,("C compiler supports -no-pie","YES") ,("Haskell CPP command","x86_64-HEAD-linux-gnu-gcc") ,("Haskell CPP flags","-E -undef -traditional") ,("ld command","x86_64-HEAD-linux-gnu-ld") ,("ld flags","") ,("ld supports compact unwind","YES") ,("ld supports build-id","YES") ,("ld supports filelist","NO") ,("ld is GNU ld","YES") ,("ar command","x86_64-HEAD-linux-gnu-ar") ,("ar flags","q") ,("ar supports at file","YES") ,("ranlib command","x86_64-HEAD-linux-gnu-ranlib") ,("touch command","touch") ,("dllwrap command","x86_64-HEAD-linux-gnu-dllwrap") ,("windres command","x86_64-HEAD-linux-gnu-windres") ,("libtool command","libtool") ,("perl command","/usr/bin/perl") ,("cross compiling","YES") ,("target os","OSLinux") ,("target arch","ArchX86_64") ,("target word size","8") ,("target has GNU nonexec stack","True") ,("target has .ident directive","True") ,("target has subsections via symbols","False") ,("target has RTS linker","YES") ,("Unregisterised","NO") ,("LLVM llc command","llc") ,("LLVM opt command","opt") ,("LLVM clang command","clang") ,("Project version","8.5.20180509") ,("Project Git commit id","5fe6aaa3756cda654374ebfd883fa8f064ff64a4") ,("Booter version","8.5.20180413") ,("Stage","1") ,("Build platform","x86_64-unknown-linux") ,("Host platform","x86_64-unknown-linux") ,("Target platform","x86_64-HEAD-linux") ,("Have interpreter","YES") ,("Object splitting supported","YES") ,("Have native code generator","YES") ,("Support SMP","NO") ,("Tables next to code","YES") ,("RTS ways","l debug thr thr_debug thr_l dyn debug_dyn thr_dyn thr_debug_dyn l_dyn thr_l_dyn") ,("RTS expects libdw","NO") ,("Support dynamic-too","YES") ,("Support parallel --make","YES") ,("Support reexported-modules","YES") ,("Support thinning and renaming package flags","YES") ,("Support Backpack","YES") ,("Requires unified installed package IDs","YES") ,("Uses package keys","YES") ,("Uses unit IDs","YES") ,("Dynamic by default","NO") ,("GHC Dynamic","NO") ,("GHC Profiled","NO") ,("Leading underscore","NO") ,("Debug on","False") ,("LibDir","/usr/lib64/x86_64-HEAD-linux-gnu-ghc-8.5.20180509") ,("Global Package DB","/usr/lib64/x86_64-HEAD-linux-gnu- ghc-8.5.20180509/package.conf.d") ] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 17 10:43:42 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 May 2018 10:43:42 -0000 Subject: [GHC] #15160: unregistersied GHC can't be built with ghc-HEAD: has no member named 'srt' In-Reply-To: <045.14426c2339b49b1c2992c7f23650370f@haskell.org> References: <045.14426c2339b49b1c2992c7f23650370f@haskell.org> Message-ID: <060.69b6959d4963714877f0a2efc0d3ca03@haskell.org> #15160: unregistersied GHC can't be built with ghc-HEAD: has no member named 'srt' -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => invalid Comment: So this is the problem: we don't officially support building GHC with an arbitrary HEAD snapshot, only released versions. In this case it failed because the `#if __GLASGOW_HASKELL__ > 804` was true, but you wanted it to be false for your snapshot. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 17 12:20:37 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 May 2018 12:20:37 -0000 Subject: [GHC] #15073: Unable to newtype derive `Prim` via DerivingStrategies In-Reply-To: <047.b85af09eb39d6271dfdb97c1ad8ee86f@haskell.org> References: <047.b85af09eb39d6271dfdb97c1ad8ee86f@haskell.org> Message-ID: <062.d39de61fd36b12535a6fe513ca71d272@haskell.org> #15073: Unable to newtype derive `Prim` via DerivingStrategies -------------------------------------+------------------------------------- Reporter: fosskers | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4620, Wiki Page: | Phab:D4701 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: deriving/should_fail/T15073 (added) * differential: Phab:D4620 => Phab:D4620, Phab:D4701 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 17 12:22:20 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 May 2018 12:22:20 -0000 Subject: [GHC] #15039: Bizarre pretty-printing of inferred Coercible constraint in partial type signature In-Reply-To: <050.aaadeac0c3786f879c5b76ef15d4ae09@haskell.org> References: <050.aaadeac0c3786f879c5b76ef15d4ae09@haskell.org> Message-ID: <065.d6a5a01a252d448bc1b7c33bcf1aa2be@haskell.org> #15039: Bizarre pretty-printing of inferred Coercible constraint in partial type signature -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.1 checker) | Keywords: Resolution: fixed | PartialTypeSignatures, TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4696 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * cc: partial-sigs/should_compile/T15039a, partial- sigs/should_compile/T15039b, partial-sigs/should_compile/T15039c, partial- sigs/should_compile/T15039d (added) * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 17 12:28:11 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 May 2018 12:28:11 -0000 Subject: [GHC] #15143: Passing an IO value through several functions results in program hanging. In-Reply-To: <048.73b9ec11a636d72a48f971cab3c258d0@haskell.org> References: <048.73b9ec11a636d72a48f971cab3c258d0@haskell.org> Message-ID: <063.b0732c4f55a67a2d33485831590c3182@haskell.org> #15143: Passing an IO value through several functions results in program hanging. -------------------------------------+------------------------------------- Reporter: Burtannia | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by danilo2): Hi! I think I might get similar problem. However, no minimal example here (unless you will need some). The code is pretty simple, I'm building a "fold-like" function with type classes: {{{ class Monad m => FoldableLayer t m layer where buildLayerFold :: ∀ layout. Layer.Cons layer layout -> m (Result t) -> m (Result t) class Monad m => LayerFoldableBuilder__ (active :: Bool) t m layer where buildLayerFold__ :: SomePtr -> m (Result t) -> m (Result t) instance {-# OVERLAPPABLE #-} Monad m => LayerFoldableBuilder__ 'False t m layer where buildLayerFold__ = \(!_) (!a) -> !a ; {-# INLINE buildLayerFold__ #-} instance (Monad m, Layer.StorableLayer layer m, FoldableLayer t m layer) => LayerFoldableBuilder__ 'True t m layer where buildLayerFold__ = \(!ptr) (!mr) -> do !layer <- Layer.unsafePeekWrapped @layer ptr !r <- mr -- | Performance buildLayerFold @t @m @layer layer $! pure r {-# INLINE buildLayerFold__ #-} }}} The problem is that if I change the last two lines to {{{ buildLayerFold @t @m @layer layer mr -- mr instead of pure r }}} The performance is 2 times slower while evaluating it. The `m` is a `State` over `IO`. Basically I am building here an action and this code change should not affect anything - because this action is just a function composition and will be evaluated eventually. I was initially thinking this might be related to strictness on the result, but that is apparently not the case. Even if I change the code to: {{{ !_ <- mr buildLayerFold @t @m @layer layer mr }}} I get the same slow results (2 times slower than the fast version). I don't see any reason why would it happen and this bug could be related. Thanks @iamrecursion for showing it to me! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 17 12:43:29 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 May 2018 12:43:29 -0000 Subject: [GHC] #12387: Template Haskell ignores class instance definitions with methods that don't belong to the class In-Reply-To: <050.eb69c313a059df9b62466d07df30fd0b@haskell.org> References: <050.eb69c313a059df9b62466d07df30fd0b@haskell.org> Message-ID: <065.9dca4a7668152395417ea31cce960614@haskell.org> #12387: Template Haskell ignores class instance definitions with methods that don't belong to the class -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): To address my hunch in the original description, it turns out that the same issue does //not// affect associated type family instances. That is, if you try compiling this program: {{{#!hs {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE TypeFamilies #-} {-# OPTIONS_GHC -ddump-splices #-} module Main where import GHC.Generics import Language.Haskell.TH.Lib data Foo = Foo $(do d <- instanceD (cxt []) (conT ''Eq `appT` conT ''Foo) [tySynInstD ''Rep $ tySynEqn [conT ''Foo] (conT ''Maybe)] return [d]) main :: IO () main = print $ Foo == Foo }}} Then it will rightly complain about `Rep` not being an associated type of `Eq`: {{{ $ /opt/ghc/8.4.2/bin/ghc Bug.hs [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Bug.hs:(11,3)-(13,15): Splicing declarations do d_a2Bz <- instanceD (cxt []) (conT ''Eq `appT` conT ''Foo) [tySynInstD ''Rep $ tySynEqn [conT ''Foo] (conT ''Maybe)] return [d_a2Bz] ======> instance Eq Foo where type Rep Foo = Maybe Bug.hs:11:3: error: • Class ‘Eq’ does not have an associated type ‘Rep’ • In the type instance declaration for ‘Rep’ In the instance declaration for ‘Eq Foo’ | 11 | $(do d <- instanceD (cxt []) (conT ''Eq `appT` conT ''Foo) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^... }}} That's because this particular validity check is performed [http://git.haskell.org/ghc.git/blob/5f15d53a98ad2f26465730d8c3463ccc58f6d94a:/compiler/typecheck/TcValidity.hs#l1635 during typechecking], not renaming. This makes me believe that postponing the analogous check for class methods would also be wise (i.e., simonpj's second bullet point in comment:1). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 17 12:47:20 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 May 2018 12:47:20 -0000 Subject: [GHC] #15153: GHC uses O_NONBLOCK on regular files, which has no effect, and blocks the runtime In-Reply-To: <042.2f3205a88421ca45196ab3bf4e5a61ff@haskell.org> References: <042.2f3205a88421ca45196ab3bf4e5a61ff@haskell.org> Message-ID: <057.48a9d2b70c1d6adad89cff37abd3c362@haskell.org> #15153: GHC uses O_NONBLOCK on regular files, which has no effect, and blocks the runtime -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.2.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): Yeah, this is well known. O_NONBLOCK doesn't do anything for local disk files, but it also doesn't do any harm. It's not usually a big problem except when the filesystem actually has significant latency, like with NFS or an arbitrary fuse filesystem. I think I was worried about the overhead of using safe calls here, the problem is that if you have lots of threads all reading from Handles (e.g. sockets) then if those reads are safe calls we'll get a large number of real OS threads created. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 17 12:53:02 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 May 2018 12:53:02 -0000 Subject: [GHC] #12387: Template Haskell ignores class instance definitions with methods that don't belong to the class In-Reply-To: <050.eb69c313a059df9b62466d07df30fd0b@haskell.org> References: <050.eb69c313a059df9b62466d07df30fd0b@haskell.org> Message-ID: <065.385b6f9f538956f0a46652c2f5b1ee02@haskell.org> #12387: Template Haskell ignores class instance definitions with methods that don't belong to the class -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Well, perhaps the phrase "postponing" isn't quite accurate. It turns out that for associated type family instances, membership in a class is tested //twice//, once during renaming and once during typechecking. comment:3 shows an example of the latter, and this demonstrates the former: {{{#!hs {-# LANGUAGE TypeFamilies #-} module Foo where import GHC.Generics instance Eq () where type Rep () = Maybe }}} {{{ $ /opt/ghc/8.4.2/bin/ghc Bug.hs [1 of 1] Compiling Foo ( Bug.hs, Bug.o ) Bug.hs:7:8: error: ‘Rep’ is not a (visible) associated type of class ‘Eq’ | 7 | type Rep () = Maybe | ^^^ }}} So it might suffice to just check class membership for class methods additionally during typechecking, just like we do for associated type family instances. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 17 13:08:42 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 May 2018 13:08:42 -0000 Subject: [GHC] #15065: T12903(profasm) produces a heap profile with out of sequence samples In-Reply-To: <048.77dde6f3e8d9d8fd59d17f4e21a2e02a@haskell.org> References: <048.77dde6f3e8d9d8fd59d17f4e21a2e02a@haskell.org> Message-ID: <063.081e6e3ca5076df315916e5800d1e6a1@haskell.org> #15065: T12903(profasm) produces a heap profile with out of sequence samples ---------------------------------+--------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Profiling | Version: 8.5 Resolution: wontfix | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: T12903(profasm) Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+--------------------------------------- Changes (by alpmestan): * status: new => closed * resolution: => wontfix Comment: This does not seem to happen on Circle CI, where we run the slow validation script. I will just omit the `profasm` way, too unreliable. I'm also closing this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 17 13:29:00 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 May 2018 13:29:00 -0000 Subject: [GHC] #15088: Test T3234 is fragile In-Reply-To: <049.b4734c814119c3f6b3a53330ff37ca44@haskell.org> References: <049.b4734c814119c3f6b3a53330ff37ca44@haskell.org> Message-ID: <064.6c8a71edea0fe2d086c56c07fe0aca18@haskell.org> #15088: Test T3234 is fragile -------------------------------------+------------------------------------- Reporter: mpickering | Owner: RolandSenn Type: task | Status: new Priority: lowest | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * owner: (none) => RolandSenn Comment: As a newcomer, I'll work on this. If I don't do any progress till end of June 2018, I'll unassign. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 17 13:43:34 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 May 2018 13:43:34 -0000 Subject: [GHC] #13838: -Wdeferred-type-errors on a program with main not of type IO () yields "main thread exited (uncaught exception)" In-Reply-To: <044.5150fbc131040d8653d1692d9b8b36a2@haskell.org> References: <044.5150fbc131040d8653d1692d9b8b36a2@haskell.org> Message-ID: <059.a95a886aabddf8183d0fce739f21da7c@haskell.org> #13838: -Wdeferred-type-errors on a program with main not of type IO () yields "main thread exited (uncaught exception)" -------------------------------------+------------------------------------- Reporter: harry | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13292 | Differential Rev(s): Phab:D4708 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sighingnow): * status: new => patch * differential: => Phab:D4708 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 17 14:16:04 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 May 2018 14:16:04 -0000 Subject: [GHC] #15161: ghci cannot find symbols defined by TH's addForeignFilePath Message-ID: <048.94ff49299bd53697b04c43fdf0c03eaa@haskell.org> #15161: ghci cannot find symbols defined by TH's addForeignFilePath --------------------------------------+--------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.5 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: T14298 | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- This causes T14298 to fail in the `ghci` way, for example: {{{#!sh $ make fulltest TEST="T14298" ... =====> T14298(ghci) 1 of 1 [0, 0, 0] cd "./th/T14298.run" && "/home/alp/WT/ghc-slow-validate/inplace/test spaces/ghc-stage2" T14298.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -XTemplateHaskell -package template-haskell --interactive -v0 -ignore-dot- ghci -fno-ghci-history +RTS -I0.1 -RTS -v0< T14298.genscript Actual stderr output differs from expected: diff -uw "/dev/null" "./th/T14298.run/T14298.run.stderr.normalised" --- /dev/null 2018-05-11 09:42:48.644575222 +0200 +++ ./th/T14298.run/T14298.run.stderr.normalised 2018-05-17 15:59:33.340172963 +0200 @@ -0,0 +1,13 @@ +ghc: ^^ Could not load 'foo', dependency unresolved. See top entry above. + + +ByteCodeLink: can't find label +During interactive linking, GHCi couldn't find the following symbol: + foo +This may be due to you not asking GHCi to load extra object files, +archives or DLLs needed by your current session. Restart GHCi, specifying +the missing library using the -L/path/to/object/dir and -lmissinglibname +flags, or simply by naming the relevant files on the GHCi command line. +Alternatively, this link failure might indicate a bug in GHCi. +If you suspect the latter, please send a bug report to: + glasgow-haskell-bugs at haskell.org *** unexpected failure for T14298(ghci) }}} More generally, there is some phasing issue and Ben indicated to me we would have to suspend the compilation of the current file, compile and link the foreign one and then resume. For now I'll just mark T14298 as expected broken for the `ghci` way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 17 14:18:44 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 May 2018 14:18:44 -0000 Subject: [GHC] #15111: GHCi leaks the first modules loaded In-Reply-To: <047.0c4c39abd5bd384dc6fc34801a3d6baa@haskell.org> References: <047.0c4c39abd5bd384dc6fc34801a3d6baa@haskell.org> Message-ID: <062.23dea5b616429ccc210350cd2a60e540@haskell.org> #15111: GHCi leaks the first modules loaded -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: ghci Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4658 Wiki Page: | Phab:D4659 -------------------------------------+------------------------------------- Comment (by Simon Marlow ): In [changeset:"f27e4f624fe1270e8027ff0a14f03514f5be31b7/ghc" f27e4f6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f27e4f624fe1270e8027ff0a14f03514f5be31b7" Fix GHCi space leaks (#15111) Summary: There were a number of leaks causing previously loaded modules to be retained after a new `:load`. This fixes enough leaks to get the tests to pass from D4658. Test Plan: See new tests in D4658 Reviewers: niteria, bgamari, simonpj, erikd Subscribers: thomie, carter GHC Trac Issues: #15111 Differential Revision: https://phabricator.haskell.org/D4659 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 17 14:20:01 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 May 2018 14:20:01 -0000 Subject: [GHC] #14179: "Conflicting family instance" error pretty prints data family instances poorly In-Reply-To: <050.3b34f958a96d53100d1cde9c870ee0f4@haskell.org> References: <050.3b34f958a96d53100d1cde9c870ee0f4@haskell.org> Message-ID: <065.ba7005fd86cb4c821f1d3695395d4754@haskell.org> #14179: "Conflicting family instance" error pretty prints data family instances poorly -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): This is an interesting one. I think that the solution here might be to pretty-print conflicting data family instances slightly differently than conflicting data family instances, for two reasons: 1. Type family instances are unique in that you have can have duplicate instances (see #14440). Thus, the pretty-printer //must// show their right-hand sides, because otherwise a user wouldn't know why they were conflicting. Data family instances, on the other hand, do not permit duplicates. These conflict, for instance: {{{#!hs data family Foo a data instance Foo a data instance Foo a }}} 2. The right-hand side of a data family instance can be quite large if there are many constructors. We could address this with `pprDeeperList`, but it's of questionable utility, since a. We might be suppressing the constructors in which two data family instance differ, and b. Part 1. brings into question whether it's worth going through this trouble in the first place, since the constructors themselves aren't the thing which causes data family instances to conflict. In light of this, I would propose simply pretty-printing the data family instances without any constructors at all. In other words, for the programs in the original description, I would propose having these be the respective error messages: {{{ Bug.hs:5:15: error: Conflicting family instance declarations: Fam Int -- Defined at Bug.hs:5:15 Fam Int -- Defined at Bug.hs:6:15 | 5 | data instance Fam Int | ^^^ }}} {{{ Bug.hs:6:15: error: Conflicting family instance declarations: Fam :: * -> * -- Defined at Bug.hs:6:15 Fam :: * -> * -- Defined at Bug.hs:7:15 | 6 | data instance Fam :: * -> * | ^^^ }}} And for the program in comment:1: {{{ Bug.hs:6:15: error: Conflicting family instance declarations: Fam [a] -- Defined at Bug.hs:6:15 Fam [a] -- Defined at Bug.hs:9:15 | 6 | data instance Fam [a] where | ^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 17 14:20:05 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 May 2018 14:20:05 -0000 Subject: [GHC] #15111: GHCi leaks the first modules loaded In-Reply-To: <047.0c4c39abd5bd384dc6fc34801a3d6baa@haskell.org> References: <047.0c4c39abd5bd384dc6fc34801a3d6baa@haskell.org> Message-ID: <062.8129193812f04988c01408c3a8529c01@haskell.org> #15111: GHCi leaks the first modules loaded -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: ghci Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4658 Wiki Page: | Phab:D4659 -------------------------------------+------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 17 14:31:12 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 May 2018 14:31:12 -0000 Subject: [GHC] #12387: Template Haskell ignores class instance definitions with methods that don't belong to the class In-Reply-To: <050.eb69c313a059df9b62466d07df30fd0b@haskell.org> References: <050.eb69c313a059df9b62466d07df30fd0b@haskell.org> Message-ID: <065.6da8e0683727725fe0366aa31b6b12e5@haskell.org> #12387: Template Haskell ignores class instance definitions with methods that don't belong to the class -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4710 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D4710 Comment: I've implemented the idea from comment:4 in Phab:D4710. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 17 14:37:28 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 May 2018 14:37:28 -0000 Subject: [GHC] #15162: armv7l-unknown-linux-gnueabihf is missing from llvm-targets Message-ID: <046.38959772a24aab5f60714cbb324b4d29@haskell.org> #15162: armv7l-unknown-linux-gnueabihf is missing from llvm-targets --------------------------------+--------------------------------- Reporter: ggardet | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Keywords: | Operating System: Linux Architecture: arm | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+--------------------------------- While trying to build GHC 8.4.2, we face the following error: {{{ [15143s] ghc-stage1: panic! (the 'impossible' happened) [15143s] (GHC version 8.4.2 for arm-unknown-linux): [15143s] Failed to lookup the datalayout for armv7l-unknown-linux- gnueabihf; available targets: ["i386-unknown-windows","i686-unknown- windows","x86_64-unknown-windows","arm-unknown-linux-gnueabihf","armv6 -unknown-linux-gnueabihf","armv7-unknown-linux-gnueabihf","aarch64 -unknown-linux-gnu","aarch64-unknown-linux","armv7a-unknown-linux- gnueabi","i386-unknown-linux-gnu","i386-unknown-linux","x86_64-unknown- linux-gnu","x86_64-unknown-linux","armv7-unknown-linux- androideabi","aarch64-unknown-linux-android","arm-unknown-nto-qnx- eabi","i386-apple-darwin","x86_64-apple-darwin","armv7-apple-ios","aarch64 -apple-ios","i386-apple-ios","x86_64-apple-ios"] }}} So, we should add armv7l-unknown-linux-gnueabihf to ./utils/llvm-targets /gen-data-layout.sh and regenerate llvm-targets file. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 17 14:44:07 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 May 2018 14:44:07 -0000 Subject: [GHC] #14370: improve documentation of -fdefer-typed-holes for naked expressions in ghci In-Reply-To: <044.22e5f2aa694f3f07f37c874e3f79e431@haskell.org> References: <044.22e5f2aa694f3f07f37c874e3f79e431@haskell.org> Message-ID: <059.df8684da72e985d7144ad0d3f4097709@haskell.org> #14370: improve documentation of -fdefer-typed-holes for naked expressions in ghci -------------------------------------+------------------------------------- Reporter: int-e | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.2.1 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by sighingnow): I think that the `Opt_DeferOutOfScopeVariables` isn't cancelled for naked expression in ghci should be a bug. Allowing `length [r]` is also unhelpful and may lead to some confusion for newcomers. I think this should be fixed as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 17 14:55:43 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 May 2018 14:55:43 -0000 Subject: [GHC] #15153: GHC uses O_NONBLOCK on regular files, which has no effect, and blocks the runtime In-Reply-To: <042.2f3205a88421ca45196ab3bf4e5a61ff@haskell.org> References: <042.2f3205a88421ca45196ab3bf4e5a61ff@haskell.org> Message-ID: <057.be40f66ba1ca3504d3c0b073db993ada@haskell.org> #15153: GHC uses O_NONBLOCK on regular files, which has no effect, and blocks the runtime -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.2.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): Replying to [comment:3 simonmar]: > It's not usually a big problem except when the filesystem actually has significant latency, like with NFS or an arbitrary fuse filesystem. What about my example though? I'm just reading a 3GB file using `BS.readFile` and it blocks other threads for 30 seconds. (My file system doens't have unexpected latency in terms of access time, it's a normal spinning disk, and the problem is the time it takes to read the data. Though I find it reasonablye to argue that the ~8ms it may take to seek this disk is ''also'' a lot of wasted CPU time, that's not the key problem in my example.) > I think I was worried about the overhead of using safe calls here, the problem is that if you have lots of threads all reading from Handles (e.g. sockets) then if those reads are safe calls we'll get a large number of real OS threads created. The concern about overhead makes sense to me, but I find it easy to argue that there's more overheard in having all other resources of a machine (CPU, network, other disks) idle while a single disk arm is moving. And the time for a `pthread_create` is rather small compared to a read of any physical storage device. Another argument is that if examples like the one I gave don't work, it is very hard to build reasonable heartbeating of long-running IO tasks in Haskell. > O_NONBLOCK doesn't do anything for local disk files, but it also doesn't do any harm What I meant is that from a quick look at the code, it looked like if O_NONBLOCK isn't set, a `safe` call would be made instead. In the spirit of https://ghc.haskell.org/trac/ghc/ticket/13296#comment:3 and the followup comment, would it be a good default to have reads to be `safe`, and offer `unsafe` equivalents when you know that the read will be very fast? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 17 15:02:12 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 May 2018 15:02:12 -0000 Subject: [GHC] #15155: How untagged pointers sneak into banged fields In-Reply-To: <048.7d229d504bd9df060a5294d6d9eccfdc@haskell.org> References: <048.7d229d504bd9df060a5294d6d9eccfdc@haskell.org> Message-ID: <063.a28b46d08d256442a08e179f30c814da@haskell.org> #15155: How untagged pointers sneak into banged fields -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 14677 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): I didn't really follow the description here. Naively I'd expect `c` to compile into a CAF, like `c = case b of b' -> C b'` and then we'd be fine. If the compiler is assuming that `b` is already a value and thus avoiding evaluating it, that would be a false assumption. Where is the false assumption being made? I think the `IND_STATIC` stuff is a red herring. There's a top-level binding `b = a` which is compiled into an `IND_STATIC` as an optimisation, but it could also be compiled into a CAF, this is just a back-end code- generation choice. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 17 15:05:49 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 May 2018 15:05:49 -0000 Subject: [GHC] #14179: "Conflicting family instance" error pretty prints data family instances poorly In-Reply-To: <050.3b34f958a96d53100d1cde9c870ee0f4@haskell.org> References: <050.3b34f958a96d53100d1cde9c870ee0f4@haskell.org> Message-ID: <065.6b9f85cb7fa13796056da7320980422f@haskell.org> #14179: "Conflicting family instance" error pretty prints data family instances poorly -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): comment:2 sounds plausible to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 17 15:17:38 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 May 2018 15:17:38 -0000 Subject: [GHC] #15088: Test T3234 is fragile In-Reply-To: <049.b4734c814119c3f6b3a53330ff37ca44@haskell.org> References: <049.b4734c814119c3f6b3a53330ff37ca44@haskell.org> Message-ID: <064.53d192797183aa8e18fc118a6b45bf0d@haskell.org> #15088: Test T3234 is fragile -------------------------------------+------------------------------------- Reporter: mpickering | Owner: RolandSenn Type: task | Status: new Priority: lowest | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Thanks Roland! Do let us know if you have any questions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 17 15:40:22 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 May 2018 15:40:22 -0000 Subject: [GHC] #15112: ghc 8.4.2 on OS X: clang: warning: argument unused during compilation: '-nopie' In-Reply-To: <047.e2e05ed138c24fadcd4842fa8e08b91d@haskell.org> References: <047.e2e05ed138c24fadcd4842fa8e08b91d@haskell.org> Message-ID: <062.7357ce77d98b2c489473e1b72995ce6e@haskell.org> #15112: ghc 8.4.2 on OS X: clang: warning: argument unused during compilation: '-nopie' ---------------------------------+---------------------------------------- Reporter: elaforge | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by mcandre): Same error on my machine. I am working around this by using ghc 8.2 instead of ghc HEAD: {{{ $ brew install ghc at 8.2 $ brew link --force ghc at 8.2 $ brew install cabal-install }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 17 15:42:36 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 May 2018 15:42:36 -0000 Subject: [GHC] #15163: non coercion variable in coVarKindsTypesRole Message-ID: <048.b3dbe8c60de34c10b2c3141afc368cad@haskell.org> #15163: non coercion variable in coVarKindsTypesRole -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: T14732 | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It is triggered by T14732... in the `profasm` way, and only that one. {{{#!sh $ make fulltest TEST="T14732" THREADS=4 =====> T14732(profasm) 1 of 1 [0, 0, 0] cd "./typecheck/should_compile/T14732.run" && "/home/alp/WT/ghc-slow- validate/inplace/test spaces/ghc-stage2" -c T14732.hs -dcore-lint -dcmm- lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow- warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno- debug-output -fno-warn-incomplete-patterns -O -prof -static -fprof-auto Compile failed (exit code 1) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.5.20180511 for x86_64-unknown-linux): coVarKindsTypesRole, non coercion variable as_atY Vector a_a2sO Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1162:37 in ghc:Outputable pprPanic, called at compiler/types/Coercion.hs:376:16 in ghc:Coercion Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for T14732(profasm) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 17 15:49:59 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 May 2018 15:49:59 -0000 Subject: [GHC] #14670: -XRebindableSyntax needs return? In-Reply-To: <048.c96b42d6aefe76220126edbb094e21e4@haskell.org> References: <048.c96b42d6aefe76220126edbb094e21e4@haskell.org> Message-ID: <063.06d0cfa1449cdbd185382d7d43249552@haskell.org> #14670: -XRebindableSyntax needs return? -------------------------------------+------------------------------------- Reporter: jackkelly | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | RebindableSyntax,ApplicativeDo Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | rebindable/T14670 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * keywords: RebindableSyntax => RebindableSyntax,ApplicativeDo -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 17 15:53:46 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 May 2018 15:53:46 -0000 Subject: [GHC] #11774: Regression on GHC 8 branch (vs 7.10.3) when using the GHC API to parse code that uses TH In-Reply-To: <050.40af602ae9a228b0dca3c0dd3ac155f0@haskell.org> References: <050.40af602ae9a228b0dca3c0dd3ac155f0@haskell.org> Message-ID: <065.de5adee2f700abbeb984332868c4fd44@haskell.org> #11774: Regression on GHC 8 branch (vs 7.10.3) when using the GHC API to parse code that uses TH -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 8.0.1-rc2 Resolution: | Keywords: RemoteGHCi Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * keywords: => RemoteGHCi -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 17 15:55:34 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 May 2018 15:55:34 -0000 Subject: [GHC] #14576: Internal error when compiling TH code with profiling on Windows In-Reply-To: <044.c2e93e4cd6fa3bc5d229bcd4603864fa@haskell.org> References: <044.c2e93e4cd6fa3bc5d229bcd4603864fa@haskell.org> Message-ID: <059.2a5b5e8238a64c04f96da27a5666b241@haskell.org> #14576: Internal error when compiling TH code with profiling on Windows -------------------------------------+------------------------------------- Reporter: lazac | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 8.2.1 Resolution: | Keywords: RemoteGHCi Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * cc: simonmar (added) * keywords: => RemoteGHCi -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 17 15:56:29 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 May 2018 15:56:29 -0000 Subject: [GHC] #14574: Template Haskell Uniq ~ Int leads to external interpreter cross compilation trouble In-Reply-To: <044.13612547bcec0532b940b49a41a2177d@haskell.org> References: <044.13612547bcec0532b940b49a41a2177d@haskell.org> Message-ID: <059.aa2f13fb552ec467b127b5ac4e65900b@haskell.org> #14574: Template Haskell Uniq ~ Int leads to external interpreter cross compilation trouble -------------------------------------+------------------------------------- Reporter: luite | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: RemoteGHCi Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * cc: simonmar (added) * keywords: => RemoteGHCi -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 17 16:01:08 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 May 2018 16:01:08 -0000 Subject: [GHC] #14271: ghci hangs with -fexternal-interpreter -prof In-Reply-To: <047.35b6ee83038ae67884e53737c2b92695@haskell.org> References: <047.35b6ee83038ae67884e53737c2b92695@haskell.org> Message-ID: <062.8d1431aa6aea4b51a5590736d4829add@haskell.org> #14271: ghci hangs with -fexternal-interpreter -prof -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Resolution: | Keywords: RemoteGHCi Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * cc: Jaffacake (removed) * cc: simonmar (added) * keywords: => RemoteGHCi -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 17 16:01:40 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 May 2018 16:01:40 -0000 Subject: [GHC] #14012: External interpreter fails on FreeBSD In-Reply-To: <046.2b65587ea7267566cfeb67b314c36291@haskell.org> References: <046.2b65587ea7267566cfeb67b314c36291@haskell.org> Message-ID: <061.5b14afa5ee0a83bdd00307ff14f31e81@haskell.org> #14012: External interpreter fails on FreeBSD ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: RemoteGHCi Operating System: FreeBSD | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by simonmar): * keywords: => RemoteGHCi * cc: simonmar (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 17 16:02:28 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 May 2018 16:02:28 -0000 Subject: [GHC] #13184: :show bindings broken under -fexternal-interpreter In-Reply-To: <046.1d0d4d608cb951c5dc098dd3122d78ee@haskell.org> References: <046.1d0d4d608cb951c5dc098dd3122d78ee@haskell.org> Message-ID: <061.84eacffee571a01157554eb6b80a5aa1@haskell.org> #13184: :show bindings broken under -fexternal-interpreter -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: RemoteGHCi Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * keywords: => RemoteGHCi -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 17 16:05:18 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 May 2018 16:05:18 -0000 Subject: [GHC] #14179: "Conflicting family instance" error pretty prints data family instances poorly In-Reply-To: <050.3b34f958a96d53100d1cde9c870ee0f4@haskell.org> References: <050.3b34f958a96d53100d1cde9c870ee0f4@haskell.org> Message-ID: <065.0982e85b34f5f784674d85b90d8ec297@haskell.org> #14179: "Conflicting family instance" error pretty prints data family instances poorly -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4711 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D4711 Comment: Replying to [comment:3 simonpj]: > PS: The first sentence of comment:2 doesn't make sense though: "pretty- print conflicting data family instances slightly differently than conflicting data family instances". Maybe needs an edit. Good catch. Fixed. Alas, I wasn't able to do much about the kind signature thing, since by the time we call this error message, we've completely lost track of whether the original data family instance declaration was written with an explicit kind signature or not. Nevertheless, I've implemented the other suggestions in this thread in Phab:D4711, which substantially cleans up the error message (and will at the very least give results that make sense in //some// context). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 17 17:02:51 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 May 2018 17:02:51 -0000 Subject: [GHC] #14890: Make Linux slow validate green In-Reply-To: <046.a107a76cbb0183d36ada5ee5738b1b26@haskell.org> References: <046.a107a76cbb0183d36ada5ee5738b1b26@haskell.org> Message-ID: <061.7e9733e8dcda3e9b8a65f5b8a58cb1be@haskell.org> #14890: Make Linux slow validate green -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alpmestan Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D4546, D4636, Wiki Page: | D4712 -------------------------------------+------------------------------------- Changes (by alpmestan): * status: new => patch * differential: D4546 => D4546, D4636, D4712 Comment: I managed to get a green validate on circleci when running all the tests that were failing after my last patch (D4636). The patch that gets us there is now [https://phabricator.haskell.org/D4712 up on phab as D4712]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 17 17:44:08 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 May 2018 17:44:08 -0000 Subject: [GHC] #14510: GHC.ExecutionStack.showStackTrace broken In-Reply-To: <043.9685830b69e2246f2b96ccff19455218@haskell.org> References: <043.9685830b69e2246f2b96ccff19455218@haskell.org> Message-ID: <058.8185d0776f060d27d1d10791934d69dd@haskell.org> #14510: GHC.ExecutionStack.showStackTrace broken ---------------------------------+-------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by niteria): I've just tried with GHC HEAD and I get: {{{ $ ./testdwarf Stack trace: set_initial_registers (rts/Libdw.c:288.0) in /data/users/bnitka/ghc-14510/testdwarf dwfl_thread_getframes in get_one_thread_cb in /usr/lib64/libdw-0.168.so dwfl_getthreads in /usr/lib64/libdw-0.168.so dwfl_getthread_frames in /usr/lib64/libdw-0.168.so libdwGetBacktrace (rts/Libdw.c:259.0) in /data/users/bnitka/ghc-14510/testdwarf base_GHCziExecutionStackziInternal_collectStackTrace1_info (libraries/base/GHC/ExecutionStack/Internal.hsc:74.10) in /data/users/bnitka/ghc-14510/testdwarf base_GHCziExecutionStackziInternal_collectStackTrace1_info (libraries/base/GHC/ExecutionStack/Internal.hsc:74.10) in /data/users/bnitka/ghc-14510/testdwarf base_GHCziExecutionStack_showStackTrace1_info (libraries/base/GHC/ExecutionStack.hs:50.1) in /data/users/bnitka/ghc-14510/testdwarf base_GHCziBase_zdfMonadIO1_info (libraries/base/GHC/Base.hs:1389.1) in /data/users/bnitka/ghc-14510/testdwarf base_GHCziBase_zdfApplicativeIO2_info (libraries/base/GHC/Base.hs:1392.1) in /data/users/bnitka/ghc-14510/testdwarf stg_catch_frame_info (rts/Exception.cmm:372.1) in /data/users/bnitka/ghc-14510/testdwarf stg_stop_thread_info (rts/StgStartup.cmm:42.1) in /data/users/bnitka/ghc-14510/testdwarf StgRunIsImplementedInAssembler (rts/StgCRun.c:370.0) in /data/users/bnitka/ghc-14510/testdwarf scheduleWaitThread (rts/Schedule.c:453.0) in /data/users/bnitka/ghc-14510/testdwarf hs_main (rts/RtsMain.c:73.0) in /data/users/bnitka/ghc-14510/testdwarf in /data/users/bnitka/ghc-14510/testdwarf __libc_start_main in _start in /data/users/bnitka/ghc-14510/testdwarf }}} I had to modify it slightly for it to print anything: {{{ import GHC.ExecutionStack import Data.Maybe main :: IO () main = do putStrLn . fromMaybe "" =<< showStackTrace return () }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 17 17:58:07 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 May 2018 17:58:07 -0000 Subject: [GHC] #14510: GHC.ExecutionStack.showStackTrace broken In-Reply-To: <043.9685830b69e2246f2b96ccff19455218@haskell.org> References: <043.9685830b69e2246f2b96ccff19455218@haskell.org> Message-ID: <058.6a40d1df4135ef0a878686b37727c792@haskell.org> #14510: GHC.ExecutionStack.showStackTrace broken ---------------------------------+-------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by niteria): 5d3b15ecbf17b7747c2f7313a981c60a2d22904d got rid of this message for `-threaded`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 17 18:51:36 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 May 2018 18:51:36 -0000 Subject: [GHC] #15160: unregistersied GHC can't be built with ghc-HEAD: has no member named 'srt' In-Reply-To: <045.14426c2339b49b1c2992c7f23650370f@haskell.org> References: <045.14426c2339b49b1c2992c7f23650370f@haskell.org> Message-ID: <060.c967403fdbeed63de6a79f45b0d5d964@haskell.org> #15160: unregistersied GHC can't be built with ghc-HEAD: has no member named 'srt' -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by slyfox): Oh, I keep forgetting the rule about unsupported bootstrap from snapshot. Sorry for the noise! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 17 21:07:18 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 May 2018 21:07:18 -0000 Subject: [GHC] #15147: Type checker plugin receives Wanteds that are not completely unflattened In-Reply-To: <046.7de470c11f4eabed34171ca75a3b8063@haskell.org> References: <046.7de470c11f4eabed34171ca75a3b8063@haskell.org> Message-ID: <061.9c1b167202eafa024d6396f3e6d50290@haskell.org> #15147: Type checker plugin receives Wanteds that are not completely unflattened -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.1 checker) | Keywords: type checker Resolution: | plugins Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by adamgundry): I'm also seeing this trying to port `uom-plugin` to 8.4. Unfortunately I've got the details of how this works in GHC pretty well paged out, and I think the code may have evolved a bit since I worked on it. The original thinking was to avoid bothering typechecker plugins with the complications of flattening and zonking, on the basis that sets (well, lists) of constraints are a simpler model to work with. But perhaps in practice the plugin interface is so low level that we would be better off doing as little as possible before handing constraints over to the plugin. Assuming we can make it relatively easy for the plugin to flatten/zonk if it wants to, that is... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 17 21:41:13 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 May 2018 21:41:13 -0000 Subject: [GHC] #15147: Type checker plugin receives Wanteds that are not completely unflattened In-Reply-To: <046.7de470c11f4eabed34171ca75a3b8063@haskell.org> References: <046.7de470c11f4eabed34171ca75a3b8063@haskell.org> Message-ID: <061.d233e7954d3540b6082ed6557b626c62@haskell.org> #15147: Type checker plugin receives Wanteds that are not completely unflattened -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.1 checker) | Keywords: type checker Resolution: | plugins Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I am surprised about those fsks. But if you ''want'' it in unflattened form then rather than fix the bug we can just refrain from flattening. Would you like to send an email to ghc-devs to propose this change, explaining why? I'm fully open to whatever would be easiest for plugin authors. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 17 22:17:23 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 May 2018 22:17:23 -0000 Subject: [GHC] #15143: Passing an IO value through several functions results in program hanging. In-Reply-To: <048.73b9ec11a636d72a48f971cab3c258d0@haskell.org> References: <048.73b9ec11a636d72a48f971cab3c258d0@haskell.org> Message-ID: <063.3db8f9bda4654365c4d19cfdcc6fd69e@haskell.org> #15143: Passing an IO value through several functions results in program hanging. -------------------------------------+------------------------------------- Reporter: Burtannia | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by simonpj): Why do you think this is a bug? You are compputing {{{ incTime (incTime ( ... (incTime testObs) ... )) }}} where {{{ incTime :: IO Obs -> IO Obs incTime o = do obs <- o case obs of ObsTime t -> return $ ObsTime (t+1) _ -> o }}} Each call of `incTime` invokes its argument `o` twice. Since `o` is passed in as an argument, GHC ''must'' call it twice in case it has side effects. The alternative code {{{ incTime' o = do obs <- o case obs of ObsTime t -> return $ ObsTime (t+1) _ -> return obs }}} is not semantically equivalent. Imagine called {{{ incTime (do { updRef r (+ 1); return ObsTemp }) }}} then I expect the reference `r` to be incremented twice. But `incTime'` will only increment it once. So each call to `incTime o` calls `o` twice. But in the call `incTime (incTime o)`, we call `incTime o` twice; and each call calls `o` twice. Result: four calls to `o`. If the nest is 3 deep we get eigth calls and so on. In short, this program has exponential runtime ''by design'', and GHC faithfully does what you ask. In short, it looks fine to me. Do you agree? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 18 03:08:50 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 May 2018 03:08:50 -0000 Subject: [GHC] #15143: Passing an IO value through several functions results in program hanging. In-Reply-To: <048.73b9ec11a636d72a48f971cab3c258d0@haskell.org> References: <048.73b9ec11a636d72a48f971cab3c258d0@haskell.org> Message-ID: <063.b6caba674fe36cb169dc78e481dad808@haskell.org> #15143: Passing an IO value through several functions results in program hanging. -------------------------------------+------------------------------------- Reporter: Burtannia | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by Burtannia): Replying to [comment:6 simonpj]: First of all I'm very excited that you replied to this. Your financial contracts paper was of great interest and your talk(s) on writing a good dissertation / paper were a huge help! So thank you for those. Anyway, back to the issue at hand... > Each call of `incTime` invokes its argument `o` twice. After thinking through this for a while I think I understand what's happening. `o` is being evaluated both in `obs <- o` and with `_ -> o`? I wasn't thinking of `o` as a monadic computation and therefore I thought of `_ -> o` as just returning the input unchanged rather than evaluating it again. > {{{ > incTime (do { updRef r (+ 1); return ObsTemp }) > }}} I don't understand this example. What is `updRef` and what value is `ObsTemp` wrapping? Not that it matters because I agree that the observed behaviour with `incTime` is not a bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 18 03:16:29 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 May 2018 03:16:29 -0000 Subject: [GHC] #11197: Overeager deferred type errors In-Reply-To: <047.311058030fc6bc2d09ef05760e42135c@haskell.org> References: <047.311058030fc6bc2d09ef05760e42135c@haskell.org> Message-ID: <062.e9e73bc48220cb6892a2fc7bd339392b@haskell.org> #11197: Overeager deferred type errors -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sighingnow): When `-fdefer-type-errors` is enabled, the program {{{#!hs main = do putStrLn "Hi there." putStrLn 1 }}} works well. However the program {{{#!hs main = do putStrLn "Hi there." putStrLn True }}} emits the deferred type error message eagerly and doesn't execute `putStrLn "Hi there."`. In the first case, the type error is `EvVarDest evar`: {{{ Wanted = WC {wc_simple = [WD] $dNum_a1zB {0}:: Num String (CDictCan(psc))} }}} However in the second case, the type error is `HoleDest hole`: {{{ Wanted = WC {wc_simple = [WD] hole{co_a1zO} {0}:: (Bool :: *) GHC.Prim.~# ([Char] :: *)} }}} Seems that the coercion hole is placed at wrong place. This ticket may related to Trac #14584. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 18 03:52:25 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 May 2018 03:52:25 -0000 Subject: [GHC] #15143: Passing an IO value through several functions results in program hanging. In-Reply-To: <048.73b9ec11a636d72a48f971cab3c258d0@haskell.org> References: <048.73b9ec11a636d72a48f971cab3c258d0@haskell.org> Message-ID: <063.3286f80007040f7b08c3c89e277b72c8@haskell.org> #15143: Passing an IO value through several functions results in program hanging. -------------------------------------+------------------------------------- Reporter: Burtannia | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by Burtannia): Replying to [comment:5 danilo2]: I think you were right that it's to do with the strictness of the value. I don't know a huge amount but here is my interpretation. > {{{ > !r <- mr -- | Performance > buildLayerFold @t @m @layer layer $! pure r > }}} This performs the monadic action `mr`, binds the result to `r` and forces that value to be fully evaluated. `$! pure r` forces `pure r` to be fully evaluated. Note that `pure r` isn't a value, it's a monadic computation that returns a value. From what I understand, your test: > {{{ > !_ <- mr > buildLayerFold @t @m @layer layer mr > }}} isn't doing what you think it's doing. `!_ <- mr` says ''perform the monadic action `mr` and strictly evaluate its result''. You then pass the monadic action `mr` as an argument to the function on the next line. Note that the computation `mr` is not strictly evaluated here. Later during the execution, that computation will be performed again but must first be evaluated. I'm presuming this "second evaluation" is why it runs two times slower. Again I'm not 100% sure that I'm correct on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 18 07:00:14 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 May 2018 07:00:14 -0000 Subject: [GHC] #15162: armv7l-unknown-linux-gnueabihf is missing from llvm-targets In-Reply-To: <046.38959772a24aab5f60714cbb324b4d29@haskell.org> References: <046.38959772a24aab5f60714cbb324b4d29@haskell.org> Message-ID: <061.8ca27a446f490a658e108d4be9f05be3@haskell.org> #15162: armv7l-unknown-linux-gnueabihf is missing from llvm-targets ---------------------------------+------------------------------ Reporter: ggardet | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+------------------------------ Comment (by ggardet): github PR with the fix: https://github.com/ghc/ghc/pull/136 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 18 08:06:54 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 May 2018 08:06:54 -0000 Subject: [GHC] #15147: Type checker plugin receives Wanteds that are not completely unflattened In-Reply-To: <046.7de470c11f4eabed34171ca75a3b8063@haskell.org> References: <046.7de470c11f4eabed34171ca75a3b8063@haskell.org> Message-ID: <061.f47e9e253636848a7c3fbf9d9e867895@haskell.org> #15147: Type checker plugin receives Wanteds that are not completely unflattened -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.1 checker) | Keywords: type checker Resolution: | plugins Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by adamgundry): Well, it rather depends on the plugin: my `uom-plugin` and other existing plugins were designed to work on the basis of receiving fully unflattened constraints, and at the time that seemed the simplest thing to get working. Of course it depends on what the plugin is doing as to which is simplest, so I can well understand nfrisby having an opposite preference in his case. As I say, I don't mind terribly if the interface changes to supply unflattened constraints, provided there is a way to properly flatten them again in the plugin monad. That seems like it would require resolving this issue anyway, though? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 18 08:38:28 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 May 2018 08:38:28 -0000 Subject: [GHC] #15016: Referencing a do-bound variable in a rec block with ApplicativeDo results in variable not in scope during type checking In-Reply-To: <043.c6ab751e43c75f3489b4a7a11657679b@haskell.org> References: <043.c6ab751e43c75f3489b4a7a11657679b@haskell.org> Message-ID: <058.d60a96e04933a32c595b9b5145f27a11@haskell.org> #15016: Referencing a do-bound variable in a rec block with ApplicativeDo results in variable not in scope during type checking -------------------------------------+------------------------------------- Reporter: rjmk | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 8.4.3 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * cc: simonmar (added) * keywords: => ApplicativeDo -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 18 08:39:40 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 May 2018 08:39:40 -0000 Subject: [GHC] #14252: ApplicativeDo: Add compiler message about irrefutable pattern matches and Monad constraints In-Reply-To: <049.ba8647167d92eb8735a641eef09d2a89@haskell.org> References: <049.ba8647167d92eb8735a641eef09d2a89@haskell.org> Message-ID: <064.7dd04f07e4e5da422b7db51ead529a44@haskell.org> #14252: ApplicativeDo: Add compiler message about irrefutable pattern matches and Monad constraints -------------------------------------+------------------------------------- Reporter: mutantmell | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * cc: simonmar (added) * keywords: => ApplicativeDo -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 18 08:40:21 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 May 2018 08:40:21 -0000 Subject: [GHC] #15143: Passing an IO value through several functions results in program hanging. In-Reply-To: <048.73b9ec11a636d72a48f971cab3c258d0@haskell.org> References: <048.73b9ec11a636d72a48f971cab3c258d0@haskell.org> Message-ID: <063.92401e08c0db6650d1d0d70aa495aff2@haskell.org> #15143: Passing an IO value through several functions results in program hanging. -------------------------------------+------------------------------------- Reporter: Burtannia | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by danilo2): @Burtannia, thanks for the reply! Why do you think `mr` is not strictly evaluated there? It is a strict function argument, so it have to be evaluated at least to WHNF. This is State over IO, so probably there could be some unevaluated parts, like the inner tuple (not the tuple values, because this is a strict state) in the state monad definition, but in such case I don't see (yet) how it could affect the performance and why `!r <- mr` and `!_ <- mr` behave differently – they both force evaluation of all intermediate structures of the monadic stack. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 18 10:32:44 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 May 2018 10:32:44 -0000 Subject: [GHC] #989: Build GHC on Windows using Microsoft toolchain In-Reply-To: <047.96e16f269cc7176052a090de33c91146@haskell.org> References: <047.96e16f269cc7176052a090de33c91146@haskell.org> Message-ID: <062.f6ecf911949ed5bfc0521741df05dd05@haskell.org> #989: Build GHC on Windows using Microsoft toolchain ------------------------------------+------------------------------ Reporter: simonmar | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: ⊥ Component: Compiler | Version: Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+------------------------------ Comment (by Azel): Is that project to use Microsoft's toolchain instead of MinGW's still relevant? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 18 12:26:44 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 May 2018 12:26:44 -0000 Subject: [GHC] #15147: Type checker plugin receives Wanteds that are not completely unflattened In-Reply-To: <046.7de470c11f4eabed34171ca75a3b8063@haskell.org> References: <046.7de470c11f4eabed34171ca75a3b8063@haskell.org> Message-ID: <061.3f02b9cc02132dbf658ae92e9b084319@haskell.org> #15147: Type checker plugin receives Wanteds that are not completely unflattened -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.1 checker) | Keywords: type checker Resolution: | plugins Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Providing a way to flatten inside the plugin would be tricky I think. Better either to supply flattened or unflattened constraints. (I suppose we could offer both, with the plugin advertising which it wanted?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 18 12:43:56 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 May 2018 12:43:56 -0000 Subject: [GHC] #15143: Passing an IO value through several functions results in program hanging. In-Reply-To: <048.73b9ec11a636d72a48f971cab3c258d0@haskell.org> References: <048.73b9ec11a636d72a48f971cab3c258d0@haskell.org> Message-ID: <063.4b31c802a833bea6a2101aa187a533ef@haskell.org> #15143: Passing an IO value through several functions results in program hanging. -------------------------------------+------------------------------------- Reporter: Burtannia | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by simonpj): It is nothing to do with strictness! Consider {{{ foo :: IO Int -> IO Int foo a = do { i1 <- a ; i2 <- a ; return (i1+i2) } }}} This function must perform `a` twice. It is ''not'' ok to "optimise" it to {{{ foo a = do { i1 <- a ; return (i1+i1) } }}} Reason: `a` might have side effects (which must be performed twice) and it might return different values on its successive calls. In the example of this ticket, in `incTime` the action `o` must be called twice. And in the particular example, the action is another call to `incTime` which calls its `o` twice; and so on. Result: 2^n calls of the final action, hence exponential behaviour. Strictness and bangs have no effect on this story -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 18 13:18:26 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 May 2018 13:18:26 -0000 Subject: [GHC] #11197: Overeager deferred type errors In-Reply-To: <047.311058030fc6bc2d09ef05760e42135c@haskell.org> References: <047.311058030fc6bc2d09ef05760e42135c@haskell.org> Message-ID: <062.6693c21cfeefcf033004c3740fd63d5b@haskell.org> #11197: Overeager deferred type errors -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Here's what is happening. In the former case we get {{{ main = let { $dNum_a1d8 :: Num String [LclId] $dNum_a1d8 = Control.Exception.Base.typeError @ 'GHC.Types.LiftedRep @ (Num String) "blah blah blah } in let { $dMonad_axl :: Monad IO [LclId] $dMonad_axl = GHC.Base.$fMonadIO } in letrec { main_a1da :: IO () [LclId] main_a1da = >> @ IO $dMonad_axl @ () @ () (putStrLn (GHC.CString.unpackCString# "Hi there."#)) (putStrLn (fromInteger @ String $dNum_a1d8 1)); } in main_a1da }}} and the binding for `dNum_a1d8` can float inwards/be inlined. In the latter case we get {{{ main = case Control.Exception.Base.typeError @ ('GHC.Types.TupleRep '[]) @ ((Bool :: *) GHC.Prim.~# ([Char] :: *)) "blah blah blah" of co_a11b { __DEFAULT -> >> @ IO GHC.Base.$fMonadIO @ () @ () (putStrLn (GHC.CString.unpackCString# "Hi there."#)) (putStrLn (GHC.Types.True `cast` (Sub co_a11b :: (Bool :: *) ~R# ([Char] :: *)))) } }}} and the simplifier does not float in arbitrary case-expressions, for fear of changing error/termination behaviour. What do to? All I can think of is to make a special case for coercions, and be willing to float them in, on the grounds that evidence bindings are added by the compiler and should have as narrow scope as possible. Any objections? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 18 13:47:11 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 May 2018 13:47:11 -0000 Subject: [GHC] #15147: Type checker plugin receives Wanteds that are not completely unflattened In-Reply-To: <046.7de470c11f4eabed34171ca75a3b8063@haskell.org> References: <046.7de470c11f4eabed34171ca75a3b8063@haskell.org> Message-ID: <061.1d8a058b119d18a58a0d95ff8093c8d4@haskell.org> #15147: Type checker plugin receives Wanteds that are not completely unflattened -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.1 checker) | Keywords: Resolution: | TypeCheckerPlugins Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * keywords: type checker plugins => TypeCheckerPlugins Comment: In that case perhaps we should indeed offer both by adding a new field to `TcPlugin` with a boolean (or a more informative new data type)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 18 13:50:23 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 May 2018 13:50:23 -0000 Subject: [GHC] #11435: Evidence from TC Plugin triggers core-lint warning In-Reply-To: <047.84e4b39cae85829cc41b2b95d0dbdb9b@haskell.org> References: <047.84e4b39cae85829cc41b2b95d0dbdb9b@haskell.org> Message-ID: <062.b05bdb7bf238e0668f395668598133e8@haskell.org> #11435: Evidence from TC Plugin triggers core-lint warning -------------------------------------+------------------------------------- Reporter: jbracker | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: core-lint | warning evidence TypeCheckerPlugins Operating System: Linux | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * keywords: core-lint warning evidence type-checker plugin => core-lint warning evidence TypeCheckerPlugins -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 18 13:50:49 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 May 2018 13:50:49 -0000 Subject: [GHC] #10077: Providing type checker plugin on command line results in false cyclic import error In-Reply-To: <047.782b0d33638d12045ffab180b13fe3e7@haskell.org> References: <047.782b0d33638d12045ffab180b13fe3e7@haskell.org> Message-ID: <062.a70e683883baf906cfc6a70a4a8e25e8@haskell.org> #10077: Providing type checker plugin on command line results in false cyclic import error -------------------------------------+------------------------------------- Reporter: jbracker | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | TypeCheckerPlugins cycle imports Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect | (amd64) warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * keywords: typechecker plugin cycle imports => TypeCheckerPlugins cycle imports -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 18 13:52:51 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 May 2018 13:52:51 -0000 Subject: [GHC] #11457: Run type-checker plugins before GHC's solver In-Reply-To: <049.a8fb4e5f5bcb03aebd9c2ea03a73390b@haskell.org> References: <049.a8fb4e5f5bcb03aebd9c2ea03a73390b@haskell.org> Message-ID: <064.2950b90dd9b838f05549c3e0d7c01834@haskell.org> #11457: Run type-checker plugins before GHC's solver -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: | TypeCheckerPlugins Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * keywords: plugin => TypeCheckerPlugins -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 18 13:53:46 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 May 2018 13:53:46 -0000 Subject: [GHC] #11525: Using a dummy typechecker plugin causes an ambiguity check error In-Reply-To: <042.ec775bcbbb96ef3ddf90f6d58883ad88@haskell.org> References: <042.ec775bcbbb96ef3ddf90f6d58883ad88@haskell.org> Message-ID: <057.d974bc6973e0c643a2494aa77d1c4d1d@haskell.org> #11525: Using a dummy typechecker plugin causes an ambiguity check error -------------------------------------+------------------------------------- Reporter: jme | Owner: darchon Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: fixed | UndecidableSuperClasses, | TypeCheckerPlugins Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: T11525 Blocked By: | Blocking: Related Tickets: #12780 | Differential Rev(s): Phab:D3105 Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * keywords: UndecidableSuperClasses, plugin => UndecidableSuperClasses, TypeCheckerPlugins -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 18 13:57:12 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 May 2018 13:57:12 -0000 Subject: [GHC] #11462: Use of typechecker plugin erroneously triggers "unbound implicit parameter" error In-Reply-To: <042.e058b949ddfb9ef1b73d598691d8a53f@haskell.org> References: <042.e058b949ddfb9ef1b73d598691d8a53f@haskell.org> Message-ID: <057.8eb4a9f570e17bbf4d8dabeca5f04433@haskell.org> #11462: Use of typechecker plugin erroneously triggers "unbound implicit parameter" error -------------------------------------+------------------------------------- Reporter: kwf | Owner: gridaphobe Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: fixed | TypeCheckerPlugins Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: T11462 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1804 Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * keywords: => TypeCheckerPlugins -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 18 13:58:26 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 May 2018 13:58:26 -0000 Subject: [GHC] #9980: TcS monad is too heavy In-Reply-To: <046.9f2f16945c1ea3d5dff728997ee3b117@haskell.org> References: <046.9f2f16945c1ea3d5dff728997ee3b117@haskell.org> Message-ID: <061.9759e01e96bcba0e3b892d66b1d0ad90@haskell.org> #9980: TcS monad is too heavy -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: | TypeCheckerPlugins Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * cc: adamgundry (added) * keywords: => TypeCheckerPlugins -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 18 13:58:45 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 May 2018 13:58:45 -0000 Subject: [GHC] #10078: tcPluginStop of a type checker plugin is not called if an error occurs In-Reply-To: <047.16df386c919a47dafd4f6f3cdd1a95cb@haskell.org> References: <047.16df386c919a47dafd4f6f3cdd1a95cb@haskell.org> Message-ID: <062.0f2c6654da66a5ec6534c83a4d4ee927@haskell.org> #10078: tcPluginStop of a type checker plugin is not called if an error occurs -------------------------------------+------------------------------------- Reporter: jbracker | Owner: jbracker Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: fixed | TypeCheckerPlugins Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * keywords: => TypeCheckerPlugins -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 18 14:01:47 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 May 2018 14:01:47 -0000 Subject: [GHC] #12780: Calling "do nothing" type checker plugin affects type checking when it shouldn't In-Reply-To: <046.701ac1658f414a768fc3ee00bdc8b2b5@haskell.org> References: <046.701ac1658f414a768fc3ee00bdc8b2b5@haskell.org> Message-ID: <061.c41f0b172c21b99e2572dc1d83d2d74d@haskell.org> #12780: Calling "do nothing" type checker plugin affects type checking when it shouldn't -------------------------------------+------------------------------------- Reporter: clinton | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | TypeCheckerPlugins Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11525 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * keywords: => TypeCheckerPlugins Comment: This is fixed in 8.2.1 and later, I think? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 18 14:03:13 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 May 2018 14:03:13 -0000 Subject: [GHC] #9840: Permit empty closed type families In-Reply-To: <049.f6cb0287f38c1240334c026f83ab01f9@haskell.org> References: <049.f6cb0287f38c1240334c026f83ab01f9@haskell.org> Message-ID: <064.641c3bf41428a3b551731d94b32cf7d2@haskell.org> #9840: Permit empty closed type families -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.8.3 checker) | Keywords: Resolution: fixed | TypeCheckerPlugins Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_compile/T9840 Blocked By: | Blocking: Related Tickets: #8028 | Differential Rev(s): Phab:D841 Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * keywords: => TypeCheckerPlugins -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 18 14:08:12 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 May 2018 14:08:12 -0000 Subject: [GHC] #15164: Slowdown in ghc compile times from GHC 8.0.2 to GHC 8.2.1 when doing Called arity analysis Message-ID: <046.d99bd58e6ad83ef24f9a7879b45c43ac@haskell.org> #15164: Slowdown in ghc compile times from GHC 8.0.2 to GHC 8.2.1 when doing Called arity analysis -------------------------------------+------------------------------------- Reporter: flip101 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hello, I have this program that compiles against packages of stack LTS-9.21. When i compile with GHC 8.0.2 (version of LTS-9.21) the compiling is fast. 72.01user 34.61system 0:52.98elapsed 201%CPU (0avgtext+0avgdata 600684maxresident)k When i upgrade to LTS-11.9 compiling gets slow. To test if it was a problem with new package or GHC (ghc gives some new packages too) i ran: /usr/bin/time stack build --compiler ghc-8.2.1 --ghc-options="-v3 -j4 -O2 -fexcess-precision -optc-O3 -optc-ffast-math -rtsopts=none -no-rtsopts- suggestions" with the old package of LTS-9.21 but with the newer GHC 8.2.1 compiler. Now the compile times are much higher: 2481.26user 663.66system 35:38.82elapsed 147%CPU (0avgtext+0avgdata 674732maxresident)k I already took out parts of the grammar to get it even to compile. When i have the full grammar i can let my laptop compile 24 hours and it's still busy. I was not sure how to further reduce the code. Maybe when a lot of effort i can cut out a few lines here and there. So i uploaded the entire project here https://github.com/flip111/parser-calledarityanalysis i already took out a lot of code. If anyone has suggestions on how to further reduce the code i can try. Because i had debug info on (-v3 flag) i saw it was stuck for a long time at "Called arity analysis" I prioritize this bug high because i think the slowdown is very problematic. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 18 14:18:59 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 May 2018 14:18:59 -0000 Subject: [GHC] #14691: Replace EvTerm with CoreExpr In-Reply-To: <046.62945affcc6cc14a9778d709349ac741@haskell.org> References: <046.62945affcc6cc14a9778d709349ac741@haskell.org> Message-ID: <061.636b925e4e9c0810c408401cc2a59857@haskell.org> #14691: Replace EvTerm with CoreExpr -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.3 checker) | Keywords: Resolution: | TypeCheckerPlugins Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * keywords: => TypeCheckerPlugins Comment: @nomeata is this ticket now fully implemented? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 18 14:27:09 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 May 2018 14:27:09 -0000 Subject: [GHC] #14691: Replace EvTerm with CoreExpr In-Reply-To: <046.62945affcc6cc14a9778d709349ac741@haskell.org> References: <046.62945affcc6cc14a9778d709349ac741@haskell.org> Message-ID: <061.81c173c0137d7fba3674932e0b9780a9@haskell.org> #14691: Replace EvTerm with CoreExpr -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.3 checker) | Keywords: Resolution: fixed | TypeCheckerPlugins Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => closed * resolution: => fixed Comment: > @nomeata is this ticket now fully implemented? Yes, at least as good as I managed to do it (there is still the `EvTypeable` constructor, as explained in the commit message). But it is good enough for the libraries (e.g. [ghc- justdoit](http://hackage.haskell.org/package/ghc-justdoit)), so this can be considered done. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 18 14:53:27 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 May 2018 14:53:27 -0000 Subject: [GHC] #14419: Check kinds for ambiguity In-Reply-To: <047.d18eb04be9d12ce25dfa15e5d81080b3@haskell.org> References: <047.d18eb04be9d12ce25dfa15e5d81080b3@haskell.org> Message-ID: <062.2dd289f65d8eada42dfc5d6ef0482c0b@haskell.org> #14419: Check kinds for ambiguity -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): After faec8d358985e5d0bf363bd96f23fe76c9e281f7, this is partially done. This data type's kind is currently rejected for being ambiguous: {{{#!hs type family F a data T1 :: forall a. F a -> Type }}} However, it would be premature to call this issue fixed, since the following two data types with very similar kinds are //not// rejected as ambiguous: {{{#!hs data T2 :: F a -> Type data T3 (b :: F a) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 18 15:06:02 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 May 2018 15:06:02 -0000 Subject: [GHC] #15164: Slowdown in ghc compile times from GHC 8.0.2 to GHC 8.2.1 when doing Called arity analysis In-Reply-To: <046.d99bd58e6ad83ef24f9a7879b45c43ac@haskell.org> References: <046.d99bd58e6ad83ef24f9a7879b45c43ac@haskell.org> Message-ID: <061.312ec90c69ad998c5c9dde20f5dc8001@haskell.org> #15164: Slowdown in ghc compile times from GHC 8.0.2 to GHC 8.2.1 when doing Called arity analysis -------------------------------------+------------------------------------- Reporter: flip101 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: nomeata (added) Comment: Adding Joachim, who wrote Called Arity Analysis. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 18 15:08:24 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 May 2018 15:08:24 -0000 Subject: [GHC] #15164: Slowdown in ghc compile times from GHC 8.0.2 to GHC 8.2.1 when doing Called arity analysis In-Reply-To: <046.d99bd58e6ad83ef24f9a7879b45c43ac@haskell.org> References: <046.d99bd58e6ad83ef24f9a7879b45c43ac@haskell.org> Message-ID: <061.2fe11849527be116c8d8d33adf7db901@haskell.org> #15164: Slowdown in ghc compile times from GHC 8.0.2 to GHC 8.2.1 when doing Called arity analysis -------------------------------------+------------------------------------- Reporter: flip101 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Thanks for the report. @flip101, are you able to test this with GHC-8.4, and see if the bug is still there? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 18 15:10:03 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 May 2018 15:10:03 -0000 Subject: [GHC] #11513: Work out when GADT parameters should be specified In-Reply-To: <047.8e435f63c64a501e9ed45a384456290b@haskell.org> References: <047.8e435f63c64a501e9ed45a384456290b@haskell.org> Message-ID: <062.3b25b99d61a59e3f7e75effa1f029cba@haskell.org> #11513: Work out when GADT parameters should be specified -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11721 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => fixed * related: => #11721 Comment: This has been subsumed by #11721. After that was fixed, GHC now specifies and orders type variables in a GADT type signature according to the usual conventions of `TypeApplications` (possibly creating wrappers where needed, as noted in comment:4). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 18 15:24:45 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 May 2018 15:24:45 -0000 Subject: [GHC] #11515: PartialTypeSignatures suggests a redundant constraint with constraint families In-Reply-To: <047.1f61d9fe36ba0e37f6daf92299bc70f1@haskell.org> References: <047.1f61d9fe36ba0e37f6daf92299bc70f1@haskell.org> Message-ID: <062.9efeaaa2ad89c150d50630138f43a570@haskell.org> #11515: PartialTypeSignatures suggests a redundant constraint with constraint families -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): This appears to be fixed, as of GHC 8.2.2: {{{ $ /opt/ghc/8.2.2/bin/ghci Bug.hs GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:7:20: error: • Found type wildcard ‘_’ standing for ‘()’ To use the inferred type, enable PartialTypeSignatures • In the type signature: foo :: (ShowSyn a, _) => a -> String | 7 | foo :: (ShowSyn a, _) => a -> String | ^ }}} I'll add a regression test. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 18 15:27:17 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 May 2018 15:27:17 -0000 Subject: [GHC] #12563: Bad error message around lack of impredicativity In-Reply-To: <047.189413f523240243492187f38831ca8b@haskell.org> References: <047.189413f523240243492187f38831ca8b@haskell.org> Message-ID: <062.ba4394a6ac4ebb66c96b9fae00a902e6@haskell.org> #12563: Bad error message around lack of impredicativity -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): This appears to be fixed, as of GHC 8.2.2: {{{ $ /opt/ghc/8.2.2/bin/ghci Bug.hs -XRankNTypes GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:4:15: error: • Cannot instantiate unification variable ‘p0’ with a type involving foralls: (forall a. f0 a) -> f0 r0 GHC doesn't yet support impredicative polymorphism • In the first argument of ‘foo’, namely ‘g’ In the expression: foo g In the expression: \ g -> foo g • Relevant bindings include g :: p0 (bound at Bug.hs:4:6) x :: p0 -> f0 r0 (bound at Bug.hs:4:1) | 4 | x = \g -> foo g | ^ }}} I'll add a regression test. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 18 15:29:21 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 May 2018 15:29:21 -0000 Subject: [GHC] #11515: PartialTypeSignatures suggests a redundant constraint with constraint families In-Reply-To: <047.1f61d9fe36ba0e37f6daf92299bc70f1@haskell.org> References: <047.1f61d9fe36ba0e37f6daf92299bc70f1@haskell.org> Message-ID: <062.ebb1229999361a7a475f60f05daecb0d@haskell.org> #11515: PartialTypeSignatures suggests a redundant constraint with constraint families -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > I'll add a regression test. Thank you! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 18 15:30:29 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 May 2018 15:30:29 -0000 Subject: [GHC] #15164: Slowdown in ghc compile times from GHC 8.0.2 to GHC 8.2.1 when doing Called arity analysis In-Reply-To: <046.d99bd58e6ad83ef24f9a7879b45c43ac@haskell.org> References: <046.d99bd58e6ad83ef24f9a7879b45c43ac@haskell.org> Message-ID: <061.39c06d5dfeb4e05317aa85bb87e44eac@haskell.org> #15164: Slowdown in ghc compile times from GHC 8.0.2 to GHC 8.2.1 when doing Called arity analysis -------------------------------------+------------------------------------- Reporter: flip101 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * cc: sgraf (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 18 15:39:47 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 May 2018 15:39:47 -0000 Subject: [GHC] #15164: Slowdown in ghc compile times from GHC 8.0.2 to GHC 8.2.1 when doing Called arity analysis In-Reply-To: <046.d99bd58e6ad83ef24f9a7879b45c43ac@haskell.org> References: <046.d99bd58e6ad83ef24f9a7879b45c43ac@haskell.org> Message-ID: <061.7daab99fafe8a7edc4573515444835ce@haskell.org> #15164: Slowdown in ghc compile times from GHC 8.0.2 to GHC 8.2.1 when doing Called arity analysis -------------------------------------+------------------------------------- Reporter: flip101 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Which module in particular is showing the slow down? Does the problem go away if you `derive` less classes (in particular, `Data`)? (Unlikely, your data types are not big, but still worth checking.) Does the problem go away with `-fno-call-arity`? (Using this flag might be a suitable work-around for you to continue with your actual program.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 18 15:51:53 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 May 2018 15:51:53 -0000 Subject: [GHC] #11515: PartialTypeSignatures suggests a redundant constraint with constraint families In-Reply-To: <047.1f61d9fe36ba0e37f6daf92299bc70f1@haskell.org> References: <047.1f61d9fe36ba0e37f6daf92299bc70f1@haskell.org> Message-ID: <062.e85527dc53eb11fa5c59828649214a74@haskell.org> #11515: PartialTypeSignatures suggests a redundant constraint with constraint families -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"819b9cfd21a1773091cec4e34716a0fd7c7d05c6/ghc" 819b9cfd/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="819b9cfd21a1773091cec4e34716a0fd7c7d05c6" Add regression tests for #11515 and #12563 Happily, both of these issues appear to have been fixed in GHC 8.2. Let's add regression tests for them to ensure that they stay fixed. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 18 15:51:53 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 May 2018 15:51:53 -0000 Subject: [GHC] #12563: Bad error message around lack of impredicativity In-Reply-To: <047.189413f523240243492187f38831ca8b@haskell.org> References: <047.189413f523240243492187f38831ca8b@haskell.org> Message-ID: <062.5d2716497aa59322e85ff373e785c43c@haskell.org> #12563: Bad error message around lack of impredicativity -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"819b9cfd21a1773091cec4e34716a0fd7c7d05c6/ghc" 819b9cfd/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="819b9cfd21a1773091cec4e34716a0fd7c7d05c6" Add regression tests for #11515 and #12563 Happily, both of these issues appear to have been fixed in GHC 8.2. Let's add regression tests for them to ensure that they stay fixed. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 18 15:53:28 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 May 2018 15:53:28 -0000 Subject: [GHC] #12563: Bad error message around lack of impredicativity In-Reply-To: <047.189413f523240243492187f38831ca8b@haskell.org> References: <047.189413f523240243492187f38831ca8b@haskell.org> Message-ID: <062.0ff5439a3738f5ed55017e85f7207782@haskell.org> #12563: Bad error message around lack of impredicativity -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T12563 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => typecheck/should_fail/T12563 * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 18 15:54:44 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 May 2018 15:54:44 -0000 Subject: [GHC] #11515: PartialTypeSignatures suggests a redundant constraint with constraint families In-Reply-To: <047.1f61d9fe36ba0e37f6daf92299bc70f1@haskell.org> References: <047.1f61d9fe36ba0e37f6daf92299bc70f1@haskell.org> Message-ID: <062.11625d8cb852cb2f3d1034affd42ca96@haskell.org> #11515: PartialTypeSignatures suggests a redundant constraint with constraint families -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: partial- | sigs/should_fail/T11515 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => partial-sigs/should_fail/T11515 * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 18 16:09:19 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 May 2018 16:09:19 -0000 Subject: [GHC] #15164: Slowdown in ghc compile times from GHC 8.0.2 to GHC 8.2.1 when doing Called arity analysis In-Reply-To: <046.d99bd58e6ad83ef24f9a7879b45c43ac@haskell.org> References: <046.d99bd58e6ad83ef24f9a7879b45c43ac@haskell.org> Message-ID: <061.c1cc4823452fb7cb0ae2f80d7b2ae533@haskell.org> #15164: Slowdown in ghc compile times from GHC 8.0.2 to GHC 8.2.1 when doing Called arity analysis -------------------------------------+------------------------------------- Reporter: flip101 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): I can confirm that - this happens for 8.2.* in module `Level4` - that `-fno-call-arity` fixes this - removing all `Data` derivings doesn't seem to have any (measurable) effect -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 18 16:16:31 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 May 2018 16:16:31 -0000 Subject: [GHC] #15009: Float equalities past local equalities In-Reply-To: <047.0a49c3ac676b2b3bc6f93c4594762c08@haskell.org> References: <047.0a49c3ac676b2b3bc6f93c4594762c08@haskell.org> Message-ID: <062.32805a1f615a337cf08af1f8c9f8f0d8@haskell.org> #15009: Float equalities past local equalities -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.3 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"2bbdd00c6d70bdc31ff78e2a42b26159c8717856/ghc" 2bbdd00/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2bbdd00c6d70bdc31ff78e2a42b26159c8717856" Orient TyVar/TyVar equalities with deepest on the left Trac #15009 showed that, for Given TyVar/TyVar equalities, we really want to orient them with the deepest-bound skolem on the left. As it happens, we also want to do the same for Wanteds, but for a different reason (more likely to be touchable). Either way, deepest wins: see TcUnify Note [Deeper level on the left]. This observation led me to some significant changes: * A SkolemTv already had a TcLevel, but the level wasn't really being used. Now it is! * I updated added invariant (SkolInf) to TcType Note [TcLevel and untouchable type variables], documenting that the level number of all the ic_skols should be the same as the ic_tclvl of the implication * FlatSkolTvs and FlatMetaTvs previously had a dummy level-number of zero, which messed the scheme up. Now they get a level number the same way as all other TcTyVars, instead of being a special case. * To make sure that FlatSkolTvs and FlatMetaTvs are untouchable (which was previously done via their magic zero level) isTouchableMetaTyVar just tests for those two cases. * TcUnify.swapOverTyVars is the crucial orientation function; see the new Note [TyVar/TyVar orientation]. I completely rewrote this function, and it's now much much easier to understand. I ended up doing some related refactoring, of course * I noticed that tcImplicitTKBndrsX and tcExplicitTKBndrsX were doing a lot of useless work in the case where there are no skolems; I added a fast-patch * Elminate the un-used tcExplicitTKBndrsSig; and thereby get rid of the higher-order parameter to tcExpliciTKBndrsX. * Replace TcHsType.emitTvImplication with TcUnify.checkTvConstraints, by analogy with TcUnify.checkConstraints. * Inline TcUnify.buildImplication into its only call-site in TcUnify.checkConstraints * TcS.buildImplication becomes TcS.CheckConstraintsTcS, with a simpler API * Now that we have NoEvBindsVar we have no need of termEvidenceAllowed; nuke the latter, adding Note [No evidence bindings] to TcEvidence. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 18 16:19:21 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 May 2018 16:19:21 -0000 Subject: [GHC] #15144: Type inference regression between GHC 8.0.2 and 8.2.2 In-Reply-To: <050.be8ee3d4bba9d11a883dc98882f5b18d@haskell.org> References: <050.be8ee3d4bba9d11a883dc98882f5b18d@haskell.org> Message-ID: <065.fe1cf5635c22347eaf9589d0ca177890@haskell.org> #15144: Type inference regression between GHC 8.0.2 and 8.2.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"ae292c6d1362f34117be75a2553049cec7022244/ghc" ae292c6d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ae292c6d1362f34117be75a2553049cec7022244" Do not unify representational equalities This patch is an easy fix to Trac #15144, which was caused by accidentally unifying a representational equality in the unflattener. (The main code in TcInteract was always careful not to do so, but I'd missed the test in the unflattener.) See Note [Do not unify representational equalities] in TcInteract }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 18 16:42:44 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 May 2018 16:42:44 -0000 Subject: [GHC] #15164: Slowdown in ghc compile times from GHC 8.0.2 to GHC 8.2.1 when doing Called arity analysis In-Reply-To: <046.d99bd58e6ad83ef24f9a7879b45c43ac@haskell.org> References: <046.d99bd58e6ad83ef24f9a7879b45c43ac@haskell.org> Message-ID: <061.23832c253251aee24657dd421d0c591f@haskell.org> #15164: Slowdown in ghc compile times from GHC 8.0.2 to GHC 8.2.1 when doing Called arity analysis -------------------------------------+------------------------------------- Reporter: flip101 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): The `-ddump-simpl-iterations` of Level4 in 8.4.2 has 89,000 terms and contains one gigantic top-level recursive binding. The output for 8.0.2 has 3,055 terms and more, manageable recursive top-level bindigns. That's huge. There's already a huge difference in compile-time for 8.4.2 with `-fno- call-arity` vs. 8.0.2 proper (>60s vs. 3s). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 18 16:49:43 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 May 2018 16:49:43 -0000 Subject: [GHC] #15164: Slowdown in ghc compile times from GHC 8.0.2 to GHC 8.2.1 when doing Called arity analysis In-Reply-To: <046.d99bd58e6ad83ef24f9a7879b45c43ac@haskell.org> References: <046.d99bd58e6ad83ef24f9a7879b45c43ac@haskell.org> Message-ID: <061.eff0781f641a3c6fa664fd832706f3d7@haskell.org> #15164: Slowdown in ghc compile times from GHC 8.0.2 to GHC 8.2.1 when doing Called arity analysis -------------------------------------+------------------------------------- Reporter: flip101 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by flip101): Thank you for your input sgraf (i think it answers all questions by nomeata). Yes the slowdown was in module Level4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 18 17:43:09 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 May 2018 17:43:09 -0000 Subject: [GHC] #15164: Slowdown in ghc compile times from GHC 8.0.2 to GHC 8.2.1 when doing Called arity analysis In-Reply-To: <046.d99bd58e6ad83ef24f9a7879b45c43ac@haskell.org> References: <046.d99bd58e6ad83ef24f9a7879b45c43ac@haskell.org> Message-ID: <061.7e23325ebf974d6d524255681b1238cb@haskell.org> #15164: Slowdown in ghc compile times from GHC 8.0.2 to GHC 8.2.1 when doing Called arity analysis -------------------------------------+------------------------------------- Reporter: flip101 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Call Arity does a fixed-point iteration for mutual recursive groups; if there is one giant, then I am not surprised to see that it explodes there. We could detect absurdly large groups and do some conservative approximation. But as Sebastian finds, there is *another*, independent regression that inflates the Core and compilation time (and blows it up in a way that completely chokes Call Arity)… -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 18 18:31:16 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 May 2018 18:31:16 -0000 Subject: [GHC] #15009: Float equalities past local equalities In-Reply-To: <047.0a49c3ac676b2b3bc6f93c4594762c08@haskell.org> References: <047.0a49c3ac676b2b3bc6f93c4594762c08@haskell.org> Message-ID: <062.b11b13455ba7e40f75ac0b8efa542a5c@haskell.org> #15009: Float equalities past local equalities -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.3 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Nice! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 18 19:06:09 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 May 2018 19:06:09 -0000 Subject: [GHC] #15009: Float equalities past local equalities In-Reply-To: <047.0a49c3ac676b2b3bc6f93c4594762c08@haskell.org> References: <047.0a49c3ac676b2b3bc6f93c4594762c08@haskell.org> Message-ID: <062.c3cd8a9b2ed90488892c0fc1dd284507@haskell.org> #15009: Float equalities past local equalities -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.4.3 Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: gadt/T15009 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => gadt/T15009 * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 18 19:07:18 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 May 2018 19:07:18 -0000 Subject: [GHC] #15144: Type inference regression between GHC 8.0.2 and 8.2.2 In-Reply-To: <050.be8ee3d4bba9d11a883dc98882f5b18d@haskell.org> References: <050.be8ee3d4bba9d11a883dc98882f5b18d@haskell.org> Message-ID: <065.2ccd341ebe6882a0ac77df9bc353db0b@haskell.org> #15144: Type inference regression between GHC 8.0.2 and 8.2.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: fixed | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_compile/T15144 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => indexed-types/should_compile/T15144 * status: new => closed * resolution: => fixed Comment: Great report, thank you! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 18 19:08:55 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 May 2018 19:08:55 -0000 Subject: [GHC] #15164: Slowdown in ghc compile times from GHC 8.0.2 to GHC 8.2.1 when doing Called arity analysis In-Reply-To: <046.d99bd58e6ad83ef24f9a7879b45c43ac@haskell.org> References: <046.d99bd58e6ad83ef24f9a7879b45c43ac@haskell.org> Message-ID: <061.e03057218bdd4db2a3c7786ee2a00891@haskell.org> #15164: Slowdown in ghc compile times from GHC 8.0.2 to GHC 8.2.1 when doing Called arity analysis -------------------------------------+------------------------------------- Reporter: flip101 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > But as Sebastian finds, there is *another*, independent regression that inflates the Core Yes, please let's characterise this aspect. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 18 19:15:11 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 May 2018 19:15:11 -0000 Subject: [GHC] #9539: TQueue can lead to thread starvation In-Reply-To: <045.f4dc0af39dea75bc36dee0474a4ea69f@haskell.org> References: <045.f4dc0af39dea75bc36dee0474a4ea69f@haskell.org> Message-ID: <060.4d468316797ec872a875f72b4bccaf0e@haskell.org> #9539: TQueue can lead to thread starvation -------------------------------------+------------------------------------- Reporter: jwlato | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.2 Resolution: fixed | Keywords: stm Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * status: patch => closed * resolution: => fixed Comment: Looks like this was applied. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 18 19:53:31 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 May 2018 19:53:31 -0000 Subject: [GHC] #15165: GHC 8.2.2: internal error with +RTS -hb Message-ID: <043.05bd633e0b8fc1db67420a68577349a9@haskell.org> #15165: GHC 8.2.2: internal error with +RTS -hb --------------------------------------+---------------------------------- Reporter: kfiz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------------- Hi, I'm trying to generate a heap profile via "+RTS -hb" on macOS 10.13.4. Unfortunately I get the following error: `internal error: Invalid object in processHeapClosureForDead(): 7`\\ `(GHC version 8.2.2 for x86_64_apple_darwin)`\\ `Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug`\\ `Abort trap: 6` Best regards Doro -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 18 20:13:14 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 May 2018 20:13:14 -0000 Subject: [GHC] #11084: Some type families don't reduce with :kind! In-Reply-To: <047.af59c4538fa4f004723d249cfac399d5@haskell.org> References: <047.af59c4538fa4f004723d249cfac399d5@haskell.org> Message-ID: <062.39c11cc195c8fd91148822167f6552f5@haskell.org> #11084: Some type families don't reduce with :kind! -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I've managed to shrink it down to two modules, but unfortunately, I don't know how to trigger the issue without the use of `cabal-install`. I've put this minimal example at https://github.com/RyanGlScott/ghc-t11084, so you can reproduce the issue like so: {{{ $ git clone https://github.com/RyanGlScott/ghc-t11084 $ cd ghc-t11084/ $ cabal install $ ghci -XDataKinds GHCi, version 8.4.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> import T11084 λ> :kind! Lookup 'True '[ '(True, True) ] Lookup 'True '[ '(True, True) ] :: Maybe Bool = T11084.Case 'True 'True 'True '[] ('True ghc-t11084-0.1:PEq.== 'True) λ> :kind! Lookup 'True '[ '(True, True) ] Lookup 'True '[ '(True, True) ] :: Maybe Bool = 'Just 'True }}} Here are the two modules in question: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} module PEq where type family (x :: a) == (y :: a) :: Bool type instance a == b = EqBool a b type family EqBool (a :: Bool) (b :: Bool) :: Bool where EqBool 'False 'False = 'True EqBool 'True 'True = 'True EqBool _ _ = 'False }}} {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE UndecidableInstances #-} module T11084 (Lookup) where import PEq type family Case key x y xys t where Case key x y xys 'True = 'Just y Case key x y xys 'False = Lookup key xys type family Lookup (n :: a) (hs :: [(a, b)]) :: Maybe b where Lookup _key '[] = 'Nothing Lookup key ('(x, y) : xys) = Case key x y xys (key == x) }}} Some notes: 1. Having `(==)` and `EqBool` defined in a separate module from `Lookup` appears to be important. If you define them all in the same module, the bug no longer occurs. 2. Moreover, replacing `(key == x)` with `EqBool key x` in the definition of `Lookup` also makes the bug go away. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 18 21:28:48 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 May 2018 21:28:48 -0000 Subject: [GHC] #15165: GHC 8.2.2: internal error with +RTS -hb In-Reply-To: <043.05bd633e0b8fc1db67420a68577349a9@haskell.org> References: <043.05bd633e0b8fc1db67420a68577349a9@haskell.org> Message-ID: <058.10c4f7bea9ddcabc2e7926caa688ac5a@haskell.org> #15165: GHC 8.2.2: internal error with +RTS -hb -----------------------------------+-------------------------------------- Reporter: kfiz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Profiling | Version: 8.2.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15063, #15087 | Differential Rev(s): Wiki Page: | -----------------------------------+-------------------------------------- Changes (by RyanGlScott): * component: Compiler => Profiling * related: => #15063, #15087 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 18 21:29:07 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 May 2018 21:29:07 -0000 Subject: [GHC] #15087: Internal Error with Bibliography Profiling In-Reply-To: <047.4e3533cfbf44e6814004409e34e96335@haskell.org> References: <047.4e3533cfbf44e6814004409e34e96335@haskell.org> Message-ID: <062.3f8550d34a466869e624d77b287ac7ea@haskell.org> #15087: Internal Error with Bibliography Profiling -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15063, #15165 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #15063 => #15063, #15165 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 18 21:29:22 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 May 2018 21:29:22 -0000 Subject: [GHC] #15063: T3001-2 fails on i386 Linux In-Reply-To: <046.fa478fb40ce13bbb24172a958e864762@haskell.org> References: <046.fa478fb40ce13bbb24172a958e864762@haskell.org> Message-ID: <061.7a58bdb566cc965644c178f413285071@haskell.org> #15063: T3001-2 fails on i386 Linux -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Profiling | Version: 8.2.2 Resolution: | Keywords: ci-breakage Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15087, #15165 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #15087 => #15087, #15165 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 19 02:28:07 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 May 2018 02:28:07 -0000 Subject: [GHC] #15166: Bad error message when `!` is used without BangPatterns extension Message-ID: <049.d2b892eabdc208b9890d4088ee5eab88@haskell.org> #15166: Bad error message when `!` is used without BangPatterns extension -------------------------------------+------------------------------------- Reporter: sighingnow | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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: -------------------------------------+------------------------------------- For {{{#!hs f :: a -> a f !x = x }}} ghc-HEAD gives {{{ P.hs:22:1: error: The type signature for ‘f’ lacks an accompanying binding | 22 | f :: a -> a | ^ }}} Here ghc should suggest `BangPatterns` extension. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 19 05:12:20 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 May 2018 05:12:20 -0000 Subject: [GHC] #15063: T3001-2 fails on i386 Linux In-Reply-To: <046.fa478fb40ce13bbb24172a958e864762@haskell.org> References: <046.fa478fb40ce13bbb24172a958e864762@haskell.org> Message-ID: <061.f03d033834af002425a4416cf88f4c8d@haskell.org> #15063: T3001-2 fails on i386 Linux -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Profiling | Version: 8.2.2 Resolution: | Keywords: ci-breakage Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15087, #15165, | Differential Rev(s): #7836 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * related: #15087, #15165 => #15087, #15165, #7836 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 19 05:12:50 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 May 2018 05:12:50 -0000 Subject: [GHC] #15165: GHC 8.2.2: internal error with +RTS -hb In-Reply-To: <043.05bd633e0b8fc1db67420a68577349a9@haskell.org> References: <043.05bd633e0b8fc1db67420a68577349a9@haskell.org> Message-ID: <058.2f4a53d33ba56a4a4ab936352a5dec65@haskell.org> #15165: GHC 8.2.2: internal error with +RTS -hb -------------------------------------+------------------------------------- Reporter: kfiz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Profiling | Version: 8.2.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15063, #15087, | Differential Rev(s): #7836 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * related: #15063, #15087 => #15063, #15087, #7836 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 19 05:13:39 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 May 2018 05:13:39 -0000 Subject: [GHC] #7836: "Invalid object in processHeapClosureForDead" when profiling with -hb In-Reply-To: <049.ee161e70aa71dbd4af4a0de9bc8eb38f@haskell.org> References: <049.ee161e70aa71dbd4af4a0de9bc8eb38f@haskell.org> Message-ID: <064.c50b6c7091ba6969004f35ab541802f3@haskell.org> #7836: "Invalid object in processHeapClosureForDead" when profiling with -hb -------------------------------------+------------------------------------- Reporter: hyperthunk | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Profiling | Version: 8.5 Resolution: | Keywords: profiling Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #9640 | Differential Rev(s): Phab:D4567 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Trac didn't notice that this was reverted. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 19 05:13:55 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 May 2018 05:13:55 -0000 Subject: [GHC] #15087: Internal Error with Bibliography Profiling In-Reply-To: <047.4e3533cfbf44e6814004409e34e96335@haskell.org> References: <047.4e3533cfbf44e6814004409e34e96335@haskell.org> Message-ID: <062.b3521ed5a8ffc9d5dcdc3c4d5301229a@haskell.org> #15087: Internal Error with Bibliography Profiling -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15063, #15165, | Differential Rev(s): #7836 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * related: #15063, #15165 => #15063, #15165, #7836 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 19 05:16:50 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 May 2018 05:16:50 -0000 Subject: [GHC] #7836: "Invalid object in processHeapClosureForDead" when profiling with -hb In-Reply-To: <049.ee161e70aa71dbd4af4a0de9bc8eb38f@haskell.org> References: <049.ee161e70aa71dbd4af4a0de9bc8eb38f@haskell.org> Message-ID: <064.ba04dda81eab5a7653cf75d66a6ed689@haskell.org> #7836: "Invalid object in processHeapClosureForDead" when profiling with -hb -------------------------------------+------------------------------------- Reporter: hyperthunk | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Profiling | Version: 8.5 Resolution: | Keywords: profiling Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #9640, #15063, | Differential Rev(s): Phab:D4567 #15087, #15165 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * related: #9640 => #9640, #15063, #15087, #15165 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 19 05:18:54 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 May 2018 05:18:54 -0000 Subject: [GHC] #9640: Invalid object in processHeapClosureForDead(): 2130762223 In-Reply-To: <047.4251ac36032806c0b7c6a3cfadb392fc@haskell.org> References: <047.4251ac36032806c0b7c6a3cfadb392fc@haskell.org> Message-ID: <062.387f8c1245e0af8fcbed1e9a9189e105@haskell.org> #9640: Invalid object in processHeapClosureForDead(): 2130762223 -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Profiling | Version: 7.8.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * related: #7836 => Comment: This is probably not a duplicate of #7836. #7836 is about an unhandled case in `processHeapClosureForDead`, but this ticket is about a memory corruption. Still let's keep this closed as it's probably impossible to reproduce now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 19 05:19:05 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 May 2018 05:19:05 -0000 Subject: [GHC] #7836: "Invalid object in processHeapClosureForDead" when profiling with -hb In-Reply-To: <049.ee161e70aa71dbd4af4a0de9bc8eb38f@haskell.org> References: <049.ee161e70aa71dbd4af4a0de9bc8eb38f@haskell.org> Message-ID: <064.c71f8eb6fc4df968db35e07ae217110f@haskell.org> #7836: "Invalid object in processHeapClosureForDead" when profiling with -hb -------------------------------------+------------------------------------- Reporter: hyperthunk | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Profiling | Version: 8.5 Resolution: | Keywords: profiling Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15063, #15087, | Differential Rev(s): Phab:D4567 #15165 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * related: #9640, #15063, #15087, #15165 => #15063, #15087, #15165 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 19 10:11:12 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 May 2018 10:11:12 -0000 Subject: [GHC] #15146: Documentation: ScopedTypeVariables feature not mentioned/misleadingly described In-Reply-To: <043.d95bdea9ee71d4ecb11e1c8b5424eb30@haskell.org> References: <043.d95bdea9ee71d4ecb11e1c8b5424eb30@haskell.org> Message-ID: <058.fd0ac5cbbf9126dec729b3be721a9513@haskell.org> #15146: Documentation: ScopedTypeVariables feature not mentioned/misleadingly described -------------------------------------+------------------------------------- Reporter: AntC | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Documentation | Version: 8.2.2 Resolution: | Keywords: newcomer, | ScopedTypeVariables Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): Replying to [comment:1 bgamari]: > It would be great if someone could offer a patch for this. (Thanks Ben for your help in piloting me through the process.) Please see [https://github.com/ghc/ghc/pull/137 this Pull Request]. Hope I've done everything right. It was a bit daunting editting the whole of `glasgow_exts` as one monstrous file. I have (I hope) touched only section 10.16. > Misleading documentation is in many ways worse than no documentation. I've at least corrected the most egregious errors. I also reviewed refs/links to ScopedTypeVariables from other sections. (Some of them were more accurate than 10.16 itself ;-) No other changes needed on this topic IMO. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 19 16:45:26 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 May 2018 16:45:26 -0000 Subject: [GHC] #15088: Test T3234 is fragile In-Reply-To: <049.b4734c814119c3f6b3a53330ff37ca44@haskell.org> References: <049.b4734c814119c3f6b3a53330ff37ca44@haskell.org> Message-ID: <064.80fe33b45379fef2a93448ab362e2c77@haskell.org> #15088: Test T3234 is fragile -------------------------------------+------------------------------------- Reporter: mpickering | Owner: RolandSenn Type: task | Status: patch Priority: lowest | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T3234 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * testcase: => T3234 * status: new => patch Comment: To fix this issue,I sent a [https://github.com/ghc/ghc/pull/138 pull- request] to the Github repository. As mentioned in the original ticket #3234, the issue was that the rule `fold/build` no longer fired. Hence it's sufficient to check only on the availability of this rule in the output. A more sophisticated test could check on: {{{ 5 RuleFired 1 ++ 1 augment/build 1 foldr/single 1 unpack 1 unpack-list }}} However this would nedd the grep alternative `grep 'foo\|bar` which is part of ''extended'' grep. Please feel free to request any needed changes to this PR. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 19 19:44:50 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 May 2018 19:44:50 -0000 Subject: [GHC] #15164: Slowdown in ghc compile times from GHC 8.0.2 to GHC 8.2.1 when doing Called arity analysis In-Reply-To: <046.d99bd58e6ad83ef24f9a7879b45c43ac@haskell.org> References: <046.d99bd58e6ad83ef24f9a7879b45c43ac@haskell.org> Message-ID: <061.725ef51bc404919e7fbd9851d4690aa4@haskell.org> #15164: Slowdown in ghc compile times from GHC 8.0.2 to GHC 8.2.1 when doing Called arity analysis -------------------------------------+------------------------------------- Reporter: flip101 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by nomeata: Old description: > Hello, > > I have this program that compiles against packages of stack LTS-9.21. > When i compile with GHC 8.0.2 (version of LTS-9.21) the compiling is > fast. > > 72.01user 34.61system 0:52.98elapsed 201%CPU (0avgtext+0avgdata > 600684maxresident)k > > When i upgrade to LTS-11.9 compiling gets slow. To test if it was a > problem with new package or GHC (ghc gives some new packages too) i ran: > > /usr/bin/time stack build --compiler ghc-8.2.1 --ghc-options="-v3 -j4 -O2 > -fexcess-precision -optc-O3 -optc-ffast-math -rtsopts=none -no-rtsopts- > suggestions" > > with the old package of LTS-9.21 but with the newer GHC 8.2.1 compiler. > Now the compile times are much higher: > > 2481.26user 663.66system 35:38.82elapsed 147%CPU (0avgtext+0avgdata > 674732maxresident)k > > I already took out parts of the grammar to get it even to compile. When i > have the full grammar i can let my laptop compile 24 hours and it's still > busy. > > I was not sure how to further reduce the code. Maybe when a lot of effort > i can cut out a few lines here and there. So i uploaded the entire > project here https://github.com/flip111/parser-calledarityanalysis i > already took out a lot of code. If anyone has suggestions on how to > further reduce the code i can try. > > Because i had debug info on (-v3 flag) i saw it was stuck for a long time > at "Called arity analysis" > > I prioritize this bug high because i think the slowdown is very > problematic. New description: Hello, I have this program that compiles against packages of stack LTS-9.21. When i compile with GHC 8.0.2 (version of LTS-9.21) the compiling is fast. {{{ 72.01user 34.61system 0:52.98elapsed 201%CPU (0avgtext+0avgdata 600684maxresident)k }}} When i upgrade to LTS-11.9 compiling gets slow. To test if it was a problem with new package or GHC (ghc gives some new packages too) i ran: {{{ /usr/bin/time stack build --compiler ghc-8.2.1 --ghc-options="-v3 -j4 -O2 -fexcess-precision -optc-O3 -optc-ffast-math -rtsopts=none -no-rtsopts- suggestions" }}} with the old package of LTS-9.21 but with the newer GHC 8.2.1 compiler. Now the compile times are much higher: {{{ 2481.26user 663.66system 35:38.82elapsed 147%CPU (0avgtext+0avgdata 674732maxresident)k }}} I already took out parts of the grammar to get it even to compile. When i have the full grammar i can let my laptop compile 24 hours and it's still busy. I was not sure how to further reduce the code. Maybe when a lot of effort i can cut out a few lines here and there. So i uploaded the entire project here https://github.com/flip111/parser-calledarityanalysis i already took out a lot of code. If anyone has suggestions on how to further reduce the code i can try. Because i had debug info on (-v3 flag) i saw it was stuck for a long time at "Called arity analysis" I prioritize this bug high because i think the slowdown is very problematic. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 19 20:14:46 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 May 2018 20:14:46 -0000 Subject: [GHC] #15164: Slowdown in ghc compile times from GHC 8.0.2 to GHC 8.2.1 when doing Called arity analysis In-Reply-To: <046.d99bd58e6ad83ef24f9a7879b45c43ac@haskell.org> References: <046.d99bd58e6ad83ef24f9a7879b45c43ac@haskell.org> Message-ID: <061.c10a4efad2c8d6023821959568e7ea98@haskell.org> #15164: Slowdown in ghc compile times from GHC 8.0.2 to GHC 8.2.1 when doing Called arity analysis -------------------------------------+------------------------------------- Reporter: flip101 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): I have minimized the test to a self-contained file without package dependencies. More minimization might be possible, but not right now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 19 20:17:31 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 May 2018 20:17:31 -0000 Subject: [GHC] #15164: Slowdown in ghc compile times from GHC 8.0.2 to GHC 8.2.1 when doing Called arity analysis In-Reply-To: <046.d99bd58e6ad83ef24f9a7879b45c43ac@haskell.org> References: <046.d99bd58e6ad83ef24f9a7879b45c43ac@haskell.org> Message-ID: <061.beb76762fa1a67b39175084cbac3a450@haskell.org> #15164: Slowdown in ghc compile times from GHC 8.0.2 to GHC 8.2.1 when doing Called arity analysis -------------------------------------+------------------------------------- Reporter: flip101 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Uploading to trac seems to fail; I put the minimized file at https://github.com/nomeata/parser-calledarityanalysis -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 19 20:23:42 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 May 2018 20:23:42 -0000 Subject: [GHC] #15164: Slowdown in ghc compile times from GHC 8.0.2 to GHC 8.2.1 when doing Called arity analysis In-Reply-To: <046.d99bd58e6ad83ef24f9a7879b45c43ac@haskell.org> References: <046.d99bd58e6ad83ef24f9a7879b45c43ac@haskell.org> Message-ID: <061.f8900162bc3373708adea8c8f98bf5c0@haskell.org> #15164: Slowdown in ghc compile times from GHC 8.0.2 to GHC 8.2.1 when doing Called arity analysis -------------------------------------+------------------------------------- Reporter: flip101 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): We already go from {{{ ==================== Desugar (after optimization) ==================== Result size of Desugar (after optimization) = {terms: 3,189, types: 4,403, coercions: 132} }}} to {{{ ==================== Desugar (after optimization) ==================== Result size of Desugar (after optimization) = {terms: 82,881, types: 86,775, coercions: 132, joins: 0/20,633} }}} Maybe the use of `UndecidableInstances` is the problem here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 19 21:41:17 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 May 2018 21:41:17 -0000 Subject: [GHC] #15164: Slowdown in ghc compile times from GHC 8.0.2 to GHC 8.2.1 when doing Called arity analysis In-Reply-To: <046.d99bd58e6ad83ef24f9a7879b45c43ac@haskell.org> References: <046.d99bd58e6ad83ef24f9a7879b45c43ac@haskell.org> Message-ID: <061.0564d8e4cf44de839a406ada87207c3e@haskell.org> #15164: Slowdown in ghc compile times from GHC 8.0.2 to GHC 8.2.1 when doing Called arity analysis -------------------------------------+------------------------------------- Reporter: flip101 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): If I focus on this part of the code: {{{ newtype ActualParameterPart = APP (NT AssociationList) instance Rule f AssociationList => Rule f ActualParameterPart where get = APP <$> n93 }}} then with 8.0 I get this code for the instance method: {{{ -- RHS size: {terms: 12, types: 18, coercions: 0} $cget_a1BB :: forall (f_a1By :: * -> *). (Rule f_a1By AssociationList, Decorator f_a1By) => f_a1By ActualParameterPart [LclId, Str=DmdType] $cget_a1BB = \ (@ (f_a1By :: * -> *)) ($dRule_a1Bz :: Rule f_a1By AssociationList) ($dDecorator_a1BD :: Decorator f_a1By) -> <$> @ f_a1By @ (NT AssociationList) @ ActualParameterPart (GHC.Base.$p1Applicative @ f_a1By (GHC.Base.$p1Monad @ f_a1By (Level4.$p1Decorator @ f_a1By $dDecorator_a1BD))) Level4.APP (n93 @ f_a1By $dDecorator_a1BD @ AssociationList $dRule_a1Bz) }}} but with 8.4 I get {{{ -- RHS size: {terms: 2,474, types: 2,544, coercions: 0, joins: 0/630} $cget_a2E1 [Occ=LoopBreaker] :: forall (f :: * -> *). (Rule f AssociationList, Decorator f) => f ActualParameterPart [LclId] $cget_a2E1 = \ (@ (f_a2DY :: * -> *)) _ [Occ=Dead] ($dDecorator_a2E4 :: Decorator f_a2DY) -> letrec { $dRule_a7WP :: Rule f_a2DY QualifiedExpression [LclId] $dRule_a7WP = Level4.$fRulefQualifiedExpression @ f_a2DY $dRule_a7Qw $dRule_a7Wx; $dRule_a7VU :: Rule f_a2DY FunctionCall [LclId] $dRule_a7VU = Level4.$fRulefFunctionCall @ f_a2DY $dRule_a7VQ; … thousands of lines omitted … $dRule_a7Qv [Occ=LoopBreaker] :: Rule f_a2DY Name [LclId] $dRule_a7Qv = Level4.$fRulefName @ f_a2DY $dRule_a7Ux $dRule_a7Uy $dRule_a7Uz; } in letrec { $dRule_a7Th :: Rule f_a2DY FunctionCall [LclId] $dRule_a7Th = Level4.$fRulefFunctionCall @ f_a2DY $dRule_a7Qy; … again thousands of lines omitted … $dRule_a7Qy [Occ=LoopBreaker] :: Rule f_a2DY Name [LclId] $dRule_a7Qy = Level4.$fRulefName @ f_a2DY $dRule_a7Te $dRule_a7Tf $dRule_a7Tg; } in letrec { $dRule_a7QO :: Rule f_a2DY TypeMark [LclId] $dRule_a7QO = Level4.$fRulefTypeMark @ f_a2DY $dRule_a7QB; … again … $dRule_a7Qx [Occ=LoopBreaker] :: Rule f_a2DY Expression [LclId] $dRule_a7Qx = Level4.$fRulefExpression @ f_a2DY $dRule_a7Qz; } in letrec { $dRule_a7Qo :: Rule f_a2DY QualifiedExpression [LclId] $dRule_a7Qo = Level4.$fRulefQualifiedExpression @ f_a2DY $dRule_a7ML $dRule_a7Q6; … … and a few more of those … $dRule_a7MM = Level4.$fRulefName @ f_a2DY $dRule_a7MN $dRule_a7MO $dRule_a7MP; } in <$> @ f_a2DY @ (NT AssociationList) @ ActualParameterPart (GHC.Base.$p1Applicative @ f_a2DY (GHC.Base.$p1Monad @ f_a2DY (Level4.$p1Decorator @ f_a2DY $dDecorator_a2E4))) Level4.APP (n93 @ f_a2DY $dDecorator_a2E4 @ AssociationList (Level4.$fRulefAssociationList @ f_a2DY (Level4.$fRulefAssociationElement @ f_a2DY (Level4.$fRulefFormalPart @ f_a2DY (Level4.$fRulefFormalDesignator @ f_a2DY $dRule_a7MM) $dRule_a7MK $dRule_a7ML) (Level4.$fRulefActualPart @ f_a2DY (Level4.$fRulefActualDesignator @ f_a2DY $dRule_a7Qx $dRule_a7Qy) $dRule_a7Qv $dRule_a7Qw)))) }}} The important change seems to be: * Previously, the code for `get` would use the dictionary for `Rule f_a1By AssociationList` passed to it, here named `$dRule_a1Bz`. * Now, it ''ignores'' the dictionary passed to it (note `_ [Occ=Dead]`) and instead seems to build the dictionary it passes to `n93` locally, using many very large local let-recs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 19 21:47:24 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 May 2018 21:47:24 -0000 Subject: [GHC] #15164: Slowdown in ghc compile times from GHC 8.0.2 to GHC 8.2.1 when doing Called arity analysis In-Reply-To: <046.d99bd58e6ad83ef24f9a7879b45c43ac@haskell.org> References: <046.d99bd58e6ad83ef24f9a7879b45c43ac@haskell.org> Message-ID: <061.8281b46b5707d0320c2f714f3270b514@haskell.org> #15164: Slowdown in ghc compile times from GHC 8.0.2 to GHC 8.2.1 when doing Called arity analysis -------------------------------------+------------------------------------- Reporter: flip101 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Ha, the code still compiles, and does so quickly with all versions, if I simply remove the contexts from the instance declarations, e.g. {{{ -instance (Rule f Expression, Rule f Name) => Rule f ActualDesignator where +instance Rule f ActualDesignator where }}} This also lets me remove `UndecidableInstances`. See this commit: https://github.com/nomeata/parser- calledarityanalysis/commit/cb2e23b081d1016278feaa1397ad62a1672a52cf @flip101, I understand that this is minimized code. Can you check your real code if you really need the contexts in the instance declarations, and if the problem goes away when you remove them? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 19 22:32:06 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 May 2018 22:32:06 -0000 Subject: [GHC] #15167: DerivClause list is not populated for (TyConI (DataD ...)) Message-ID: <049.1da123fe6825387f79a8e9ada4e3ab34@haskell.org> #15167: DerivClause list is not populated for (TyConI (DataD ...)) -------------------------------------+------------------------------------- Reporter: 0xd34df00d | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Template | Version: 8.4.2 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: -------------------------------------+------------------------------------- {{{#!haskell % cat Test.hs {-# LANGUAGE LambdaCase #-} module Test where import Language.Haskell.TH test :: Name -> Q [Dec] test name = reify name >>= \case TyConI dec -> do runIO $ print dec pure [] _ -> pure [] % cat Run.hs {-# LANGUAGE TemplateHaskell #-} import Test data Foo = Foo deriving (Eq, Ord, Show) test ''Foo % ghc Run.hs [2 of 2] Compiling Main ( Run.hs, Run.o ) DataD [] Main.Foo [] Nothing [NormalC Main.Foo []] [] }}} One might expect the `DataD` to mention `Eq, Ord, Show` in the `DerivClause` list, but it doesn't. This behavior manifests with every ghc version I tried: 8.0.2, 8.2.2, 8.4.2. I also asked a question whether it's intended behaviour on #haskell, and I've been advised to open a bug report, so here it is. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 19 22:36:43 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 May 2018 22:36:43 -0000 Subject: [GHC] #15164: Slowdown in ghc compile times from GHC 8.0.2 to GHC 8.2.1 when doing Called arity analysis In-Reply-To: <046.d99bd58e6ad83ef24f9a7879b45c43ac@haskell.org> References: <046.d99bd58e6ad83ef24f9a7879b45c43ac@haskell.org> Message-ID: <061.4ed51679d3fe4e051bb598398c5361de@haskell.org> #15164: Slowdown in ghc compile times from GHC 8.0.2 to GHC 8.2.1 when doing Called arity analysis -------------------------------------+------------------------------------- Reporter: flip101 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Great detective work. I see what is happening. First, a workaround is to use `-fno-solve-constant-dicts`. Second, if you don't actually need the contexts on your instances then yes, try omitting them. What's happening is this. The "short cut solver" `TcInteract.shortCutSolver` tries to solve goals using top-level evidence only (see `Note [Shortcut solving]`). But in doing so, it doesn't have enough sharing. To solve G it may need G1 and G2. To solve G1 it may need X; and to solve G2 it may need X. But it doesn't spot that it only needs to solve X once. So it does the "solve X" work (successfully) twice. Then the same thing happens when solving X. And the structure of this particular example is that we get successive doubling. Solution is simple: just be a bit more intelligent about sharing. I can do that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 20 00:54:03 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 May 2018 00:54:03 -0000 Subject: [GHC] #15166: Bad error message when `!` is used without BangPatterns extension In-Reply-To: <049.d2b892eabdc208b9890d4088ee5eab88@haskell.org> References: <049.d2b892eabdc208b9890d4088ee5eab88@haskell.org> Message-ID: <064.651727595465f02c8443ea95a1d9bd6c@haskell.org> #15166: Bad error message when `!` is used without BangPatterns extension -------------------------------------+------------------------------------- Reporter: sighingnow | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #13600 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #13600 Comment: I think this is a duplicate of #13600? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 20 01:01:12 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 May 2018 01:01:12 -0000 Subject: [GHC] #15167: DerivClause list is not populated for (TyConI (DataD ...)) In-Reply-To: <049.1da123fe6825387f79a8e9ada4e3ab34@haskell.org> References: <049.1da123fe6825387f79a8e9ada4e3ab34@haskell.org> Message-ID: <064.46edb66cc0d64b9e8873105b2775be0c@haskell.org> #15167: DerivClause list is not populated for (TyConI (DataD ...)) -------------------------------------+------------------------------------- Reporter: 0xd34df00d | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Template Haskell | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: newcomer (added) Comment: Indeed, this is expected. Reified data declarations never have derived instances attached to them, as they're only used when splicing a TH- constructed data type into source code. (If you want to know a data type's instances via TH, you should use `reifyInstances`.) The Haddocks in `template-haskell` currently don't state that reified data types lack derived instance information, however, so it would be good to update the documentation to reflect this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 20 01:24:08 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 May 2018 01:24:08 -0000 Subject: [GHC] #15164: Slowdown in ghc compile times from GHC 8.0.2 to GHC 8.2.1 when doing Called arity analysis In-Reply-To: <046.d99bd58e6ad83ef24f9a7879b45c43ac@haskell.org> References: <046.d99bd58e6ad83ef24f9a7879b45c43ac@haskell.org> Message-ID: <061.de1f591fc835a58a8b7ada5006e54de0@haskell.org> #15164: Slowdown in ghc compile times from GHC 8.0.2 to GHC 8.2.1 when doing Called arity analysis -------------------------------------+------------------------------------- Reporter: flip101 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by flip101): Hi nomeata. When i started to develop my program i got some errors that some deductions/proof could not be made. Actually i don't remember the exact term for it and the exact error message. Anyway after asking around it was clear i had to put these constraints. I left these constraints in place while further developing my code and also using other packages. Now i tried to remove them again and i don't get any errors about it and the compiler speed looks good too (minutes, not days/weeks). I still need to verify if the program does what i expect it to do, but at least it compiles fast now. I think it's a good solution for me, but still a problem for GHC, so i will leave this issue open. Good job on identifying this issue everyone. It's very nice. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 20 01:31:46 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 May 2018 01:31:46 -0000 Subject: [GHC] #15166: Bad error message when `!` is used without BangPatterns extension In-Reply-To: <049.d2b892eabdc208b9890d4088ee5eab88@haskell.org> References: <049.d2b892eabdc208b9890d4088ee5eab88@haskell.org> Message-ID: <064.71c27d0b74d563c7bc69f5bf17620c6d@haskell.org> #15166: Bad error message when `!` is used without BangPatterns extension -------------------------------------+------------------------------------- Reporter: sighingnow | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #13600 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sighingnow): * status: new => closed * resolution: => duplicate Comment: Yes, this indeed a duplicate of #13600, should be closed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 20 01:34:54 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 May 2018 01:34:54 -0000 Subject: [GHC] #13600: surprising error message with bang pattern In-Reply-To: <051.cb1136f932f929f97ddeb5e4dd8a6304@haskell.org> References: <051.cb1136f932f929f97ddeb5e4dd8a6304@haskell.org> Message-ID: <066.9a5d088b644fcb19e60672ed3cf1e4eb@haskell.org> #13600: surprising error message with bang pattern -------------------------------------+------------------------------------- Reporter: andrewufrank | Owner: sighingnow Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Poor/confusing | (amd64) error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sighingnow): * owner: (none) => sighingnow -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 20 07:30:49 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 May 2018 07:30:49 -0000 Subject: [GHC] #13600: surprising error message with bang pattern In-Reply-To: <051.cb1136f932f929f97ddeb5e4dd8a6304@haskell.org> References: <051.cb1136f932f929f97ddeb5e4dd8a6304@haskell.org> Message-ID: <066.82522040f00c85711841241313250407@haskell.org> #13600: surprising error message with bang pattern -------------------------------------+------------------------------------- Reporter: andrewufrank | Owner: sighingnow Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: BangPatterns Operating System: Linux | Architecture: x86_64 Type of failure: Poor/confusing | (amd64) error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ulysses4ever): * keywords: => BangPatterns -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 20 14:38:03 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 May 2018 14:38:03 -0000 Subject: [GHC] #8316: GHCi debugger segfaults when trying force a certain variable In-Reply-To: <044.9ebacfadd8f49d7b017849858920cbb4@haskell.org> References: <044.9ebacfadd8f49d7b017849858920cbb4@haskell.org> Message-ID: <059.9efcdc54aa30bd23965e08597da59fd4@haskell.org> #8316: GHCi debugger segfaults when trying force a certain variable -------------------------------------+------------------------------------- Reporter: guest | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: debugger Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4535 Wiki Page: | -------------------------------------+------------------------------------- Old description: > The file Test.hs has following definition: > {{{ > foo :: [Int] > foo = [1..] > }}} > > Calling ghci as: > {{{ > ghci Test.hs -ignore-dot-ghci > }}} > > and bebugging foo like this: > {{{ > *Main> :break foo > Breakpoint 0 activated at main.hs:2:7-11 > *Main> foo > Stopped in Main.foo, main.hs:2:7-11 > _result :: [Int] = _ > [main.hs:2:7-11] [main.hs:2:7-11] *Main> :print foo > foo = (_t1::[Int]) > [main.hs:2:7-11] [main.hs:2:7-11] *Main> _t1 > }}} > > results in this segault: > {{{ > : internal error: TSO object entered! > (GHC version 8.5.20180302 for x86_64_unknown_linux) > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > [1] 5445 abort (core dumped) ghci Test.hs -ignore-dot-ghci > }}} New description: The file Test.hs has following definition: {{{ foo :: [Int] foo = [1..] }}} Calling ghci as: {{{ ghci Test.hs -ignore-dot-ghci }}} and bebugging foo like this: {{{ *Main> :break foo Breakpoint 0 activated at main.hs:2:7-11 *Main> foo Stopped in Main.foo, main.hs:2:7-11 _result :: [Int] = _ [main.hs:2:7-11] *Main> :print foo foo = (_t1::[Int]) [main.hs:2:7-11] *Main> _t1 }}} results in this segault: {{{ : internal error: TSO object entered! (GHC version 8.5.20180302 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug [1] 5445 abort (core dumped) ghci Test.hs -ignore-dot-ghci }}} -- Comment (by Nolan): Bug with context printed twice was fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 20 15:11:36 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 May 2018 15:11:36 -0000 Subject: [GHC] #15168: GHC HEAD crashes on Windows 64 after the SRT overhaul (May 16, 2018 and newer) Message-ID: <044.deabc7a4c199713a6195b6ed0eaae792@haskell.org> #15168: GHC HEAD crashes on Windows 64 after the SRT overhaul (May 16, 2018 and newer) -------------------------------------+------------------------------------- Reporter: awson | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- After the series of SRT overhaul patches GHC doesn't work on Windows 64-bit. GHC executable crashes (AV) on any attempt to compile anything or even to start in interactive mode. When crashed it report crash address which may look not as a real address at all (e.g. 0x800 or 0xffffffffffffffff) and may report either reading from or executing such an address. OTOH, when started with, e.g. `+RTS -A256m -RTS` it is able to compile some programs (`haddock` at least). Reverting all related commits down to eb8e692cab7970c495681e14721d05ecadd21581 make things work again. I have no proof that things went bad exactly at eb8e692cab7970c495681e14721d05ecadd21581. Perhaps, this happened later on, but I have a proof that things were good immediately before. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 20 15:35:12 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 May 2018 15:35:12 -0000 Subject: [GHC] #15169: SRT offset optimisation breaks on MachO platforms Message-ID: <046.f2a576c45e77082d3e47dbc39c359c13@haskell.org> #15169: SRT offset optimisation breaks on MachO platforms --------------------------------------+--------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- 2b0918c9834be1873728176e4944bec26271234a reduces the overhead of SRT references by encoding them as an offset on amd64, as such references are always possible to represent in a half-word in the small memory model. Unfortunately, this appears to break on MachO platforms (e.g. Darwin) due to an object format limitation. Specifically, linking fails with: {{{ /var/folders/3y/qjvrbynj45j_z4jt_l1k1qg00000gv/T/ghc32020_0/ghc_3.s:219:8: error: error: unsupported relocation with subtraction expression, symbol '_integerzmgmp_GHCziIntegerziType_quotInteger_closure' can not be undefined in a subtraction expression .long _integerzmgmp_GHCziIntegerziType_quotInteger_closure-(_cOA_info)+0 ^ | 219 | .long _integerzmgmp_GHCziIntegerziType_quotInteger_closure-(_cOA_info)+0 | }}} [[https://llvm.org/viewvc/llvm- project?view=revision&revision=220599|Apparently]] MachO does not permit relocations' subtraction expressions to refer to undefined symbols. As far as I can tell this means that it is essentially impossible to express an offset between symbols living in different compilation units. This means that we lively can't use this optimisation on MachO platforms. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 20 15:42:14 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 May 2018 15:42:14 -0000 Subject: [GHC] #15099: Missing instances for Data.Monoid.Alt In-Reply-To: <045.026b0504cddc6774e706c3e5ef528903@haskell.org> References: <045.026b0504cddc6774e706c3e5ef528903@haskell.org> Message-ID: <060.3ca6e55ffab8d3234542e09c077e5b73@haskell.org> #15099: Missing instances for Data.Monoid.Alt -------------------------------------+------------------------------------- Reporter: ekmett | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4698 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"c617c1fb9403dc80f95c8083db9d347ce839b70f/ghc" c617c1fb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c617c1fb9403dc80f95c8083db9d347ce839b70f" base: Add Foldable and Traversable instances for Alt Add Foldable and Traversable instances for Data.Monoid.Alt Signed-off-by: Jack Henahan Reviewers: hvr, bgamari Reviewed By: bgamari Subscribers: mpickering, rwbarton, thomie, carter GHC Trac Issues: #15099 Differential Revision: https://phabricator.haskell.org/D4698 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 20 15:42:43 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 May 2018 15:42:43 -0000 Subject: [GHC] #14890: Make Linux slow validate green In-Reply-To: <046.a107a76cbb0183d36ada5ee5738b1b26@haskell.org> References: <046.a107a76cbb0183d36ada5ee5738b1b26@haskell.org> Message-ID: <061.b43ee8de4faa29034839b18d4b0c4f53@haskell.org> #14890: Make Linux slow validate green -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alpmestan Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D4546, D4636, Wiki Page: | D4712 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"c4219d9f7d122a106fc8fb1e5cd9a62dadadf76c/ghc" c4219d9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c4219d9f7d122a106fc8fb1e5cd9a62dadadf76c" Another batch of './validation --slow' tweaks This finally gets us to a green ./validate --slow on linux for a ghc checkout from the beginning of this week, see https://circleci.com/gh/ghc/ghc/4739 This is hopefully the final (or second to final) patch to address #14890. Test Plan: ./validate --slow Reviewers: bgamari, hvr, simonmar Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14890 Differential Revision: https://phabricator.haskell.org/D4712 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 20 15:42:58 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 May 2018 15:42:58 -0000 Subject: [GHC] #13857: compactAdd doesn't work with SmallArray# In-Reply-To: <049.63d32166f598a80d4ab31076e3e7e75b@haskell.org> References: <049.63d32166f598a80d4ab31076e3e7e75b@haskell.org> Message-ID: <064.507244184e6e0415cc937cfae26ab215@haskell.org> #13857: compactAdd doesn't work with SmallArray# -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.3 Component: Runtime System | Version: 8.2.1-rc2 Resolution: | Keywords: compact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3888, Wiki Page: | Phab:D4702 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"12deb9a97c05ad462ef04e8d2062c3d11c52c6ff/ghc" 12deb9a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="12deb9a97c05ad462ef04e8d2062c3d11c52c6ff" rts: Fix compaction of SmallMutArrPtrs This was blatantly wrong due to copy-paste blindness: * labels were shadowed, which GHC doesn't warn about(!), resulting in plainly wrong behavior * the sharing check was omitted * the wrong closure layout was being used Moreover, the test wasn't being run due to its primitive dependency, so I didn't even notice. Sillyness. Test Plan: install `primitive`, `make test TEST=compact_small_array` Reviewers: simonmar, erikd Reviewed By: simonmar Subscribers: rwbarton, thomie, carter GHC Trac Issues: #13857. Differential Revision: https://phabricator.haskell.org/D4702 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 20 17:02:12 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 May 2018 17:02:12 -0000 Subject: [GHC] #14873: GHC HEAD regression (piResultTy) In-Reply-To: <050.432390dbdc6a6bf0129a45fcc689c7e7@haskell.org> References: <050.432390dbdc6a6bf0129a45fcc689c7e7@haskell.org> Message-ID: <065.37454c3fe5eb090185d79700f23de8dc@haskell.org> #14873: GHC HEAD regression (piResultTy) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * milestone: => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 20 17:29:45 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 May 2018 17:29:45 -0000 Subject: [GHC] #13857: compactAdd doesn't work with SmallArray# In-Reply-To: <049.63d32166f598a80d4ab31076e3e7e75b@haskell.org> References: <049.63d32166f598a80d4ab31076e3e7e75b@haskell.org> Message-ID: <064.3ff0087783f2bdfafda0598c9257ab29@haskell.org> #13857: compactAdd doesn't work with SmallArray# -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: merge Priority: high | Milestone: 8.4.3 Component: Runtime System | Version: 8.2.1-rc2 Resolution: | Keywords: compact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3888, Wiki Page: | Phab:D4702 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 20 17:30:22 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 May 2018 17:30:22 -0000 Subject: [GHC] #15099: Missing instances for Data.Monoid.Alt In-Reply-To: <045.026b0504cddc6774e706c3e5ef528903@haskell.org> References: <045.026b0504cddc6774e706c3e5ef528903@haskell.org> Message-ID: <060.776b8035b8ec4aa28d6394d07cec55d5@haskell.org> #15099: Missing instances for Data.Monoid.Alt -------------------------------------+------------------------------------- Reporter: ekmett | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4698 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 20 18:36:11 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 May 2018 18:36:11 -0000 Subject: [GHC] #15006: User guide uses cnd.mathjax.org, which has shut down In-Reply-To: <044.949eedec228cd4e86d997cf4e57c7609@haskell.org> References: <044.949eedec228cd4e86d997cf4e57c7609@haskell.org> Message-ID: <059.cd3be65e9e35529da441c85612033372@haskell.org> #15006: User guide uses cnd.mathjax.org, which has shut down -------------------------------------+------------------------------------- Reporter: lyxia | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.3 Component: Documentation | Version: 8.4.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4603 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 20 18:36:58 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 May 2018 18:36:58 -0000 Subject: [GHC] #13857: compactAdd doesn't work with SmallArray# In-Reply-To: <049.63d32166f598a80d4ab31076e3e7e75b@haskell.org> References: <049.63d32166f598a80d4ab31076e3e7e75b@haskell.org> Message-ID: <064.73ec92f740f3ec22c7ed7e4179726ad0@haskell.org> #13857: compactAdd doesn't work with SmallArray# -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.4.3 Component: Runtime System | Version: 8.2.1-rc2 Resolution: fixed | Keywords: compact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3888, Wiki Page: | Phab:D4702 -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to 8.4.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 20 18:37:06 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 May 2018 18:37:06 -0000 Subject: [GHC] #15038: Memory Corruption (strange closure type) In-Reply-To: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> References: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> Message-ID: <064.08a2beb75241c65777158ec2aa55984b@haskell.org> #15038: Memory Corruption (strange closure type) -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.4.3 Component: Compiler | Version: 8.4.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #9718 | Differential Rev(s): Phab:D4680 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 20 18:37:40 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 May 2018 18:37:40 -0000 Subject: [GHC] #15145: Emit info-level log message when package environments have been picked up In-Reply-To: <042.c53199cdee50c6795e3e80c97a39de2b@haskell.org> References: <042.c53199cdee50c6795e3e80c97a39de2b@haskell.org> Message-ID: <057.56d074d42acc7c10622b173889d4d228@haskell.org> #15145: Emit info-level log message when package environments have been picked up -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: feature request | Status: closed Priority: high | Milestone: 8.4.3 Component: Compiler | Version: 8.0.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4689 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 20 18:37:49 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 May 2018 18:37:49 -0000 Subject: [GHC] #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) In-Reply-To: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> References: <042.8c95ac31f99ceda58ba0af61b4bb0fd5@haskell.org> Message-ID: <057.98338b43caf579f54d10e938c8fa239b@haskell.org> #15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.4.3 Component: Compiler | Version: 8.4.1 (CodeGen) | Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: T13658 at runtime | T14779a T14779b T14868 debug | parsing001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4654 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 20 18:40:44 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 May 2018 18:40:44 -0000 Subject: [GHC] #15168: GHC HEAD crashes on Windows 64 after the SRT overhaul (May 16, 2018 and newer) In-Reply-To: <044.deabc7a4c199713a6195b6ed0eaae792@haskell.org> References: <044.deabc7a4c199713a6195b6ed0eaae792@haskell.org> Message-ID: <059.95600b5a3b9fdc4e8cd6572ffa23ec4f@haskell.org> #15168: GHC HEAD crashes on Windows 64 after the SRT overhaul (May 16, 2018 and newer) -------------------------------------+------------------------------------- Reporter: awson | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: high => highest * cc: simonmar (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 20 19:48:34 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 May 2018 19:48:34 -0000 Subject: [GHC] #15170: GHC HEAD panic (dischargeFmv) Message-ID: <050.742dfec2bfbf9cc7b0adae8375103ae6@haskell.org> #15170: GHC HEAD panic (dischargeFmv) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 (Type checker) | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following program panics on GHC HEAD: {{{#!hs {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} {-# LANGUAGE TypeFamilyDependencies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} module Bug where import Data.Kind import Data.Proxy data family Sing (a :: k) data SomeSing :: Type -> Type where SomeSing :: Sing (a :: k) -> SomeSing k class SingKind k where type Demote k = (r :: Type) | r -> k fromSing :: Sing (a :: k) -> Demote k toSing :: Demote k -> SomeSing k withSomeSing :: forall k r . SingKind k => Demote k -> (forall (a :: k). Sing a -> r) -> r withSomeSing x f = case toSing x of SomeSing x' -> f x' newtype instance Sing (f :: k1 ~> k2) = SLambda { applySing :: forall t. Sing t -> Sing (f @@ t) } instance (SingKind k1, SingKind k2) => SingKind (k1 ~> k2) where type Demote (k1 ~> k2) = Demote k1 -> Demote k2 fromSing sFun x = withSomeSing x (fromSing . applySing sFun) toSing = undefined data TyFun :: Type -> Type -> Type type a ~> b = TyFun a b -> Type infixr 0 ~> type family Apply (f :: k1 ~> k2) (x :: k1) :: k2 type f @@ x = Apply f x infixl 9 @@ dcomp :: forall (a :: Type) (b :: a ~> Type) (c :: forall (x :: a). Proxy x ~> b @@ x ~> Type) (f :: forall (x :: a) (y :: b @@ x). Proxy x ~> Proxy y ~> c @@ ('Proxy :: Proxy x) @@ y) (g :: forall (x :: a). Proxy x ~> b @@ x) (x :: a). SingKind (c @@ ('Proxy :: Proxy x) @@ (g @@ ('Proxy :: Proxy x))) => (forall (xx :: a) (yy :: b @@ xx). Sing (f @@ ('Proxy :: Proxy xx) @@ ('Proxy :: Proxy yy))) -> Sing g -> Sing a -> Demote (c @@ ('Proxy :: Proxy x) @@ (g @@ ('Proxy :: Proxy x))) dcomp _sf _ _ = undefined }}} {{{ $ /opt/ghc/head/bin/ghc Bug2.hs [1 of 1] Compiling Bug ( Bug2.hs, Bug2.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.5.20180501 for x86_64-unknown-linux): dischargeFmv [D] _ {0}:: (Apply (f_a1ih[sk:2] xx_a1iA[tau:3] yy_a1iB[tau:3] |> Sym ((TyFun _N ((TyFun (Proxy (Sym {co_a1jm}) (Coh _N {co_a1jm}))_N (Sym {co_a1jB} ; (Apply (Sym {co_a1jm}) <*>_N (Coh ((Coh _N ((TyFun (Sym {co_a1jm}) <*>_N)_N ->_N <*>_N) ; Sym {co_a1jA}) ; (Apply _N ((TyFun (Sym {co_a1jm}) <*>_N)_N ->_N <*>_N) (Coh _N (Sym ((TyFun _N ((TyFun (Sym {co_a1jm}) <*>_N)_N ->_N <*>_N))_N ->_N <*>_N))) <'Proxy>_N)_N) (Sym ((TyFun (Sym {co_a1jm}) <*>_N)_N ->_N <*>_N))) (Coh _N {co_a1jm}))_N))_N ->_N <*>_N))_N ->_N <*>_N)) 'Proxy :: (Proxy (yy_a1iB[tau:3] |> {co_a1jm}) ~> s_a1jp[fmv:0])) ~# (s_a1jQ[fmv:0] :: (Proxy (yy_a1iB[tau:3] |> {co_a1jm}) ~> s_a1jp[fmv:0])) Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1162:37 in ghc:Outputable pprPanic, called at compiler/typecheck/TcSMonad.hs:3047:25 in ghc:TcSMonad }}} On GHC 8.4.2, it simply throws an error: {{{ $ /opt/ghc/8.4.2/bin/ghci Bug2.hs GHCi, version 8.4.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug2.hs, interpreted ) Bug2.hs:53:71: error: • Expected kind ‘Apply b xx’, but ‘y’ has kind ‘b @@ x’ • In the first argument of ‘Proxy’, namely ‘y’ In the first argument of ‘(~>)’, namely ‘Proxy y’ In the second argument of ‘(~>)’, namely ‘Proxy y ~> c @@ ( 'Proxy :: Proxy x) @@ y’ | 53 | (f :: forall (x :: a) (y :: b @@ x). Proxy x ~> Proxy y ~> c @@ ('Proxy :: Proxy x) @@ y) | ^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 20 19:58:16 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 May 2018 19:58:16 -0000 Subject: [GHC] #14975: Refactor (Maybe Coercion) In-Reply-To: <047.51816057ba89e62ff311692e8071c67c@haskell.org> References: <047.51816057ba89e62ff311692e8071c67c@haskell.org> Message-ID: <062.12b2575753aa71d76f3d275fbb09e555@haskell.org> #14975: Refactor (Maybe Coercion) -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11735 | Differential Rev(s): Phab:D4699 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D4699 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 20 20:05:33 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 May 2018 20:05:33 -0000 Subject: [GHC] #15170: GHC HEAD panic (dischargeFmv) In-Reply-To: <050.742dfec2bfbf9cc7b0adae8375103ae6@haskell.org> References: <050.742dfec2bfbf9cc7b0adae8375103ae6@haskell.org> Message-ID: <065.5fd9a898b888b514a3ee5fb88ccedae7@haskell.org> #15170: GHC HEAD panic (dischargeFmv) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Here's as small of an example as I can muster: {{{#!hs {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} module Bug where import Data.Kind import Data.Proxy data TyFun :: Type -> Type -> Type type a ~> b = TyFun a b -> Type infixr 0 ~> type family Apply (f :: k1 ~> k2) (x :: k1) :: k2 type f @@ x = Apply f x infixl 9 @@ wat :: forall (a :: Type) (b :: a ~> Type) (c :: forall (x :: a). Proxy x ~> b @@ x ~> Type) (f :: forall (x :: a) (y :: b @@ x). Proxy x ~> Proxy y ~> c @@ ('Proxy :: Proxy x) @@ y) (x :: a). (forall (xx :: a) (yy :: b @@ xx). Proxy (f @@ ('Proxy :: Proxy xx) @@ ('Proxy :: Proxy yy))) -> () wat _ = () }}} {{{ $ /opt/ghc/head/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.5.20180501 for x86_64-unknown-linux): dischargeFmv [D] _ {0}:: (Apply (f_a1rx[sk:2] xx_a1rH[tau:3] yy_a1rI[tau:3] |> Sym ((TyFun _N ((TyFun (Proxy (Sym {co_a1rP}) (Coh _N {co_a1rP}))_N (Sym {co_a1s4} ; (Apply (Sym {co_a1rP}) <*>_N (Coh ((Coh _N ((TyFun (Sym {co_a1rP}) <*>_N)_N ->_N <*>_N) ; Sym {co_a1s3}) ; (Apply _N ((TyFun (Sym {co_a1rP}) <*>_N)_N ->_N <*>_N) (Coh _N (Sym ((TyFun _N ((TyFun (Sym {co_a1rP}) <*>_N)_N ->_N <*>_N))_N ->_N <*>_N))) <'Proxy>_N)_N) (Sym ((TyFun (Sym {co_a1rP}) <*>_N)_N ->_N <*>_N))) (Coh _N {co_a1rP}))_N))_N ->_N <*>_N))_N ->_N <*>_N)) 'Proxy :: (Proxy (yy_a1rI[tau:3] |> {co_a1rP}) ~> s_a1rS[fmv:0])) ~# (s_a1sj[fmv:0] :: (Proxy (yy_a1rI[tau:3] |> {co_a1rP}) ~> s_a1rS[fmv:0])) Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1162:37 in ghc:Outputable pprPanic, called at compiler/typecheck/TcSMonad.hs:3047:25 in ghc:TcSMonad }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 20 20:35:47 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 May 2018 20:35:47 -0000 Subject: [GHC] #15170: GHC HEAD panic (dischargeFmv) In-Reply-To: <050.742dfec2bfbf9cc7b0adae8375103ae6@haskell.org> References: <050.742dfec2bfbf9cc7b0adae8375103ae6@haskell.org> Message-ID: <065.383e35f02b5a10e5881c3f955af12e58@haskell.org> #15170: GHC HEAD panic (dischargeFmv) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): This flipped from an error to a panic in commit faec8d358985e5d0bf363bd96f23fe76c9e281f7 (`Track type variable scope more carefully.`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 20 22:52:13 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 May 2018 22:52:13 -0000 Subject: [GHC] #13793: Simple program trips checkNurserySanity() In-Reply-To: <046.a36b0da0c049dac7c618bbfdc92da5ef@haskell.org> References: <046.a36b0da0c049dac7c618bbfdc92da5ef@haskell.org> Message-ID: <061.cfd43ae75137a27399fce6fc1fd55c65@haskell.org> #13793: Simple program trips checkNurserySanity() -------------------------------------+------------------------------------- Reporter: niteria | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 8.4.3 Component: Runtime System | Version: 8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4649 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 20 22:53:09 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 May 2018 22:53:09 -0000 Subject: [GHC] #15171: Add HeapView functionality breaks validate (stage 0 ghc is 8.4.2) Message-ID: <042.d4faa7bf45389fae4f27f23c4016d805@haskell.org> #15171: Add HeapView functionality breaks validate (stage 0 ghc is 8.4.2) -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Runtime | Version: 8.5 System | Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Building GHC (amd64) | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: https://phabricator.haskell.org/D3055| -------------------------------------+------------------------------------- {{{ "/opt/ghc/bin/ghc" -hisuf hi -osuf o -hcsuf hc -static -O0 -H64m -Wall -package-db libraries/bootstrapping.conf -this-unit-id mtl-2.2.2 -hide- all-packages -i -ilibraries/mtl/. -ilibraries/mtl/dist-boot/build -Ilibraries/mtl/dist-boot/build -ilibraries/mtl/dist-boot/build/./autogen -Ilibraries/mtl/dist-boot/build/./autogen -Ilibraries/mtl/. -optP- include -optPlibraries/mtl/dist-boot/build/./autogen/cabal_macros.h -package-id base-4.11.1.0 -package-id transformers-0.5.5.0 -Wall -fno- warn-unused-imports -fno-warn-warnings-deprecations -Wcompat -Wnoncanonical-monad-instances -Wnoncanonical-monadfail-instances -XHaskell2010 -no-user-package-db -rtsopts -fno-warn-deprecated-flags -odir libraries/mtl/dist-boot/build -hidir libraries/mtl/dist-boot/build -stubdir libraries/mtl/dist-boot/build -c libraries/mtl/./Control/Monad/RWS/Lazy.hs -o libraries/mtl/dist- boot/build/Control/Monad/RWS/Lazy.o libraries/ghc-heap/GHC/Exts/Heap.hs:119:48: error: • Couldn't match expected type ‘ByteArray#’ with actual type ‘Array# b0’ • In the first argument of ‘sizeofByteArray#’, namely ‘dat’ In the first argument of ‘I#’, namely ‘(sizeofByteArray# dat)’ In the first argument of ‘div’, namely ‘(I# (sizeofByteArray# dat))’ • Relevant bindings include dat :: Array# b0 (bound at libraries/ghc-heap/GHC/Exts/Heap.hs:115:18) | 119 | let nelems = (I# (sizeofByteArray# dat)) `div` wORD_SIZE | ^^^ libraries/ghc-heap/GHC/Exts/Heap.hs:121:47: error: • Couldn't match expected type ‘ByteArray#’ with actual type ‘Array# b0’ • In the first argument of ‘indexWordArray#’, namely ‘dat’ In the first argument of ‘W#’, namely ‘(indexWordArray# dat i)’ In the expression: W# (indexWordArray# dat i) • Relevant bindings include dat :: Array# b0 (bound at libraries/ghc-heap/GHC/Exts/Heap.hs:115:18) | 121 | rawWds = [W# (indexWordArray# dat i) | I# i <- [0.. end] ] | ^^^ libraries/ghc-heap/GHC/Exts/Heap.hs:122:43: error: • Couldn't match expected type ‘Array# a0’ with actual type ‘ByteArray#’ • In the first argument of ‘sizeofArray#’, namely ‘pointers’ In the first argument of ‘I#’, namely ‘(sizeofArray# pointers)’ In the expression: I# (sizeofArray# pointers) | 122 | pelems = I# (sizeofArray# pointers) | ^^^^^^^^ libraries/ghc-heap/GHC/Exts/Heap.hs:123:67: error: • Couldn't match expected type ‘Array# Any’ with actual type ‘ByteArray#’ • In the fourth argument of ‘Array’, namely ‘pointers’ In the second argument of ‘($)’, namely ‘Array 0 (pelems - 1) pelems pointers’ In the expression: amap' Box $ Array 0 (pelems - 1) pelems pointers | 123 | ptrList = amap' Box $ Array 0 (pelems - 1) pelems pointers | ^^^^^^^^ libraries/ghc-heap/ghc.mk:3: recipe for target 'libraries/ghc-heap/dist- boot/build/GHC/Exts/Heap.o' failed make[1]: *** [libraries/ghc-heap/dist-boot/build/GHC/Exts/Heap.o] Error 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 20 22:54:18 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 May 2018 22:54:18 -0000 Subject: [GHC] #15171: Add HeapView functionality breaks validate (stage 0 ghc is 8.4.2) In-Reply-To: <042.d4faa7bf45389fae4f27f23c4016d805@haskell.org> References: <042.d4faa7bf45389fae4f27f23c4016d805@haskell.org> Message-ID: <057.0c993b2faf112cac882ef3a00165cbf5@haskell.org> #15171: Add HeapView functionality breaks validate (stage 0 ghc is 8.4.2) -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Core Libraries | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://phabricator.haskell.org/D3055 -------------------------------------+------------------------------------- Changes (by jrp): * component: Runtime System => Core Libraries -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 20 23:08:05 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 May 2018 23:08:05 -0000 Subject: [GHC] #15167: DerivClause list is not populated for (TyConI (DataD ...)) In-Reply-To: <049.1da123fe6825387f79a8e9ada4e3ab34@haskell.org> References: <049.1da123fe6825387f79a8e9ada4e3ab34@haskell.org> Message-ID: <064.131ce74ef320f1fe65e1d39856cbe578@haskell.org> #15167: DerivClause list is not populated for (TyConI (DataD ...)) -------------------------------------+------------------------------------- Reporter: 0xd34df00d | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Template Haskell | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by 0xd34df00d): Thanks for getting to my report! Seems like `reifyInstances`'s documentation could also be slightly improved: it's not entirely obvious from it right now that it can/should be used to get the list of instances for a data type. Indeed, for the above example, how does one use it to get something about `Eq, Ord, Show` without knowing a priori that those are the classes that `Foo` implements? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 21 00:08:54 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 May 2018 00:08:54 -0000 Subject: [GHC] #15171: Add HeapView functionality breaks validate (stage 0 ghc is 8.4.2) In-Reply-To: <042.d4faa7bf45389fae4f27f23c4016d805@haskell.org> References: <042.d4faa7bf45389fae4f27f23c4016d805@haskell.org> Message-ID: <057.27005dacd0a890f9326ea790a71f75e9@haskell.org> #15171: Add HeapView functionality breaks validate (stage 0 ghc is 8.4.2) -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.6.1 Component: Core Libraries | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3055, Wiki Page: | Phab:D3616 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: https://phabricator.haskell.org/D3055 => Phab:D3055, Phab:D3616 Comment: Yes, this is fixed by Phab:D3616 which I am currently about to merge. Thanks for the ticket though! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 21 00:09:22 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 May 2018 00:09:22 -0000 Subject: [GHC] #9539: TQueue can lead to thread starvation In-Reply-To: <045.f4dc0af39dea75bc36dee0474a4ea69f@haskell.org> References: <045.f4dc0af39dea75bc36dee0474a4ea69f@haskell.org> Message-ID: <060.e1356c76760de0d92c334ae124f276bb@haskell.org> #9539: TQueue can lead to thread starvation -------------------------------------+------------------------------------- Reporter: jwlato | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.2 Resolution: fixed | Keywords: stm Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I'm a bit surprised that we'd want queues with only amortized bounds here. That leads to an arbitrary thread having to reverse a list at an arbitrary time. Would it be better to use a scheduled queue here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 21 00:43:52 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 May 2018 00:43:52 -0000 Subject: [GHC] #14381: Consider making ghc-pkg fill in abi-depends based on depends In-Reply-To: <045.a757b4d974e51bd6ab6f6869ba65de4c@haskell.org> References: <045.a757b4d974e51bd6ab6f6869ba65de4c@haskell.org> Message-ID: <060.22b359603f055a389b9f95f38ef21d99@haskell.org> #14381: Consider making ghc-pkg fill in abi-depends based on depends -------------------------------------+------------------------------------- Reporter: ezyang | Owner: tdammers Type: bug | Status: new Priority: highest | Milestone: 8.4.2 Component: ghc-pkg | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4159 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"1cdc14f9c014f1a520638f7c0a01799ac6d104e6/ghc" 1cdc14f9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1cdc14f9c014f1a520638f7c0a01799ac6d104e6" ghc-pkg: recompute `abi-depends` for updated packages See `Note [Recompute abi-depends]` for more information. Signed-off-by: Austin Seipp Test Plan: `./validate` Reviewers: bgamari, ezyang Reviewed By: bgamari Subscribers: tdammers, juhp, carter, alexbiehl, shlevy, cocreature, rwbarton, thomie GHC Trac Issues: #14381 Differential Revision: https://phabricator.haskell.org/D4159 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 21 06:01:42 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 May 2018 06:01:42 -0000 Subject: [GHC] #10241: BlockedIndefinitelyOnMVar thrown to the thread which is not blocked indefinitely In-Reply-To: <049.aa2da898b4545668797a015c17e2bd6d@haskell.org> References: <049.aa2da898b4545668797a015c17e2bd6d@haskell.org> Message-ID: <064.f848d0ce6c3fa89a4c31b83ae3186acb@haskell.org> #10241: BlockedIndefinitelyOnMVar thrown to the thread which is not blocked indefinitely -------------------------------------+------------------------------------- Reporter: asukamirai | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #10793 | Differential Rev(s): Phab:D4644 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: patch => closed * resolution: => wontfix -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 21 08:38:27 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 May 2018 08:38:27 -0000 Subject: [GHC] #15164: Slowdown in ghc compile times from GHC 8.0.2 to GHC 8.2.1 when doing Called arity analysis In-Reply-To: <046.d99bd58e6ad83ef24f9a7879b45c43ac@haskell.org> References: <046.d99bd58e6ad83ef24f9a7879b45c43ac@haskell.org> Message-ID: <061.55ebf95cc81ba90f064abdcf5be81d49@haskell.org> #15164: Slowdown in ghc compile times from GHC 8.0.2 to GHC 8.2.1 when doing Called arity analysis -------------------------------------+------------------------------------- Reporter: flip101 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"f2ce86c2edc0840f5e731d5286a2a5e484263e3f/ghc" f2ce86c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f2ce86c2edc0840f5e731d5286a2a5e484263e3f" Do better sharing in the short-cut solver Trac #15164 showed that it sometimes really matters to share sub-proofs when solving constraints. Without it, we can get exponentialy bad behaviour. Fortunately, it's easily solved. Note [Shortcut try_solve_from_instance] explains. I did some minor assocaited refactoring. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 21 08:40:42 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 May 2018 08:40:42 -0000 Subject: [GHC] #15164: Slowdown in ghc compile times from GHC 8.0.2 to GHC 8.2.1 when doing Called arity analysis In-Reply-To: <046.d99bd58e6ad83ef24f9a7879b45c43ac@haskell.org> References: <046.d99bd58e6ad83ef24f9a7879b45c43ac@haskell.org> Message-ID: <061.66ed934a490d8e806745bf8b43e0e9b5@haskell.org> #15164: Slowdown in ghc compile times from GHC 8.0.2 to GHC 8.2.1 when doing Called arity analysis -------------------------------------+------------------------------------- Reporter: flip101 | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Compile-time | Test Case: performance bug | perf/compiler/T15164 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => perf/compiler/T15164 * resolution: => fixed Comment: Thanks for the detective work. Should now be fixed in 8.6. And we have a solid workaround for 8.4 (see comment:16). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 21 09:03:57 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 May 2018 09:03:57 -0000 Subject: [GHC] #15127: Unbox around runRW# In-Reply-To: <045.fd34327d751bad75e01da7c62c0c3479@haskell.org> References: <045.fd34327d751bad75e01da7c62c0c3479@haskell.org> Message-ID: <060.be2ab2e9ada0cc538d0245b146e4fd08@haskell.org> #15127: Unbox around runRW# -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.8.1 Component: Compiler | Version: 8.4.2 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by simonpj): See also #13014 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 21 09:29:55 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 May 2018 09:29:55 -0000 Subject: [GHC] #9123: Need for higher kinded roles In-Reply-To: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> References: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> Message-ID: <061.48c96b6f061c7f354e5848cb145969c4@haskell.org> #9123: Need for higher kinded roles -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Keywords: Roles, Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I have discovered something interesting. The new quantified-constraints machinery is enough to accept the example in comment:42 (because of the super-duper handling of superclasses): {{{ type role Wrap representational nominal newtype Wrap m a = Wrap (m a) class Monad' m where join' :: forall a. m (m a) -> m a instance ( forall p q. Coercible p q => Coercible (m p) (m q) , Monad' m) => Monad' (Wrap m) where join' :: forall a. Wrap m (Wrap m a) -> Wrap m a join' = coerce @(m (m a) -> m a) @(Wrap m (Wrap m a) -> Wrap m a) join' }}} But alas it is NOT enough to accept the example in comment:29! Here is how it goes wrong. {{{ class MyMonad m where join :: m (m a) -> m a type role StateT nominal representational nominal -- as inferred data StateT s m a = StateT (s -> m (a, s)) instance MyMonad m => Monad (StateT s m) where ... type role IntStateT representational nominal -- as inferred newtype IntStateT m a = IntStateT (StateT Int m a) }}} and suppose we use quantified constraints to do this: {{{ instance (MyMonad m, forall p q. Coercible p q => Coercible (m p) (m q)) => MyMonad (IntStateT m) where join :: forall a. IntStateT m (IntStateT m a) -> IntStateT m a join = coerce @(StateT Int m (StateT Int m a) -> StateT Int m a) @(IntStateT m (IntStateT m a) -> IntStateT m a) join }}} You would think this should work. But it doesn't. {{{ T9123a.hs:27:10: error: • Couldn't match type ‘IntStateT m a’ with ‘StateT Int m a’ arising from a use of ‘coerce’ }}} The reason is that from the `coerce` we gert {{{ [W] Coercible (StateT Int m (StateT Int m a) -> StateT Int m a) (IntStateT m (IntStateT m a) -> IntStateT m a) --> (built in rule) [W] (StateT Int m (StateT Int m a) -> StateT Int m a) ~R# (IntStateT m (IntStateT m a) -> IntStateT m a) --> (decompose arrow) [W] (StateT Int m (StateT Int m a)) ~R# (IntStateT m (IntStateT m a)) [W] StateT Int m a ~ IntStateT m a -- This one is easily solved --> (unwrap IntStateT newtype) [W] (StateT Int m (StateT Int m a)) ~R# (StateT Int m (IntStateT m a)) --> (decompose StateT) YIKES [W] (StateT Int m a) ~N# (IntStateT m a) }}} This last step is the mistake. Instead we should use the "given" {{{ forall p q. Coercible p q => Coercible (m p) (m q) }}} Then we'd have {{{ [W] (StateT Int m (StateT Int m a)) ~R# (StateT Int m (IntStateT m a)) --> (use given: forall p q. Coercible p q => Coercible (m p) (m q)) [W] (StateT Int m a) ~R# (IntStateT m a) }}} which of course we can solve. Now we have a very unsettling overlap between the `(decompose `StateT)` rule and the `(use given)` rule, in which the former can lead us into a dead end. Moreover, in the [https://www.microsoft.com/en-us/research/publication /safe-coercions/ Safe Coercions paper], Section 2.2.4, we suggest (but do not really work out) that we can only decompose `T a1 .. an ~R# T b1 .. bn` if the nominal-role parameters are equal --- whereas in the implementation we decompose eagerly and emit a nominal equality, which is wrong on this occasion. I wonder what would happen if we refrained from decomposing when the nominal parameters differed? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 21 09:38:43 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 May 2018 09:38:43 -0000 Subject: [GHC] #15168: GHC HEAD crashes on Windows 64 after the SRT overhaul (May 16, 2018 and newer) In-Reply-To: <044.deabc7a4c199713a6195b6ed0eaae792@haskell.org> References: <044.deabc7a4c199713a6195b6ed0eaae792@haskell.org> Message-ID: <059.c0b9d25f255d2e4c74df19be6382214b@haskell.org> #15168: GHC HEAD crashes on Windows 64 after the SRT overhaul (May 16, 2018 and newer) -------------------------------------+------------------------------------- Reporter: awson | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * cc: Phyx- (added) Comment: Sorry about this. Of course if we're not able to resolve this quickly we should back out the patches. I don't have any theories yet about what the cause might be, and I don't have easy access to a machine to test on; @bgamari would you be able to take a look by any chance? or @Phyx-? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 21 10:01:59 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 May 2018 10:01:59 -0000 Subject: [GHC] #15164: Slowdown in ghc compile times from GHC 8.0.2 to GHC 8.2.1 when doing Called arity analysis In-Reply-To: <046.d99bd58e6ad83ef24f9a7879b45c43ac@haskell.org> References: <046.d99bd58e6ad83ef24f9a7879b45c43ac@haskell.org> Message-ID: <061.9f2d7ddb0a9342cb4834bd7caf671e59@haskell.org> #15164: Slowdown in ghc compile times from GHC 8.0.2 to GHC 8.2.1 when doing Called arity analysis -------------------------------------+------------------------------------- Reporter: flip101 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Compile-time | Test Case: performance bug | perf/compiler/T15164 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: closed => new * resolution: fixed => Comment: Actually, Joachim, you might still want to look at this. Although the code is now the same as when you leave out those instance contexts, the Called Arity pass still allocates 10x more than any other pass, and there is a visible pause when doing `-dshow-passes` {{{ [1 of 1] Compiling T15164 ( T15164.hs, T15164.o ) [Optimisation flags changed] *** Parser [T15164]: !!! Parser [T15164]: finished in 138.64 milliseconds, allocated 14.548 megabytes *** Renamer/typechecker [T15164]: !!! Renamer/typechecker [T15164]: finished in 564.37 milliseconds, allocated 75.649 megabytes *** Desugar [T15164]: Result size of Desugar (before optimization) = {terms: 8,197, types: 8,602, coercions: 0, joins: 0/1,317} Result size of Desugar (after optimization) = {terms: 7,303, types: 7,589, coercions: 132, joins: 0/888} !!! Desugar [T15164]: finished in 397.68 milliseconds, allocated 44.898 megabytes *** Simplifier [T15164]: Result size of Simplifier iteration=1 = {terms: 8,488, types: 9,420, coercions: 4,178, joins: 0/1,271} Result size of Simplifier iteration=2 = {terms: 7,722, types: 8,271, coercions: 8,086, joins: 0/888} Result size of Simplifier = {terms: 7,722, types: 8,271, coercions: 8,086, joins: 0/888} !!! Simplifier [T15164]: finished in 1026.47 milliseconds, allocated 163.355 megabytes *** Specialise [T15164]: Result size of Specialise = {terms: 7,788, types: 8,373, coercions: 8,102, joins: 0/894} !!! Specialise [T15164]: finished in 49.66 milliseconds, allocated 9.532 megabytes *** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) [T15164]: Result size of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) = {terms: 9,133, types: 18,102, coercions: 8,102, joins: 0/116} !!! Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) [T15164]: finished in 296.67 milliseconds, allocated 56.540 megabytes *** Simplifier [T15164]: Result size of Simplifier iteration=1 = {terms: 9,019, types: 17,757, coercions: 8,096, joins: 0/116} Result size of Simplifier iteration=2 = {terms: 8,860, types: 17,474, coercions: 8,054, joins: 0/109} Result size of Simplifier = {terms: 8,860, types: 17,474, coercions: 8,054, joins: 0/109} !!! Simplifier [T15164]: finished in 1315.09 milliseconds, allocated 178.537 megabytes *** Simplifier [T15164]: Result size of Simplifier iteration=1 = {terms: 8,716, types: 17,272, coercions: 8,054, joins: 0/109} Result size of Simplifier = {terms: 8,716, types: 17,272, coercions: 8,054, joins: 0/109} !!! Simplifier [T15164]: finished in 833.40 milliseconds, allocated 123.259 megabytes *** Simplifier [T15164]: Result size of Simplifier = {terms: 8,716, types: 17,272, coercions: 8,054, joins: 0/109} !!! Simplifier [T15164]: finished in 317.06 milliseconds, allocated 60.850 megabytes *** Float inwards [T15164]: Result size of Float inwards = {terms: 8,716, types: 17,272, coercions: 8,054, joins: 0/109} !!! Float inwards [T15164]: finished in 42.00 milliseconds, allocated 10.019 megabytes *** Called arity analysis [T15164]: Result size of Called arity analysis = {terms: 8,716, types: 17,272, coercions: 8,054, joins: 0/109} !!! Called arity analysis [T15164]: finished in 6284.17 milliseconds, allocated 1793.237 megabytes *** Simplifier [T15164]: Result size of Simplifier iteration=1 = {terms: 8,716, types: 17,272, coercions: 8,054, joins: 0/109} Result size of Simplifier = {terms: 8,716, types: 17,272, coercions: 8,054, joins: 0/109} !!! Simplifier [T15164]: finished in 793.92 milliseconds, allocated 121.870 megabytes *** Demand analysis [T15164]: Result size of Demand analysis = {terms: 8,716, types: 17,272, coercions: 8,054, joins: 0/109} !!! Demand analysis [T15164]: finished in 440.65 milliseconds, allocated 49.624 megabytes *** Worker Wrapper binds [T15164]: Result size of Worker Wrapper binds = {terms: 11,775, types: 29,390, coercions: 8,054, joins: 0/761} !!! Worker Wrapper binds [T15164]: finished in 12.07 milliseconds, allocated 3.429 megabytes *** Simplifier [T15164]: Result size of Simplifier iteration=1 = {terms: 17,573, types: 104,236, coercions: 890, joins: 0/543} Result size of Simplifier = {terms: 5,574, types: 18,021, coercions: 890, joins: 0/63} !!! Simplifier [T15164]: finished in 1502.93 milliseconds, allocated 170.271 megabytes *** Exitification transformation [T15164]: Result size of Exitification transformation = {terms: 5,574, types: 18,021, coercions: 890, joins: 0/63} !!! Exitification transformation [T15164]: finished in 2.65 milliseconds, allocated 0.638 megabytes *** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}) [T15164]: Result size of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}) = {terms: 5,574, types: 18,021, coercions: 890, joins: 0/63} !!! Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}) [T15164]: finished in 139.13 milliseconds, allocated 31.777 megabytes *** Common sub-expression [T15164]: Result size of Common sub-expression = {terms: 4,921, types: 12,615, coercions: 862, joins: 0/63} !!! Common sub-expression [T15164]: finished in 57.98 milliseconds, allocated 9.568 megabytes *** Float inwards [T15164]: Result size of Float inwards = {terms: 4,915, types: 12,604, coercions: 862, joins: 0/60} !!! Float inwards [T15164]: finished in 8.74 milliseconds, allocated 4.139 megabytes *** Simplifier [T15164]: Result size of Simplifier iteration=1 = {terms: 4,719, types: 12,081, coercions: 862, joins: 0/60} Result size of Simplifier = {terms: 4,719, types: 12,081, coercions: 862, joins: 0/60} !!! Simplifier [T15164]: finished in 237.42 milliseconds, allocated 48.927 megabytes *** Demand analysis [T15164]: Result size of Demand analysis = {terms: 4,719, types: 12,081, coercions: 862, joins: 0/60} !!! Demand analysis [T15164]: finished in 93.32 milliseconds, allocated 22.688 megabytes *** CoreTidy [T15164]: Result size of Tidy Core = {terms: 4,815, types: 13,321, coercions: 865, joins: 0/60} !!! CoreTidy [T15164]: finished in 52.63 milliseconds, allocated 14.762 megabytes Created temporary directory: /tmp/ghc8754_0 *** CorePrep [T15164]: Result size of CorePrep = {terms: 6,049, types: 15,480, coercions: 865, joins: 0/363} !!! CorePrep [T15164]: finished in 35.54 milliseconds, allocated 10.242 megabytes *** Stg2Stg: *** CodeGen [T15164]: !!! CodeGen [T15164]: finished in 907.70 milliseconds, allocated 209.890 megabytes *** Assembler: *** CorePrep [T15164]: Result size of CorePrep = {terms: 6,049, types: 15,480, coercions: 865, joins: 0/363} !!! CorePrep [T15164]: finished in 223.32 milliseconds, allocated 10.223 megabytes *** Stg2Stg: *** CodeGen [T15164]: !!! CodeGen [T15164]: finished in 859.65 milliseconds, allocated 218.926 megabytes *** Assembler: }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 21 10:03:05 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 May 2018 10:03:05 -0000 Subject: [GHC] #15164: Slowdown in ghc compile times from GHC 8.0.2 to GHC 8.2.1 when doing Called arity analysis In-Reply-To: <046.d99bd58e6ad83ef24f9a7879b45c43ac@haskell.org> References: <046.d99bd58e6ad83ef24f9a7879b45c43ac@haskell.org> Message-ID: <061.f5fd548149784969ac791eb16001af42@haskell.org> #15164: Slowdown in ghc compile times from GHC 8.0.2 to GHC 8.2.1 when doing Called arity analysis -------------------------------------+------------------------------------- Reporter: flip101 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Compile-time | Test Case: performance bug | perf/compiler/T15164 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"5f3fb71213e78838cd3060be37ad2d9dd1ed247f/ghc" 5f3fb71/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5f3fb71213e78838cd3060be37ad2d9dd1ed247f" Fix perf numbers for #15164 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 21 10:33:57 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 May 2018 10:33:57 -0000 Subject: [GHC] #15172: Undecidable instances slip through Message-ID: <046.cc6dd12b5882dbdf2439449eeaf7ffdc@haskell.org> #15172: Undecidable instances slip through -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Consider {{{ {-# LANGUAGE FlexibleInstances, TypeFamilies, ConstraintKinds #-} type family F a :: Constraint class C a where instance (F a) => C [[a]] where }}} This should be rejected because the `F a` constraint could expand to be arbitrarily large, depending on `F`. There's simply a missing check in `checkInstTermination`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 21 10:34:22 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 May 2018 10:34:22 -0000 Subject: [GHC] #15172: Undecidable instances slip through In-Reply-To: <046.cc6dd12b5882dbdf2439449eeaf7ffdc@haskell.org> References: <046.cc6dd12b5882dbdf2439449eeaf7ffdc@haskell.org> Message-ID: <061.6f66ec4fa4c6df556d696d7738499768@haskell.org> #15172: Undecidable instances slip through -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > Consider > {{{ > {-# LANGUAGE FlexibleInstances, TypeFamilies, ConstraintKinds #-} > > type family F a :: Constraint > > class C a where > instance (F a) => C [[a]] where > }}} > This should be rejected because the `F a` constraint could expand to be > arbitrarily large, depending on `F`. There's simply a missing check in > `checkInstTermination`. New description: Consider {{{ {-# LANGUAGE FlexibleInstances, TypeFamilies, ConstraintKinds #-} type family F a :: Constraint class C a where instance (F a) => C [[a]] where }}} This should be rejected because the `F a` constraint could expand to be arbitrarily large, depending on `F`. But it's accepted by HEAD. There's simply a missing check in `checkInstTermination`. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 21 12:00:46 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 May 2018 12:00:46 -0000 Subject: [GHC] #15168: GHC HEAD crashes on Windows 64 after the SRT overhaul (May 16, 2018 and newer) In-Reply-To: <044.deabc7a4c199713a6195b6ed0eaae792@haskell.org> References: <044.deabc7a4c199713a6195b6ed0eaae792@haskell.org> Message-ID: <059.5a78a8f7c7588f0d4f927ee2e5f5e913@haskell.org> #15168: GHC HEAD crashes on Windows 64 after the SRT overhaul (May 16, 2018 and newer) -------------------------------------+------------------------------------- Reporter: awson | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by awson): Don't know if this would make things any clearer, but changing `-A` parameter I've also managed to trigger `ARR_WORDS object entered!` and `Evaluated a CAF that was GC'd!` internal errors. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 21 12:04:18 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 May 2018 12:04:18 -0000 Subject: [GHC] #15170: GHC HEAD panic (dischargeFmv) In-Reply-To: <050.742dfec2bfbf9cc7b0adae8375103ae6@haskell.org> References: <050.742dfec2bfbf9cc7b0adae8375103ae6@haskell.org> Message-ID: <065.df23f99915fa0d8cffdb75c93b45e8d9@haskell.org> #15170: GHC HEAD panic (dischargeFmv) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"57858fc8b519078ae89a4859ce7588adb39f6e96/ghc" 57858fc/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="57858fc8b519078ae89a4859ce7588adb39f6e96" Make dischargeFmv handle Deriveds A Derived CFunEqCan does not "own" its FlatMetaTv (fmv), and should not update it. But one caller (canCFunEqCan) was failing to satisfy the precondition to dischargeFmv, which led to a crash (Trac #15170). I fixed this by making dischargeFmv handle Deriveds (to avoid forcing each caller to do so separately). NB: this does not completely fix the original #15170 bug, but I'll explain that on the ticket. The test case for this patch is actually the program in comment:1. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 21 12:16:32 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 May 2018 12:16:32 -0000 Subject: [GHC] #15171: Add HeapView functionality breaks validate (stage 0 ghc is 8.4.2) In-Reply-To: <042.d4faa7bf45389fae4f27f23c4016d805@haskell.org> References: <042.d4faa7bf45389fae4f27f23c4016d805@haskell.org> Message-ID: <057.48cc00004c56d4fd1974d75a1f005f8c@haskell.org> #15171: Add HeapView functionality breaks validate (stage 0 ghc is 8.4.2) -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.6.1 Component: Core Libraries | Version: 8.5 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3055, Wiki Page: | Phab:D4716 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * differential: Phab:D3055, Phab:D3616 => Phab:D3055, Phab:D4716 * resolution: => fixed Comment: This was landed in commit e1fd946103fba2b8bfc4f5b3096de4307a7e6f81. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 21 12:16:34 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 May 2018 12:16:34 -0000 Subject: [GHC] #15170: GHC HEAD panic (dischargeFmv) In-Reply-To: <050.742dfec2bfbf9cc7b0adae8375103ae6@haskell.org> References: <050.742dfec2bfbf9cc7b0adae8375103ae6@haskell.org> Message-ID: <065.4f99d2dcf1ae61fc48172545627a45b9@haskell.org> #15170: GHC HEAD panic (dischargeFmv) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): The patch in comment:3 makes the program in comment:1 compile fine. However, the program in the Description now fails with a Lint error: {{{ *** Core Lint errors : in result of Desugar (before optimization) *** : warning: In the type ‘forall (x :: a_a10V[sk:0]) a (b :: a ~> *) (c :: forall (x :: a). Proxy x ~> ((b @@ x) ~> *)) (f :: forall (x :: a) (y :: b @@ x). Proxy x ~> (Proxy y ~> ((c x @@ 'Proxy) @@ y))) (g :: forall (x :: a). Proxy x ~> (b @@ x)) (x :: a). SingKind ((c x @@ 'Proxy) @@ (g x @@ 'Proxy)) => (forall (xx :: a) (yy :: b @@ xx). Sing ((f xx yy @@ 'Proxy) @@ 'Proxy)) -> Sing (g x) -> Sing a -> Demote ((c x @@ 'Proxy) @@ (g x @@ 'Proxy))’ @ a_a10V[sk:0] is out of scope }}} I believe that the cause is the same as #14880, which I would love to get nailed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 21 12:17:03 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 May 2018 12:17:03 -0000 Subject: [GHC] #15170: GHC HEAD panic (dischargeFmv) In-Reply-To: <050.742dfec2bfbf9cc7b0adae8375103ae6@haskell.org> References: <050.742dfec2bfbf9cc7b0adae8375103ae6@haskell.org> Message-ID: <065.6421ff56389474686901ecb39a06bace@haskell.org> #15170: GHC HEAD panic (dischargeFmv) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | polykinds/T15170 Blocked By: 14880 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => polykinds/T15170 * blockedby: => 14880 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 21 12:18:40 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 May 2018 12:18:40 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.9cbeaa2a222324ed703cfce8aef1968c@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * blocking: 15170 => Comment: I believe that #15170 is also blocked on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 21 12:20:09 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 May 2018 12:20:09 -0000 Subject: [GHC] #15143: Passing an IO value through several functions results in program hanging. In-Reply-To: <048.73b9ec11a636d72a48f971cab3c258d0@haskell.org> References: <048.73b9ec11a636d72a48f971cab3c258d0@haskell.org> Message-ID: <063.071beb3ee82d08dbceeff00a90091de3@haskell.org> #15143: Passing an IO value through several functions results in program hanging. -------------------------------------+------------------------------------- Reporter: Burtannia | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: invalid | 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => invalid Comment: As explained above, this is expected behavior. Closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 21 12:22:36 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 May 2018 12:22:36 -0000 Subject: [GHC] #14230: Gruesome kind mismatch errors for associated data family instances In-Reply-To: <050.be2138b3feceaf8cddb1acd9189d3e67@haskell.org> References: <050.be2138b3feceaf8cddb1acd9189d3e67@haskell.org> Message-ID: <065.e818589c57afc3810e442fe46664f5c2@haskell.org> #14230: Gruesome kind mismatch errors for associated data family instances -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.3 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #14175 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * milestone: 8.4.1 => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 21 12:36:21 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 May 2018 12:36:21 -0000 Subject: [GHC] #15170: GHC HEAD panic (dischargeFmv) In-Reply-To: <050.742dfec2bfbf9cc7b0adae8375103ae6@haskell.org> References: <050.742dfec2bfbf9cc7b0adae8375103ae6@haskell.org> Message-ID: <065.405453822f6210294bafa90276638ae2@haskell.org> #15170: GHC HEAD panic (dischargeFmv) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | polykinds/T15170 Blocked By: | Blocking: Related Tickets: #14880, #15076 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => fixed * related: => #14880, #15076 Comment: Thanks, Simon! Ironically, I was writing this to work around #14880/#15076, and while I applied the workaround to `f`, I forgot to apply it to `g`. This is the function that I //meant// to write: {{{#!hs dcomp :: forall (a :: Type) (b :: a ~> Type) (c :: forall (x :: a). Proxy x ~> b @@ x ~> Type) (f :: forall (x :: a) (y :: b @@ x). Proxy x ~> Proxy y ~> c @@ ('Proxy :: Proxy x) @@ y) (g :: forall (x :: a). Proxy x ~> b @@ x) (x :: a). SingKind (c @@ ('Proxy :: Proxy x) @@ (g @@ ('Proxy :: Proxy x))) => (forall (xx :: a) (yy :: b @@ xx). Sing (f @@ ('Proxy :: Proxy xx) @@ ('Proxy :: Proxy yy))) -> (forall (xx :: a). Sing (g @@ ('Proxy :: Proxy xx))) -> Sing a -> Demote (c @@ ('Proxy :: Proxy x) @@ (g @@ ('Proxy :: Proxy x))) dcomp _sf _ _ = undefined }}} And after your most recent patch, this compiles without a hitch, even with `-dcore-lint`! I think we can close this in favor of #14880/#15076, as the Core Lint error in the original program is just a dressed-up version of the program in #15076. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 21 12:39:36 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 May 2018 12:39:36 -0000 Subject: [GHC] #15172: Undecidable instances slip through In-Reply-To: <046.cc6dd12b5882dbdf2439449eeaf7ffdc@haskell.org> References: <046.cc6dd12b5882dbdf2439449eeaf7ffdc@haskell.org> Message-ID: <061.72130ee5cecaf6baa0d9a9aa67a446ca@haskell.org> #15172: Undecidable instances slip through -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"af0757de4649ca562a0e9a624ebef155113531ab/ghc" af0757de/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="af0757de4649ca562a0e9a624ebef155113531ab" Check for type families in an instance context This patch adds a check for type families to the instance-decl termination check. See Note [Type families in instance contexts] and Trac #15172. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 21 12:40:38 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 May 2018 12:40:38 -0000 Subject: [GHC] #15172: Undecidable instances slip through In-Reply-To: <046.cc6dd12b5882dbdf2439449eeaf7ffdc@haskell.org> References: <046.cc6dd12b5882dbdf2439449eeaf7ffdc@haskell.org> Message-ID: <061.2a6ecd867154e01bb53bf6d68e08779f@haskell.org> #15172: Undecidable instances slip through -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_fail/T15172 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => indexed-types/should_fail/T15172 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 21 12:47:18 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 May 2018 12:47:18 -0000 Subject: [GHC] #14325: Erroneous program emits no errors In-Reply-To: <046.40df183102ba61ea001c050698aa9aba@haskell.org> References: <046.40df183102ba61ea001c050698aa9aba@haskell.org> Message-ID: <061.8d473c1fa51cb77e098948a52721ee93@haskell.org> #14325: Erroneous program emits no errors -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: | DeferredErrors Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T14325 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => DeferredErrors -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 21 12:47:30 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 May 2018 12:47:30 -0000 Subject: [GHC] #14370: improve documentation of -fdefer-typed-holes for naked expressions in ghci In-Reply-To: <044.22e5f2aa694f3f07f37c874e3f79e431@haskell.org> References: <044.22e5f2aa694f3f07f37c874e3f79e431@haskell.org> Message-ID: <059.cc76ceb4902c3858f544620b29eb3683@haskell.org> #14370: improve documentation of -fdefer-typed-holes for naked expressions in ghci -------------------------------------+------------------------------------- Reporter: int-e | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.2.1 Resolution: | Keywords: | DeferredErrors 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: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => DeferredErrors -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 21 12:47:50 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 May 2018 12:47:50 -0000 Subject: [GHC] #14722: Error message points to wrong location In-Reply-To: <051.c333e5a6f35eca7f4991a44f21fca447@haskell.org> References: <051.c333e5a6f35eca7f4991a44f21fca447@haskell.org> Message-ID: <066.5c7fa5ff86d49f4fd7dcc3a6ce2ffe8b@haskell.org> #14722: Error message points to wrong location -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | TypeApplications, DeferredErrors 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: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: TypeApplications => TypeApplications, DeferredErrors -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 21 13:24:43 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 May 2018 13:24:43 -0000 Subject: [GHC] #9123: Need for higher kinded roles In-Reply-To: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> References: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> Message-ID: <061.70af95b1ed85913a14c738825faffed6@haskell.org> #9123: Need for higher kinded roles -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Keywords: Roles, Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I don't see how you can use the implication given the way you've described. (Look at your "use given:" line. How is it working?) Indeed, I think the program, as written, should be rejected. Role inference correctly deems the final index to `StateT` to have a nominal role, as it appears as an argument to a type variable. Therefore, I think the solver is doing the right thing. On the other hand, what happens if you defined `StateT` to be a newtype? If `StateT` were a newtype, then the solver could (plausibly) unwrap the newtype, and then the given would apply. I don't know if the solver does this -- it's quite conceivable that changing `StateT` to newtype won't change the behavior, but then at least we'd have a possible way out. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 21 14:51:55 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 May 2018 14:51:55 -0000 Subject: [GHC] #9123: Need for higher kinded roles In-Reply-To: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> References: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> Message-ID: <061.496967abf6c16ed78071e210a13cd6da@haskell.org> #9123: Need for higher kinded roles -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Keywords: Roles, Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Look at your "use given:" line. How is it working? Well, I'm sweeping a bit under the carpet. The super-duper superclass machinery arranges that if you have {{{ [G] forall p q. Coercible p q => Coercible (m p) (m q) }}} then you also have {{{ [G] forall p q. Coercible p q => m p ~R# m q }}} and it's ''that'' Given that takes the step {{{ [W] (StateT Int m (StateT Int m a)) ~R# (StateT Int m (IntStateT m a)) --> (use given: forall p q. Coercible p q => m p ~R# m q) [W] Coercible (StateT Int m a) (IntStateT m a) }}} Now to prove that `Coercible` constraint we need `StateT Int m a ~R# IntStateT m a`. -------------- However, you are absolutely right. The Given we have {{{ [G] forall p q. Coercible p q => Coercible (m p) (m q) }}} is not quantified over `forall m`; it only holds for `m`, and not for `StateT Int m`! So my claim that you can use the Given is completely false. Sorry about that. ------------------ > On the other hand, what happens if you defined StateT to be a newtype? If StateT were a newtype, then the solver could (plausibly) unwrap the newtype, and then the given would apply. Yes it can, and yes, it does! The newtype-unwrapping rule precedes the tycon-decompostion rule in `can_eq_nc'`. And indeed with the change from data type to newtype, the program in comment:29 compiles fine. Your comment in comment:29 "-- could be a newtype, but that doesn't change my argument" is quite false. ------------- Bottom line: I should comment the importance of unwrapping before decomposition. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 21 15:02:07 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 May 2018 15:02:07 -0000 Subject: [GHC] #15168: GHC HEAD crashes on Windows 64 after the SRT overhaul (May 16, 2018 and newer) In-Reply-To: <044.deabc7a4c199713a6195b6ed0eaae792@haskell.org> References: <044.deabc7a4c199713a6195b6ed0eaae792@haskell.org> Message-ID: <059.09e70a1137de6dcb92c90b9a71e0e420@haskell.org> #15168: GHC HEAD crashes on Windows 64 after the SRT overhaul (May 16, 2018 and newer) -------------------------------------+------------------------------------- Reporter: awson | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I can add it to my list but it may not be until later in the week until I get to it. Perhaps we should revert for now. Unfortunately this is all very messy since ec22f7ddc81b40a9dbcf140e5cf44730cb776d00 conflicted. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 21 15:18:31 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 May 2018 15:18:31 -0000 Subject: [GHC] #9123: Need for higher kinded roles In-Reply-To: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> References: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> Message-ID: <061.730085f6bad0c176f6007440406f6c89@haskell.org> #9123: Need for higher kinded roles -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Keywords: Roles, Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I had seen the bit you had hidden under the carpet, but was still stuck on the "completely false" part -- glad we agree there. :) And I'm glad that the current implementation is correct. If you're documenting this, you may wish to refresh yourself on Section 5.3.1 of the [https://repository.brynmawr.edu/cgi/viewcontent.cgi?referer=&httpsredir=1&article=1010&context=compsci_pubs JFP "Safe Coercions" paper], which goes over all this in some detail. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 21 15:50:16 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 May 2018 15:50:16 -0000 Subject: [GHC] #9123: Need for higher kinded roles In-Reply-To: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> References: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> Message-ID: <061.740a2ac53567fa8cd7e76a443171906d@haskell.org> #9123: Need for higher kinded roles -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Keywords: Roles, Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > you may wish to refresh yourself on Section 5.3.1 Ah yes. But it actually doesn't explain the importance of giving unwrapping priority. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 21 15:54:36 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 May 2018 15:54:36 -0000 Subject: [GHC] #11197: Overeager deferred type errors In-Reply-To: <047.311058030fc6bc2d09ef05760e42135c@haskell.org> References: <047.311058030fc6bc2d09ef05760e42135c@haskell.org> Message-ID: <062.f04687f9c7d26bcfb94776f5773a94db@haskell.org> #11197: Overeager deferred type errors -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 7.11 checker) | Keywords: TypeInType, Resolution: | DeferredErrors Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: TypeInType => TypeInType, DeferredErrors -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 21 19:11:56 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 May 2018 19:11:56 -0000 Subject: [GHC] #15142: GHC HEAD regression: tcTyVarDetails In-Reply-To: <050.e98a1ae073f44bf5c57814edebb43575@haskell.org> References: <050.e98a1ae073f44bf5c57814edebb43575@haskell.org> Message-ID: <065.2edfe2507e5dedb8fd0d60890f455eb5@haskell.org> #15142: GHC HEAD regression: tcTyVarDetails -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: TypeInType, Resolution: | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Comparing the results of `-ddump-tc-trace` on this program: {{{#!hs {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind class C (a :: Type) (b :: k) where type T b }}} On GHC 8.4.2, we have: {{{ kcTyClGroup: initial kinds [r1xu :-> ATcTyCon C :: forall k. * -> k -> Constraint, r1xA :-> ATcTyCon T :: forall k. k -> *] }}} But on GHC HEAD, we have: {{{ kcTyClGroup: initial kinds C :: forall k. * -> k -> Constraint T :: forall (k :: k_a1zm[tau:1]) (co :: k_a1zm[tau:1] GHC.Prim.~# *). (k |> {co_a1zq}) -> * }}} And indeed, `tcTyVarDetails` appears to be panicking on `co`. But I haven't the foggiest idea of what it's doing there... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 21 22:30:48 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 May 2018 22:30:48 -0000 Subject: [GHC] #15168: GHC HEAD crashes on Windows 64 after the SRT overhaul (May 16, 2018 and newer) In-Reply-To: <044.deabc7a4c199713a6195b6ed0eaae792@haskell.org> References: <044.deabc7a4c199713a6195b6ed0eaae792@haskell.org> Message-ID: <059.8e11fafeaad78a64e0e4722502572d03@haskell.org> #15168: GHC HEAD crashes on Windows 64 after the SRT overhaul (May 16, 2018 and newer) -------------------------------------+------------------------------------- Reporter: awson | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): I am unable to reproduce the complete failure scenario @awson is seeing. {{{ Tamar at Pinky MINGW64 ~/ghc $ inplace/bin/ghc-stage2.exe --version The Glorious Glasgow Haskell Compilation System, version 8.5.20180521 Tamar at Pinky MINGW64 ~/ghc $ inplace/bin/ghc-stage2.exe -fforce-recomp hello.hs [1 of 1] Compiling Main ( hello.hs, hello.o ) Linking hello.exe ... Tamar at Pinky MINGW64 ~/ghc $ ./hello.exe Hello World }}} That said, the bindisttest does fail with: {{{ ghc-cabal.exe: 'E:/ghc- dev/msys64/home/Tamar/ghc/bindistprep/ghc-8.5.20180521/bin/ghc.exe' exited with an error: ghc.exe: internal error: evacuate: strange closure type 912 (GHC version 8.5.20180521 for x86_64_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 21 23:22:12 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 May 2018 23:22:12 -0000 Subject: [GHC] #11197: Overeager deferred type errors In-Reply-To: <047.311058030fc6bc2d09ef05760e42135c@haskell.org> References: <047.311058030fc6bc2d09ef05760e42135c@haskell.org> Message-ID: <062.b0b9263ab8b912db16f0593326b147a3@haskell.org> #11197: Overeager deferred type errors -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 7.11 checker) | Keywords: TypeInType, Resolution: | DeferredErrors Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Does `-fdefer-type-errors` pull its weight as a compiler feature? The package mentioned above (`should-not-typecheck`) could arguably be improved by using GHCi instead. I think it makes sense to at least ''consider'' the alternative of ripping out the feature instead of jumping through hoops to fix it. It strikes me as complicated, intrusive, and (to my mind) not very useful. But it would be nice to hear whether people find it useful for writing programs or for teaching Haskell to beginners. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 21 23:22:25 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 May 2018 23:22:25 -0000 Subject: [GHC] #11197: Overeager deferred type errors In-Reply-To: <047.311058030fc6bc2d09ef05760e42135c@haskell.org> References: <047.311058030fc6bc2d09ef05760e42135c@haskell.org> Message-ID: <062.5203febe66de1eeb380c0cf9c35bd642@haskell.org> #11197: Overeager deferred type errors -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 7.11 checker) | Keywords: TypeInType, Resolution: | DeferredErrors Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 22 01:10:45 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 May 2018 01:10:45 -0000 Subject: [GHC] #15164: Slowdown in ghc compile times from GHC 8.0.2 to GHC 8.2.1 when doing Called arity analysis In-Reply-To: <046.d99bd58e6ad83ef24f9a7879b45c43ac@haskell.org> References: <046.d99bd58e6ad83ef24f9a7879b45c43ac@haskell.org> Message-ID: <061.0997d7348f74dad1ad87f9d11fc43755@haskell.org> #15164: Slowdown in ghc compile times from GHC 8.0.2 to GHC 8.2.1 when doing Called arity analysis -------------------------------------+------------------------------------- Reporter: flip101 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Compile-time | Test Case: performance bug | perf/compiler/T15164 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): JFTR, there is a patch that fixes most of it at Phab:D4718, I am just waiting for Harbormaster to finish and tell me the new perf test numbers, then I will push it to master. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 22 01:35:25 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 May 2018 01:35:25 -0000 Subject: [GHC] #15173: Tests are failing with segfaults under CircleCI Message-ID: <046.ba1f8d097fee9d45bfa33d6a3fa79280@haskell.org> #15173: Tests are failing with segfaults under CircleCI -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.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 seems something has regressed recently as `master` now fails to validate on CircleCI with some tests segfaulting. Namely, {{{ T10508_api T6145 T8628 T8639_api T10052 T7478 parseTree comments listcomps literals T11430 dynCompileExpr parsed }}} all in the `normal` way. This may be due to the SRT rework. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 22 01:35:36 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 May 2018 01:35:36 -0000 Subject: [GHC] #15173: Tests are failing with segfaults under CircleCI In-Reply-To: <046.ba1f8d097fee9d45bfa33d6a3fa79280@haskell.org> References: <046.ba1f8d097fee9d45bfa33d6a3fa79280@haskell.org> Message-ID: <061.15972d00235778c3cff92d441e969389@haskell.org> #15173: Tests are failing with segfaults under CircleCI -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => highest -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 22 05:41:40 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 May 2018 05:41:40 -0000 Subject: [GHC] #15174: got internal error when running a simple but computationally intensive loop Message-ID: <046.2d6bd673a2eb5f473f595f4e5636b491@haskell.org> #15174: got internal error when running a simple but computationally intensive loop -------------------------------+--------------------------------- Reporter: rgrover | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.2 Keywords: | Operating System: Linux Architecture: ia64 | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------+--------------------------------- Got the following on the GHCi prompt: {{{ λ> main : internal error: Unable to commit 1048576 bytes of memory (GHC version 8.2.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) }}} The program being run: {{{#!hs gaussian mean sigma x = exp (-0.5 * (x - mean) ^ 2 / sigma ^ 2) / (sigma * sqrt (2 * pi)) integrate :: (Double -> Double) -> (Double, Double) -> Double -> Double integrate f (low, high) step = step * sum values where xs = [low, low+step .. high] values = f <$> xs main = print $ integrate (gaussian 100 10) (-1 * 1e5, 1e5) 0.001 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 22 07:01:44 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 May 2018 07:01:44 -0000 Subject: [GHC] #15174: got internal error when running a simple but computationally intensive loop In-Reply-To: <046.2d6bd673a2eb5f473f595f4e5636b491@haskell.org> References: <046.2d6bd673a2eb5f473f595f4e5636b491@haskell.org> Message-ID: <061.cfb3ce659a5fe41c08f0da71ac374c4e@haskell.org> #15174: got internal error when running a simple but computationally intensive loop ---------------------------------+------------------------------ Reporter: rgrover | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.2 Resolution: invalid | Keywords: Operating System: Linux | Architecture: ia64 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+------------------------------ Changes (by sighingnow): * status: new => closed * resolution: => invalid Comment: This isn't a bug. In ghci the program is compiled without fully optimization then list fusion rules doesn't fire. To fix this problem, you could pass extra optimization arguments to ghci: {{{ ghci -fobject-code -O2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 22 07:35:35 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 May 2018 07:35:35 -0000 Subject: [GHC] #15175: ghc: panic! (the 'impossible' happened) Message-ID: <048.878b0f4dc853207e744a4ed01c5bc85a@haskell.org> #15175: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: MADjestic | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hey guys, When following the installation instructions for [https://github.com /ivanperez-keera/SpaceInvaders/ SpaceInvaders], I am getting the following error: {{{ [13 of 14] Compiling ObjectBehavior ( src/ObjectBehavior.hs, dist/dist- sandbox-5c221c1a/build/spaceInvaders/spaceInvaders-tmp/ObjectBehavior.o ) src/ObjectBehavior.hs:20:1: warning: [-Wunused-imports] The qualified import of ‘System.Random’ is redundant except perhaps to import instances from ‘System.Random’ To import instances alone, use: import System.Random() src/ObjectBehavior.hs:23:1: warning: [-Wunused-imports] The import of ‘FRP.Yampa.Integration’ is redundant except perhaps to import instances from ‘FRP.Yampa.Integration’ To import instances alone, use: import FRP.Yampa.Integration() src/ObjectBehavior.hs:24:1: warning: [-Wunused-imports] The import of ‘FRP.Yampa.Utilities’ is redundant except perhaps to import instances from ‘FRP.Yampa.Utilities’ To import instances alone, use: import FRP.Yampa.Utilities() src/ObjectBehavior.hs:256:1: warning: [-Wmissing-signatures] Top-level binding with no type signature: gravity :: Vector2 Velocity src/ObjectBehavior.hs:263:1: warning: [-Wmissing-signatures] Top-level binding with no type signature: limit :: Ord a => a -> a -> a -> a src/ObjectBehavior.hs:265:1: warning: [-Wmissing-signatures] Top-level binding with no type signature: symLimit :: (Num t, Ord t) => t -> t -> t ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): StgCmmEnv: variable not found $dNum_aoyU local binds for: $s$fVectorSpaceVector2a_$s$fVectorSpaceVector2a_$cnorm $s$fVectorSpaceVector2a_$s$fVectorSpaceVector2a_$cp1VectorSpace $sintegralAux_rsVn integralAux_rsVo lvl_rsVp lvl1_rsVq lvl2_rsVr lvl3_rsVs $sintegralAux1_rsVt integralAux1_rsVu $sintegralAux2_rsVv integralAux2_rsVw lvl4_rsVx lvl5_rsVy lvl6_rsVz lvl7_rsVA lvl8_rsVB lvl9_rsVC lvl10_rsVD lvl11_rsVE lvl13_rsVM lvl14_rsVN lvl15_rsVO lvl16_rsVP lvl17_rsVQ lvl18_rsVR lvl19_rsVS lvl20_rsVT lvl21_rsVU lvl22_rsVV lvl23_rsVW lvl24_rsVX lvl25_rsVY dt_rsVZ dt1_rsW0 sf_rsW1 dt2_rsW2 lvl26_rsW3 lvl27_rsW4 lvl28_rsW5 lvl29_rsW6 lvl30_rsW7 lvl31_rsW8 lvl32_rsW9 lvl33_rsWa lvl34_rsWb lvl35_rsWc lvl36_rsWd lvl37_rsWe lvl38_rsWf lvl39_rsWg lvl40_rsWh lvl41_rsWi lvl42_rsWj lvl43_rsWk lvl44_rsWl lvl45_rsWm lvl46_rsWn lvl47_rsWo lvl48_rsWp lvl49_rsWq lvl50_rsWr lvl51_rsWs lvl52_rsWt lvl53_rsWu lvl54_rsWv lvl55_rsWw lvl56_rsWx lvl57_rsWy lvl58_rsWz lvl59_rsWA lvl60_rsWB lvl61_rsWC lvl62_rsWD lvl63_rsWE lvl64_rsWF $sintegralAux3_rsWG integralAux5_rsWH ll_rsWI Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} [https://github.com/ivanperez- keera/SpaceInvaders/issues/30#issuecomment-390638740 /original issue] {{{ $ ghc -V The Glorious Glasgow Haskell Compilation System, version 8.0.2 $ uname -a Linux nu 4.9.95-gentoo #1 SMP PREEMPT Wed May 9 22:32:30 CEST 2018 x86_64 Intel(R) Core(TM) i5-3230M CPU @ 2.60GHz GenuineIntel GNU/Linux }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 22 08:11:19 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 May 2018 08:11:19 -0000 Subject: [GHC] #11197: Overeager deferred type errors In-Reply-To: <047.311058030fc6bc2d09ef05760e42135c@haskell.org> References: <047.311058030fc6bc2d09ef05760e42135c@haskell.org> Message-ID: <062.eef91570763d25411ae8e52425fd17c0@haskell.org> #11197: Overeager deferred type errors -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 7.11 checker) | Keywords: TypeInType, Resolution: | DeferredErrors Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes, I'd be very interested to know how useful people find `-fdefer-type- errors`. But in fact it's extraordinarily simple to implement, albeit with some wrinkles around the edges like this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 22 08:22:35 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 May 2018 08:22:35 -0000 Subject: [GHC] #15175: ghc: panic! (the 'impossible' happened) In-Reply-To: <048.878b0f4dc853207e744a4ed01c5bc85a@haskell.org> References: <048.878b0f4dc853207e744a4ed01c5bc85a@haskell.org> Message-ID: <063.4abdfd5ff9999eace38af80094739620@haskell.org> #15175: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: MADjestic | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Can you (or someone) try with * `-dcore-lint` * GHC 8.4 We have fixed lots of bugs since 8.0! Thanks -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 22 08:23:12 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 May 2018 08:23:12 -0000 Subject: [GHC] #15168: GHC HEAD crashes on Windows 64 after the SRT overhaul (May 16, 2018 and newer) In-Reply-To: <044.deabc7a4c199713a6195b6ed0eaae792@haskell.org> References: <044.deabc7a4c199713a6195b6ed0eaae792@haskell.org> Message-ID: <059.3ee97947355bc2d3e9100997c125db56@haskell.org> #15168: GHC HEAD crashes on Windows 64 after the SRT overhaul (May 16, 2018 and newer) -------------------------------------+------------------------------------- Reporter: awson | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): Could someone who is able to repro this, please recompile stage 2 with `-debug`: {{{ cd ghc make re2 GhcDebugged=YES }}} and then see if the error message is different. This will tell us whether it's a case of some CAF being garbage collected when it shouldn't be, or something else. (incidentally the above workflow would be good to support in Hadrian, it's something I do a lot) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 22 08:31:27 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 May 2018 08:31:27 -0000 Subject: [GHC] #15168: GHC HEAD crashes on Windows 64 after the SRT overhaul (May 16, 2018 and newer) In-Reply-To: <044.deabc7a4c199713a6195b6ed0eaae792@haskell.org> References: <044.deabc7a4c199713a6195b6ed0eaae792@haskell.org> Message-ID: <059.4c08de8cded6c68465e6f8a49d753122@haskell.org> #15168: GHC HEAD crashes on Windows 64 after the SRT overhaul (May 16, 2018 and newer) -------------------------------------+------------------------------------- Reporter: awson | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): There's nothing Windows-specific in the GC'ing of CAFs that I'm aware of. There are no Windows-specific conditionals in the SRT code generation, nor in the garbage collector, so I'm mystified about how this is failing. The only wrinkle I know about is the old `COMPILING_WINDOWS_DLL` hacks that we had to support SRT references in another DLL: https://phabricator.haskell.org/diffusion/GHC/browse/master/rts/sm/Scav.c;bfc1fc2566944a455572303cbb2cbbf0c539c871$393-409 I removed that code, but it wasn't active in any case because we aren't doing shared libraries on Windows, and as far as I could tell it couldn't have worked anyway because the code generator had no support for generating these references (that part probably got lost earlier). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 22 09:18:48 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 May 2018 09:18:48 -0000 Subject: [GHC] #15155: How untagged pointers sneak into banged fields In-Reply-To: <048.7d229d504bd9df060a5294d6d9eccfdc@haskell.org> References: <048.7d229d504bd9df060a5294d6d9eccfdc@haskell.org> Message-ID: <063.7726eaedee0a5082c3823373aca40951@haskell.org> #15155: How untagged pointers sneak into banged fields -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 14677 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => CodeGen -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 22 09:19:12 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 May 2018 09:19:12 -0000 Subject: [GHC] #14677: Code generator does not correctly tag a pointer In-Reply-To: <046.7a1d900f9976c54932290e6492402f05@haskell.org> References: <046.7a1d900f9976c54932290e6492402f05@haskell.org> Message-ID: <061.5571ee300d0afbba1d04e958697a7b11@haskell.org> #14677: Code generator does not correctly tag a pointer -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 15155 | Blocking: 14626 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => CodeGen -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 22 09:19:32 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 May 2018 09:19:32 -0000 Subject: [GHC] #14626: No need to enter a scrutinised value In-Reply-To: <048.67c951c2aecb97b988badb4816dbe757@haskell.org> References: <048.67c951c2aecb97b988badb4816dbe757@haskell.org> Message-ID: <063.904a7874d80877e225c257473d8f6345@haskell.org> #14626: No need to enter a scrutinised value -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: heisenbug Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: performance, | CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 14677 | Blocking: Related Tickets: #13861 #14677 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: performance => performance, CodeGen -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 22 09:19:52 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 May 2018 09:19:52 -0000 Subject: [GHC] #14373: Introduce PTR-tagging for big constructor families In-Reply-To: <048.fd4e2364f8515bbd8b92613edf1e7763@haskell.org> References: <048.fd4e2364f8515bbd8b92613edf1e7763@haskell.org> Message-ID: <063.e5fbc5d680f234e4a552c3ecce0da7e0@haskell.org> #14373: Introduce PTR-tagging for big constructor families -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: heisenbug Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4267 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => CodeGen -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 22 09:21:00 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 May 2018 09:21:00 -0000 Subject: [GHC] #13861: Take more advantage of STG representation invariance (follows up #9291) In-Reply-To: <048.651e325a747e822318af666cede88e81@haskell.org> References: <048.651e325a747e822318af666cede88e81@haskell.org> Message-ID: <063.1c5d2150575592a939fba0b006a1c356@haskell.org> #13861: Take more advantage of STG representation invariance (follows up #9291) -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: heisenbug Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => CodeGen -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 22 09:23:50 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 May 2018 09:23:50 -0000 Subject: [GHC] #15168: GHC HEAD crashes on Windows 64 after the SRT overhaul (May 16, 2018 and newer) In-Reply-To: <044.deabc7a4c199713a6195b6ed0eaae792@haskell.org> References: <044.deabc7a4c199713a6195b6ed0eaae792@haskell.org> Message-ID: <059.8d429147029e6dc3189f44c8c8ce95a7@haskell.org> #15168: GHC HEAD crashes on Windows 64 after the SRT overhaul (May 16, 2018 and newer) -------------------------------------+------------------------------------- Reporter: awson | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by awson): Have done this for `main = putStrLn "Hello, world"`. With `-A` less than `8m` it segfaults, with `8m` and `9m` compiles successfully, from `10m` to `15m` spits `Evaluated a CAF that was GC'd!` internal error, on `16m` and above compiles successfully. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 22 09:27:07 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 May 2018 09:27:07 -0000 Subject: [GHC] #15168: GHC HEAD crashes on Windows 64 after the SRT overhaul (May 16, 2018 and newer) In-Reply-To: <044.deabc7a4c199713a6195b6ed0eaae792@haskell.org> References: <044.deabc7a4c199713a6195b6ed0eaae792@haskell.org> Message-ID: <059.a1e1eb25fffcdab74bef035c3c8c924e@haskell.org> #15168: GHC HEAD crashes on Windows 64 after the SRT overhaul (May 16, 2018 and newer) -------------------------------------+------------------------------------- Reporter: awson | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by awson): @simonmar Btw, did you see #15173? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 22 09:39:23 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 May 2018 09:39:23 -0000 Subject: [GHC] #15173: Tests are failing with segfaults under CircleCI In-Reply-To: <046.ba1f8d097fee9d45bfa33d6a3fa79280@haskell.org> References: <046.ba1f8d097fee9d45bfa33d6a3fa79280@haskell.org> Message-ID: <061.8a6a004a07cf61df2879005fa9defe6a@haskell.org> #15173: Tests are failing with segfaults under CircleCI -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * cc: simonmar (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 22 09:40:37 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 May 2018 09:40:37 -0000 Subject: [GHC] #15176: Superclass `Monad m =>` makes program run 100 times slower Message-ID: <046.1ae5a16457a25527a576b82200e29a09@haskell.org> #15176: Superclass `Monad m =>` makes program run 100 times slower -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 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: -------------------------------------+------------------------------------- Hi! I've just encountered a very bizarre error. === General description === The code: {{{ class LayersFoldableBuilder__ t (layers :: [Type]) m where buildLayersFold__ :: SomePtr -> m (Fold.Result t) -> m (Fold.Result t) instance Monad m => LayersFoldableBuilder__ t '[] m where buildLayersFold__ = \_ a -> a {-# INLINE buildLayersFold__ #-} instance ( MonadIO m , Storable.Storable (Layer.Cons l ()) , Layer.StorableLayer l m , LayerFoldableBuilder__ (EnabledLayer t l) t m l , LayersFoldableBuilder__ t ls m ) => LayersFoldableBuilder__ t (l ': ls) m where buildLayersFold__ = \ptr mr -> do let fs = buildLayersFold__ @t @ls ptr' ptr' = Ptr.plusPtr ptr $ Layer.byteSize @l layerBuild__ @(EnabledLayer t l) @t @m @l ptr $! fs mr {-# INLINE buildLayersFold__ #-} }}} This is a typeclass `LayersFoldableBuilder__` and ALL of its instances. Please note, that every instance has a `Monad m` or `MonadIO m` constraint. The program which uses this code heavily runs in 40ms. If we only add constraint `Monad m =>` to the class definition: {{{ class Monad m => LayersFoldableBuilder__ t (layers :: [Type]) m where buildLayersFold__ :: SomePtr -> m (Fold.Result t) -> m (Fold.Result t) }}} The program runs in 3.5s , which is almost 100 times slower. Unfortunatelly I do not have minimal example, but it is reproducible. It is a part of the Luna Language codebase: https://github.com/luna/luna- core/blob/60bf6130691c23e52b97b067b52becb8fdb0c72e/core/src/Data/Graph/Traversal/Scoped.hs#L102 it was introduced in the commit 60bf6130691c23e52b97b067b52becb8fdb0c72e on branch static-layers . However, building this is simple: stack bench luna-core . After invoking it we see the described results. === Why its important and what should we do to fix it === 1. I am writing this because I care about Haskell community. I want GHC and Haskell to be widely used. Right now, the only thing I hear from all companies around our company is that impredicative performance, even when following rules "how to write efficient code" is the biggest pain people have. Haskell is gathering attention - pure functional programming, immutability etc - are great. But it will not become a popular choice unless we care about predictive performance. 2. Such performance changes are unacceptable when thinking about Haskell and GHC as production ready systems. We need a clear way how to write high performance Haskell without the need to benchmark every part of our programs even when refactoring things. GHC has enough information to discover that we want high performance here and there (even by looking at INLINE pragmas) and should warn us about lack of optimization. We should also have a way to force GHC to apply optimizations in particular places - for example by explicit marking code to be always specialized during compilation, so GHC would never fall back to dict-passing in such places. Such possibility would solve MANY related problems and user fears. 3. The point 2 also applies to strictness. In my opinion, having more clear strictness resolution rules / tools is important. Right now the only way to know if strictness analysis did a good job and we are not constantly boxing / unboxing things is to read core, which is tedious and 99% of Haskell users do not even know how to do it (We've got 10 really, really good Haskellers here, 2 of them are capable of reading core, but not very fluently). I would love to chat more about these topics, because they are crucial for growing Haskell community and making Haskell more popular choice, which is waht we want, right? We don't want Haskell to be just a research project with "all its users being its authors" at the same time, am I === What happens in core === I inspected core and have found that indeed, after adding the constraint, GHC does not apply all optimizations to the definitions. To be honest, I completely don't understand it, because the code uses everywhere explicit `INLINE` pragma to be sure everything is optimized away in the compilation stage: {{{ -------------------------------------------------------------------------------- SLOW, without Monad m => -------------------------------------------------------------------------------- -- RHS size: {terms: 5, types: 12, coercions: 4, joins: 0/0} buildLayersFold__ [InlPrag=INLINE] :: forall t (layers :: [*]) (m :: * -> *). LayersFoldableBuilder__ t layers m => SomePtr -> m (Fold.Result t) -> m (Fold.Result t) [GblId[ClassOp], Arity=1, Caf=NoCafRefs, Str=, Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=1,unsat_ok=False,boring_ok=True) Tmpl= \ (@ t_ao0O) (@ (layers_ao0P :: [*])) (@ (m_ao0Q :: * -> *)) (v_B1 [Occ=Once] :: LayersFoldableBuilder__ t_ao0O layers_ao0P m_ao0Q) -> v_B1 `cast` (Data.Graph.Traversal.Scoped.N:LayersFoldableBuilder__[0] _N _N _N :: (LayersFoldableBuilder__ t_ao0O layers_ao0P m_ao0Q :: Constraint) ~R# (SomePtr -> m_ao0Q (Fold.Result t_ao0O) -> m_ao0Q (Fold.Result t_ao0O) :: *))}] buildLayersFold__ = \ (@ t_ao0O) (@ (layers_ao0P :: [*])) (@ (m_ao0Q :: * -> *)) (v_B1 :: LayersFoldableBuilder__ t_ao0O layers_ao0P m_ao0Q) -> v_B1 `cast` (Data.Graph.Traversal.Scoped.N:LayersFoldableBuilder__[0] _N _N _N :: (LayersFoldableBuilder__ t_ao0O layers_ao0P m_ao0Q :: Constraint) ~R# (SomePtr -> m_ao0Q (Fold.Result t_ao0O) -> m_ao0Q (Fold.Result t_ao0O) :: *)) -------------------------------------------------------------------------------- FAST, without Monad m => -------------------------------------------------------------------------------- -- RHS size: {terms: 8, types: 25, coercions: 0, joins: 0/0} Data.Graph.Traversal.Scoped.$p1LayersFoldableBuilder__ :: forall t (layers :: [*]) (m :: * -> *). LayersFoldableBuilder__ t layers m => Monad m [GblId[ClassOp], Arity=1, Caf=NoCafRefs, Str=, RULES: Built in rule for Data.Graph.Traversal.Scoped.$p1LayersFoldableBuilder__: "Class op $p1LayersFoldableBuilder__"] Data.Graph.Traversal.Scoped.$p1LayersFoldableBuilder__ = \ (@ t_ao0P) (@ (layers_ao0Q :: [*])) (@ (m_ao0R :: * -> *)) (v_B1 :: LayersFoldableBuilder__ t_ao0P layers_ao0Q m_ao0R) -> case v_B1 of v_B1 { Data.Graph.Traversal.Scoped.C:LayersFoldableBuilder__ v_B2 v_B3 -> v_B2 } -- RHS size: {terms: 8, types: 25, coercions: 0, joins: 0/0} buildLayersFold__ :: forall t (layers :: [*]) (m :: * -> *). LayersFoldableBuilder__ t layers m => SomePtr -> m (Fold.Result t) -> m (Fold.Result t) [GblId[ClassOp], Arity=1, Caf=NoCafRefs, Str=, RULES: Built in rule for buildLayersFold__: "Class op buildLayersFold__"] buildLayersFold__ = \ (@ t_ao0P) (@ (layers_ao0Q :: [*])) (@ (m_ao0R :: * -> *)) (v_B1 :: LayersFoldableBuilder__ t_ao0P layers_ao0Q m_ao0R) -> case v_B1 of v_B1 { Data.Graph.Traversal.Scoped.C:LayersFoldableBuilder__ v_B2 v_B3 -> v_B3 } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 22 09:43:57 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 May 2018 09:43:57 -0000 Subject: [GHC] #15173: Tests are failing with segfaults under CircleCI In-Reply-To: <046.ba1f8d097fee9d45bfa33d6a3fa79280@haskell.org> References: <046.ba1f8d097fee9d45bfa33d6a3fa79280@haskell.org> Message-ID: <061.f1ad69026c081014c443b5897e4a52e1@haskell.org> #15173: Tests are failing with segfaults under CircleCI -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): Spinning up a build to look into this. Strange that none of these failed in a normal validate, perhaps it's only exposed by the perf builds we're doing on CircleCI? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 22 09:49:17 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 May 2018 09:49:17 -0000 Subject: [GHC] #15168: GHC HEAD crashes on Windows 64 after the SRT overhaul (May 16, 2018 and newer) In-Reply-To: <044.deabc7a4c199713a6195b6ed0eaae792@haskell.org> References: <044.deabc7a4c199713a6195b6ed0eaae792@haskell.org> Message-ID: <059.2de9cc8073cd4b1c235b320cb8e9a1dd@haskell.org> #15168: GHC HEAD crashes on Windows 64 after the SRT overhaul (May 16, 2018 and newer) -------------------------------------+------------------------------------- Reporter: awson | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by awson): Forgot to add: mine GHC build is `perf` (fully optimized GHC executable). Perhaps @Phyx- uses different build options (hence, no segfaults)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 22 09:49:58 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 May 2018 09:49:58 -0000 Subject: [GHC] #14381: Consider making ghc-pkg fill in abi-depends based on depends In-Reply-To: <045.a757b4d974e51bd6ab6f6869ba65de4c@haskell.org> References: <045.a757b4d974e51bd6ab6f6869ba65de4c@haskell.org> Message-ID: <060.e205a281ba80ed31125aa16bb302de0d@haskell.org> #14381: Consider making ghc-pkg fill in abi-depends based on depends -------------------------------------+------------------------------------- Reporter: ezyang | Owner: tdammers Type: bug | Status: new Priority: highest | Milestone: 8.4.2 Component: ghc-pkg | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4159 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): OK, I have a patch incoming that should do the trick. One issue though is that there is a theoretical possibility of the same package database being mentioned multiple times; this would sabotage the "get packages below the current one in the stack" logic, because right now, two package databases are considered "the same" iff their locations are equal, and the "get packages below this one in the stack" logic consists of popping all package db's off the stack that are not the same as the "current" one. So if we have a stack like this one: {{{#!hs [ "foo/bar" , "baz/quux" , "foo/bar" , "pizza/olives" ] }}} ...and we're trying to get all the package databases below the second occurrence of "foo/bar", we would want to get just {{{ ["foo/bar", "pizza/olives"]}}}, but we will in fact get the entire stack. Question is whether this is ever going to be a problem in practice - I would assume that having the same package database in the stack more than once would pose all sorts of problems anyway. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 22 09:58:02 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 May 2018 09:58:02 -0000 Subject: [GHC] #15176: Superclass `Monad m =>` makes program run 100 times slower In-Reply-To: <046.1ae5a16457a25527a576b82200e29a09@haskell.org> References: <046.1ae5a16457a25527a576b82200e29a09@haskell.org> Message-ID: <061.26b767039b84c9594acef530233be08d@haskell.org> #15176: Superclass `Monad m =>` makes program run 100 times slower -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 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: | -------------------------------------+------------------------------------- Description changed by danilo2: Old description: > Hi! I've just encountered a very bizarre error. > > === General description === > > The code: > > {{{ > class LayersFoldableBuilder__ t (layers :: [Type]) m where > buildLayersFold__ :: SomePtr -> m (Fold.Result t) -> m (Fold.Result > t) > > instance Monad m => LayersFoldableBuilder__ t '[] m where > buildLayersFold__ = \_ a -> a > {-# INLINE buildLayersFold__ #-} > > instance ( MonadIO m > , Storable.Storable (Layer.Cons l ()) > , Layer.StorableLayer l m > , LayerFoldableBuilder__ (EnabledLayer t l) t m l > , LayersFoldableBuilder__ t ls m ) > => LayersFoldableBuilder__ t (l ': ls) m where > buildLayersFold__ = \ptr mr -> do > let fs = buildLayersFold__ @t @ls ptr' > ptr' = Ptr.plusPtr ptr $ Layer.byteSize @l > layerBuild__ @(EnabledLayer t l) @t @m @l ptr $! fs mr > {-# INLINE buildLayersFold__ #-} > }}} > > This is a typeclass `LayersFoldableBuilder__` and ALL of its instances. > Please note, that every instance has a `Monad m` or `MonadIO m` > constraint. The program which uses this code heavily runs in 40ms. If we > only add constraint `Monad m =>` to the class definition: > > {{{ > class Monad m => LayersFoldableBuilder__ t (layers :: [Type]) m where > buildLayersFold__ :: SomePtr -> m (Fold.Result t) -> m (Fold.Result > t) > }}} > > The program runs in 3.5s , which is almost 100 times slower. > > Unfortunatelly I do not have minimal example, but it is reproducible. It > is a part of the Luna Language codebase: https://github.com/luna/luna- > core/blob/60bf6130691c23e52b97b067b52becb8fdb0c72e/core/src/Data/Graph/Traversal/Scoped.hs#L102 > > it was introduced in the commit 60bf6130691c23e52b97b067b52becb8fdb0c72e > on branch static-layers . However, building this is simple: stack bench > luna-core . After invoking it we see the described results. > > === Why its important and what should we do to fix it === > > 1. I am writing this because I care about Haskell community. I want GHC > and Haskell to be widely used. Right now, the only thing I hear from all > companies around our company is that impredicative performance, even when > following rules "how to write efficient code" is the biggest pain people > have. Haskell is gathering attention - pure functional programming, > immutability etc - are great. But it will not become a popular choice > unless we care about predictive performance. > > 2. Such performance changes are unacceptable when thinking about Haskell > and GHC as production ready systems. We need a clear way how to write > high performance Haskell without the need to benchmark every part of our > programs even when refactoring things. GHC has enough information to > discover that we want high performance here and there (even by looking at > INLINE pragmas) and should warn us about lack of optimization. We should > also have a way to force GHC to apply optimizations in particular places > - for example by explicit marking code to be always specialized during > compilation, so GHC would never fall back to dict-passing in such places. > Such possibility would solve MANY related problems and user fears. > > 3. The point 2 also applies to strictness. In my opinion, having more > clear strictness resolution rules / tools is important. Right now the > only way to know if strictness analysis did a good job and we are not > constantly boxing / unboxing things is to read core, which is tedious and > 99% of Haskell users do not even know how to do it (We've got 10 really, > really good Haskellers here, 2 of them are capable of reading core, but > not very fluently). I would love to chat more about these topics, because > they are crucial for growing Haskell community and making Haskell more > popular choice, which is waht we want, right? We don't want Haskell to be > just a research project with "all its users being its authors" at the > same time, am I > > === What happens in core === > > I inspected core and have found that indeed, after adding the constraint, > GHC does not apply all optimizations to the definitions. To be honest, I > completely don't understand it, because the code uses everywhere explicit > `INLINE` pragma to be sure everything is optimized away in the > compilation stage: > > {{{ > -------------------------------------------------------------------------------- > SLOW, without Monad m => > -------------------------------------------------------------------------------- > > -- RHS size: {terms: 5, types: 12, coercions: 4, joins: 0/0} > buildLayersFold__ [InlPrag=INLINE] > :: forall t (layers :: [*]) (m :: * -> *). > LayersFoldableBuilder__ t layers m => > SomePtr -> m (Fold.Result t) -> m (Fold.Result t) > [GblId[ClassOp], > Arity=1, > Caf=NoCafRefs, > Str=, > Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, > WorkFree=True, Expandable=True, > Guidance=ALWAYS_IF(arity=1,unsat_ok=False,boring_ok=True) > Tmpl= \ (@ t_ao0O) > (@ (layers_ao0P :: [*])) > (@ (m_ao0Q :: * -> *)) > (v_B1 [Occ=Once] > :: LayersFoldableBuilder__ t_ao0O layers_ao0P m_ao0Q) > -> > v_B1 > `cast` > (Data.Graph.Traversal.Scoped.N:LayersFoldableBuilder__[0] > _N _N _N > :: (LayersFoldableBuilder__ > t_ao0O layers_ao0P m_ao0Q :: Constraint) > ~R# (SomePtr > -> m_ao0Q (Fold.Result t_ao0O) > -> m_ao0Q (Fold.Result t_ao0O) :: *))}] > buildLayersFold__ > = \ (@ t_ao0O) > (@ (layers_ao0P :: [*])) > (@ (m_ao0Q :: * -> *)) > (v_B1 :: LayersFoldableBuilder__ t_ao0O layers_ao0P m_ao0Q) -> > v_B1 > `cast` (Data.Graph.Traversal.Scoped.N:LayersFoldableBuilder__[0] > _N _N _N > :: (LayersFoldableBuilder__ > t_ao0O layers_ao0P m_ao0Q :: Constraint) > ~R# (SomePtr > -> m_ao0Q (Fold.Result t_ao0O) > -> m_ao0Q (Fold.Result t_ao0O) :: *)) > > > -------------------------------------------------------------------------------- > FAST, without Monad m => > -------------------------------------------------------------------------------- > > -- RHS size: {terms: 8, types: 25, coercions: 0, joins: 0/0} > Data.Graph.Traversal.Scoped.$p1LayersFoldableBuilder__ > :: forall t (layers :: [*]) (m :: * -> *). > LayersFoldableBuilder__ t layers m => > Monad m > [GblId[ClassOp], > Arity=1, > Caf=NoCafRefs, > Str=, > RULES: Built in rule for > Data.Graph.Traversal.Scoped.$p1LayersFoldableBuilder__: "Class op > $p1LayersFoldableBuilder__"] > Data.Graph.Traversal.Scoped.$p1LayersFoldableBuilder__ > = \ (@ t_ao0P) > (@ (layers_ao0Q :: [*])) > (@ (m_ao0R :: * -> *)) > (v_B1 :: LayersFoldableBuilder__ t_ao0P layers_ao0Q m_ao0R) -> > case v_B1 of v_B1 > { Data.Graph.Traversal.Scoped.C:LayersFoldableBuilder__ v_B2 > v_B3 -> > v_B2 > } > > -- RHS size: {terms: 8, types: 25, coercions: 0, joins: 0/0} > buildLayersFold__ > :: forall t (layers :: [*]) (m :: * -> *). > LayersFoldableBuilder__ t layers m => > SomePtr -> m (Fold.Result t) -> m (Fold.Result t) > [GblId[ClassOp], > Arity=1, > Caf=NoCafRefs, > Str=, > RULES: Built in rule for buildLayersFold__: "Class op > buildLayersFold__"] > buildLayersFold__ > = \ (@ t_ao0P) > (@ (layers_ao0Q :: [*])) > (@ (m_ao0R :: * -> *)) > (v_B1 :: LayersFoldableBuilder__ t_ao0P layers_ao0Q m_ao0R) -> > case v_B1 of v_B1 > { Data.Graph.Traversal.Scoped.C:LayersFoldableBuilder__ v_B2 > v_B3 -> > v_B3 > } > }}} New description: Hi! I've just encountered a very bizarre error. === General description === The code: {{{ class LayersFoldableBuilder__ t (layers :: [Type]) m where buildLayersFold__ :: SomePtr -> m (Fold.Result t) -> m (Fold.Result t) instance Monad m => LayersFoldableBuilder__ t '[] m where buildLayersFold__ = \_ a -> a {-# INLINE buildLayersFold__ #-} instance ( MonadIO m , Storable.Storable (Layer.Cons l ()) , Layer.StorableLayer l m , LayerFoldableBuilder__ (EnabledLayer t l) t m l , LayersFoldableBuilder__ t ls m ) => LayersFoldableBuilder__ t (l ': ls) m where buildLayersFold__ = \ptr mr -> do let fs = buildLayersFold__ @t @ls ptr' ptr' = Ptr.plusPtr ptr $ Layer.byteSize @l layerBuild__ @(EnabledLayer t l) @t @m @l ptr $! fs mr {-# INLINE buildLayersFold__ #-} }}} This is a typeclass `LayersFoldableBuilder__` and ALL of its instances. Please note, that every instance has a `Monad m` or `MonadIO m` constraint. The program which uses this code heavily runs in 40ms. If we only add constraint `Monad m =>` to the class definition: {{{ class Monad m => LayersFoldableBuilder__ t (layers :: [Type]) m where buildLayersFold__ :: SomePtr -> m (Fold.Result t) -> m (Fold.Result t) }}} The program runs in 3.5s , which is almost 100 times slower. Unfortunatelly I do not have minimal example, but it is reproducible. It is a part of the Luna Language codebase: https://github.com/luna/luna- core/blob/60bf6130691c23e52b97b067b52becb8fdb0c72e/core/src/Data/Graph/Traversal/Scoped.hs#L102 it was introduced in the commit 60bf6130691c23e52b97b067b52becb8fdb0c72e on branch static-layers . However, building this is simple: stack bench luna-core . After invoking it we see the described results. === Why its important and what should we do to fix it === 1. I am writing this because I care about Haskell community. I want GHC and Haskell to be widely used. Right now, the only thing I hear from all companies around our company is that impredicative performance, even when following rules "how to write efficient code" is the biggest pain people have. Haskell is gathering attention - pure functional programming, immutability etc - are great. But it will not become a popular choice unless we care about predictive performance. 2. Such performance changes are unacceptable when thinking about Haskell and GHC as production ready systems. We need a clear way how to write high performance Haskell without the need to benchmark every part of our programs even when refactoring things. GHC has enough information to discover that we want high performance here and there (even by looking at INLINE pragmas) and should warn us about lack of optimization. We should also have a way to force GHC to apply optimizations in particular places - for example by explicit marking code to be always specialized during compilation, so GHC would never fall back to dict-passing in such places. Such possibility would solve MANY related problems and user fears. 3. The point 2 also applies to strictness. In my opinion, having more clear strictness resolution rules / tools is important. Right now the only way to know if strictness analysis did a good job and we are not constantly boxing / unboxing things is to read core, which is tedious and 99% of Haskell users do not even know how to do it (We've got 10 really, really good Haskellers here, 2 of them are capable of reading core, but not very fluently). I would love to chat more about these topics, because they are crucial for growing Haskell community and making Haskell more popular choice, which is waht we want, right? We don't want Haskell to be just a research project with "all its users being its authors" at the same time, am I === What happens in core === I inspected core and have found that indeed, after adding the constraint, GHC does not apply all optimizations to the definitions. To be honest, I completely don't understand it, because the code uses everywhere explicit `INLINE` pragma to be sure everything is optimized away in the compilation stage: {{{ -------------------------------------------------------------------------------- SLOW, with Monad m => -------------------------------------------------------------------------------- -- RHS size: {terms: 5, types: 12, coercions: 4, joins: 0/0} buildLayersFold__ [InlPrag=INLINE] :: forall t (layers :: [*]) (m :: * -> *). LayersFoldableBuilder__ t layers m => SomePtr -> m (Fold.Result t) -> m (Fold.Result t) [GblId[ClassOp], Arity=1, Caf=NoCafRefs, Str=, Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=1,unsat_ok=False,boring_ok=True) Tmpl= \ (@ t_ao0O) (@ (layers_ao0P :: [*])) (@ (m_ao0Q :: * -> *)) (v_B1 [Occ=Once] :: LayersFoldableBuilder__ t_ao0O layers_ao0P m_ao0Q) -> v_B1 `cast` (Data.Graph.Traversal.Scoped.N:LayersFoldableBuilder__[0] _N _N _N :: (LayersFoldableBuilder__ t_ao0O layers_ao0P m_ao0Q :: Constraint) ~R# (SomePtr -> m_ao0Q (Fold.Result t_ao0O) -> m_ao0Q (Fold.Result t_ao0O) :: *))}] buildLayersFold__ = \ (@ t_ao0O) (@ (layers_ao0P :: [*])) (@ (m_ao0Q :: * -> *)) (v_B1 :: LayersFoldableBuilder__ t_ao0O layers_ao0P m_ao0Q) -> v_B1 `cast` (Data.Graph.Traversal.Scoped.N:LayersFoldableBuilder__[0] _N _N _N :: (LayersFoldableBuilder__ t_ao0O layers_ao0P m_ao0Q :: Constraint) ~R# (SomePtr -> m_ao0Q (Fold.Result t_ao0O) -> m_ao0Q (Fold.Result t_ao0O) :: *)) -------------------------------------------------------------------------------- FAST, without Monad m => -------------------------------------------------------------------------------- -- RHS size: {terms: 8, types: 25, coercions: 0, joins: 0/0} Data.Graph.Traversal.Scoped.$p1LayersFoldableBuilder__ :: forall t (layers :: [*]) (m :: * -> *). LayersFoldableBuilder__ t layers m => Monad m [GblId[ClassOp], Arity=1, Caf=NoCafRefs, Str=, RULES: Built in rule for Data.Graph.Traversal.Scoped.$p1LayersFoldableBuilder__: "Class op $p1LayersFoldableBuilder__"] Data.Graph.Traversal.Scoped.$p1LayersFoldableBuilder__ = \ (@ t_ao0P) (@ (layers_ao0Q :: [*])) (@ (m_ao0R :: * -> *)) (v_B1 :: LayersFoldableBuilder__ t_ao0P layers_ao0Q m_ao0R) -> case v_B1 of v_B1 { Data.Graph.Traversal.Scoped.C:LayersFoldableBuilder__ v_B2 v_B3 -> v_B2 } -- RHS size: {terms: 8, types: 25, coercions: 0, joins: 0/0} buildLayersFold__ :: forall t (layers :: [*]) (m :: * -> *). LayersFoldableBuilder__ t layers m => SomePtr -> m (Fold.Result t) -> m (Fold.Result t) [GblId[ClassOp], Arity=1, Caf=NoCafRefs, Str=, RULES: Built in rule for buildLayersFold__: "Class op buildLayersFold__"] buildLayersFold__ = \ (@ t_ao0P) (@ (layers_ao0Q :: [*])) (@ (m_ao0R :: * -> *)) (v_B1 :: LayersFoldableBuilder__ t_ao0P layers_ao0Q m_ao0R) -> case v_B1 of v_B1 { Data.Graph.Traversal.Scoped.C:LayersFoldableBuilder__ v_B2 v_B3 -> v_B3 } }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 22 10:01:24 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 May 2018 10:01:24 -0000 Subject: [GHC] #15024: ghc: please switch to llvm-toolchain-6.0 In-Reply-To: <052.f8dd93d53607fec0aa24cccf11d14e57@haskell.org> References: <052.f8dd93d53607fec0aa24cccf11d14e57@haskell.org> Message-ID: <067.aa2553805210d853548df71b69eae6dc@haskell.org> #15024: ghc: please switch to llvm-toolchain-6.0 -------------------------------------+------------------------------------- Reporter: LocutusOfBorg | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by LocutusOfBorg): Hello, llvm ping :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 22 10:25:56 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 May 2018 10:25:56 -0000 Subject: [GHC] #15168: GHC HEAD crashes on Windows 64 after the SRT overhaul (May 16, 2018 and newer) In-Reply-To: <044.deabc7a4c199713a6195b6ed0eaae792@haskell.org> References: <044.deabc7a4c199713a6195b6ed0eaae792@haskell.org> Message-ID: <059.4d8d6a55cb4de0a821de457661923d77@haskell.org> #15168: GHC HEAD crashes on Windows 64 after the SRT overhaul (May 16, 2018 and newer) -------------------------------------+------------------------------------- Reporter: awson | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Ah yes that would explain the difference. I was using the default validate build. I will try a perf build when I get home. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 22 10:33:24 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 May 2018 10:33:24 -0000 Subject: [GHC] #15173: Tests are failing with segfaults under CircleCI In-Reply-To: <046.ba1f8d097fee9d45bfa33d6a3fa79280@haskell.org> References: <046.ba1f8d097fee9d45bfa33d6a3fa79280@haskell.org> Message-ID: <061.6318f850d8cfdc8736c982f503721ccf@haskell.org> #15173: Tests are failing with segfaults under CircleCI -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): Can't repro with a quick build, trying to add `-O2` to `GhcLibHcOpts` and `GhcStage2HcOpts` now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 22 10:56:32 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 May 2018 10:56:32 -0000 Subject: [GHC] #15173: Tests are failing with segfaults under CircleCI In-Reply-To: <046.ba1f8d097fee9d45bfa33d6a3fa79280@haskell.org> References: <046.ba1f8d097fee9d45bfa33d6a3fa79280@haskell.org> Message-ID: <061.1765dfd7c8f4eb8ffb1086ea337b45e6@haskell.org> #15173: Tests are failing with segfaults under CircleCI -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): Ok, got a segfault. Debugging... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 22 11:04:36 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 May 2018 11:04:36 -0000 Subject: [GHC] #14890: Make Linux slow validate green In-Reply-To: <046.a107a76cbb0183d36ada5ee5738b1b26@haskell.org> References: <046.a107a76cbb0183d36ada5ee5738b1b26@haskell.org> Message-ID: <061.055ce91a3de45bbc2c17aebfc6334e6e@haskell.org> #14890: Make Linux slow validate green -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alpmestan Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D4546, D4636, Wiki Page: | D4712 -------------------------------------+------------------------------------- Comment (by alpmestan): Ben, I suppose we can now give a shot at enabling the slow validate scenario in our Circle CI config? We want to run it on a nightly basis right? Or per-commit? For reference, [https://circleci.com/gh/ghc/ghc/4420 a full slow validate] appears to take a little over 2 hours. We have to weight that against the usefulness of having per-commit (or per-merged-patch, I suppose) slow validate status. If I remember correctly, we were leaning towards nightly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 22 11:18:09 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 May 2018 11:18:09 -0000 Subject: [GHC] #15177: Faulty instance termination check, with PolyKinds and/or TypeInType Message-ID: <046.c24a808ae6f672394489dfaa7b18ebab@haskell.org> #15177: Faulty instance termination check, with PolyKinds and/or TypeInType -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- When checking the [http://downloads.haskell.org/~ghc/master/users- guide/glasgow_exts.html#instance-termination-rules Paterson conditions] for termination an instance declaration, we check for the number of "constructors and variables" in the instance head and constraints. '''Question''': Do we look at A. All the arguments, visible or invisible? B. Just the visible arguments? I think both will ensure termination, provided we are consistent. A current bug in GHC means that we are not consistent. In particular in `TcValidity.checkInstTermination` we see {{{ checkInstTermination tys theta = check_preds theta where ... head_size = sizeTypes tys ... check pred = case classifyPredType pred of ... -> check2 pred (sizeTypes $ filterOutInvisibleTypes (classTyCon cls) tys) }}} Notice the `filterOutInvisibleTypes` in the context predicate, but not for the `head_size`! I tried doing it both ways and fell into a swamp. Fails plan A: * `rebindable/T5908` has `instance (Category w, ...) => Monad (WriterT w m)`. With kind arguments this is actualy `instance (Category @(TYPE LiftedRep) w, ...) => Monad (WriterT w m)`, and now the predicate in the context and the head both ahve size 4. So under (B) this is OK but not under (A). * `deriving/should_compile/T11833` is similar * So is `overloadedrecflds/should_run/hasfieldrun02`. Fails plan B * `polykinds/T12718` has `instance Prelude.Num a => XNum a`, where `XNum` is poly-kinded. Under (A) this would be OK, but not under B. * `typecheck/should_compile/T14441` is tricky. Putting in explicit kinds we have {{{ type family Demote (k :: Type) :: Type -- Demote :: forall k -> Type type family DemoteX (a :: k) :: Demote k -- DemoteX :: forall k. k -> Demote k data Prox (a :: k) = P -- P :: forall k (a:k). Prox @k a type instance DemoteX P = P -- type instance DemoteX (Prox @k a) (P @k @a) -- = P @(Demote k) @(DemoteX @k a) }}} So the LHS has 2 visible constructors and variables, namely `DemoteX` and `P`. But the type-family applications in the RHS also each have two visible, e.g. `Demote` and `k` for `Demote k`. Confusingly, these applications are hidden inside the invisible argument of `P`; but we really must look at them to ensure termination. Aaargh. * `dependent/should_compile/T13910` is similar, but a lot more complicated. Currently, because of the bug, these all pass. But I think it should be possible to exploit the bug to defeat the termination check, so things are not good at all. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 22 11:26:44 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 May 2018 11:26:44 -0000 Subject: [GHC] #15177: Faulty instance termination check, with PolyKinds and/or TypeInType In-Reply-To: <046.c24a808ae6f672394489dfaa7b18ebab@haskell.org> References: <046.c24a808ae6f672394489dfaa7b18ebab@haskell.org> Message-ID: <061.052b1ca76ce0246ac53190cea362fe37@haskell.org> #15177: Faulty instance termination check, with PolyKinds and/or TypeInType -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > When checking the [http://downloads.haskell.org/~ghc/master/users- > guide/glasgow_exts.html#instance-termination-rules Paterson conditions] > for termination an instance declaration, we check for the number of > "constructors and variables" in the instance head and constraints. > '''Question''': Do we look at > A. All the arguments, visible or invisible? > B. Just the visible arguments? > > I think both will ensure termination, provided we are consistent. > > A current bug in GHC means that we are not consistent. In particular in > `TcValidity.checkInstTermination` we see > {{{ > checkInstTermination tys theta > = check_preds theta > where > ... > head_size = sizeTypes tys > > ... > check pred > = case classifyPredType pred of > ... > -> check2 pred (sizeTypes $ filterOutInvisibleTypes > (classTyCon cls) tys) > }}} > Notice the `filterOutInvisibleTypes` in the context predicate, but not > for the `head_size`! > > I tried doing it both ways and fell into a swamp. > > Fails plan A: > > * `rebindable/T5908` has `instance (Category w, ...) => Monad (WriterT w > m)`. With kind arguments this is actualy `instance (Category @(TYPE > LiftedRep) w, ...) => Monad (WriterT w m)`, and now the predicate in the > context and the head both ahve size 4. So under (B) this is OK but not > under (A). > * `deriving/should_compile/T11833` is similar > * So is `overloadedrecflds/should_run/hasfieldrun02`. > > Fails plan B > > * `polykinds/T12718` has `instance Prelude.Num a => XNum a`, where `XNum` > is poly-kinded. Under (A) this would be OK, but not under B. > > * `typecheck/should_compile/T14441` is tricky. Putting in explicit kinds > we have > {{{ > type family Demote (k :: Type) :: Type > -- Demote :: forall k -> Type > > type family DemoteX (a :: k) :: Demote k > -- DemoteX :: forall k. k -> Demote k > > data Prox (a :: k) = P > -- P :: forall k (a:k). Prox @k a > > type instance DemoteX P = P > -- type instance DemoteX (Prox @k a) (P @k @a) > -- = P @(Demote k) @(DemoteX @k a) > }}} > So the LHS has 2 visible constructors and variables, namely `DemoteX` > and `P`. But the type-family applications in the RHS also each have two > visible, e.g. `Demote` and `k` for `Demote k`. Confusingly, these > applications are hidden inside the invisible argument of `P`; but we > really must look at them to ensure termination. Aaargh. > > * `dependent/should_compile/T13910` is similar, but a lot more > complicated. > > Currently, because of the bug, these all pass. But I think it should be > possible to exploit the bug to defeat the termination check, so things > are not good at all. New description: When checking the [http://downloads.haskell.org/~ghc/master/users- guide/glasgow_exts.html#instance-termination-rules Paterson conditions] for termination an instance declaration, we check for the number of "constructors and variables" in the instance head and constraints. '''Question''': Do we look at A. All the arguments, visible or invisible? B. Just the visible arguments? I think both will ensure termination, provided we are consistent. A current bug in GHC means that we are not consistent. In particular in `TcValidity.checkInstTermination` we see {{{ checkInstTermination tys theta = check_preds theta where ... head_size = sizeTypes tys ... check pred = case classifyPredType pred of ... -> check2 pred (sizeTypes $ filterOutInvisibleTypes (classTyCon cls) tys) }}} Notice the `filterOutInvisibleTypes` in the context predicate, but not for the `head_size`! Moreover, `sizeTypes` itself does not do the `filterOutInvisibleTypes` when it finds a `TyConApp`. I tried doing it both ways and fell into a swamp. Fails plan A: * `rebindable/T5908` has `instance (Category w, ...) => Monad (WriterT w m)`. With kind arguments this is actualy `instance (Category @(TYPE LiftedRep) w, ...) => Monad (WriterT w m)`, and now the predicate in the context and the head both ahve size 4. So under (B) this is OK but not under (A). * `deriving/should_compile/T11833` is similar * So is `overloadedrecflds/should_run/hasfieldrun02`. Fails plan B * `polykinds/T12718` has `instance Prelude.Num a => XNum a`, where `XNum` is poly-kinded. Under (A) this would be OK, but not under B. * `typecheck/should_compile/T14441` is tricky. Putting in explicit kinds we have {{{ type family Demote (k :: Type) :: Type -- Demote :: forall k -> Type type family DemoteX (a :: k) :: Demote k -- DemoteX :: forall k. k -> Demote k data Prox (a :: k) = P -- P :: forall k (a:k). Prox @k a type instance DemoteX P = P -- type instance DemoteX (Prox @k a) (P @k @a) -- = P @(Demote k) @(DemoteX @k a) }}} So the LHS has 2 visible constructors and variables, namely `DemoteX` and `P`. But the type-family applications in the RHS also each have two visible, e.g. `Demote` and `k` for `Demote k`. Confusingly, these applications are hidden inside the invisible argument of `P`; but we really must look at them to ensure termination. Aaargh. * `dependent/should_compile/T13910` is similar, but a lot more complicated. Currently, because of the bug, these all pass. But I think it should be possible to exploit the bug to defeat the termination check, so things are not good at all. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 22 11:44:21 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 May 2018 11:44:21 -0000 Subject: [GHC] #15177: Faulty instance termination check, with PolyKinds and/or TypeInType In-Reply-To: <046.c24a808ae6f672394489dfaa7b18ebab@haskell.org> References: <046.c24a808ae6f672394489dfaa7b18ebab@haskell.org> Message-ID: <061.9c7698bb762013e477f800088faf4ff4@haskell.org> #15177: Faulty instance termination check, with PolyKinds and/or TypeInType -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > When checking the [http://downloads.haskell.org/~ghc/master/users- > guide/glasgow_exts.html#instance-termination-rules Paterson conditions] > for termination an instance declaration, we check for the number of > "constructors and variables" in the instance head and constraints. > '''Question''': Do we look at > A. All the arguments, visible or invisible? > B. Just the visible arguments? > > I think both will ensure termination, provided we are consistent. > > A current bug in GHC means that we are not consistent. In particular in > `TcValidity.checkInstTermination` we see > {{{ > checkInstTermination tys theta > = check_preds theta > where > ... > head_size = sizeTypes tys > > ... > check pred > = case classifyPredType pred of > ... > -> check2 pred (sizeTypes $ filterOutInvisibleTypes > (classTyCon cls) tys) > }}} > Notice the `filterOutInvisibleTypes` in the context predicate, but not > for the `head_size`! Moreover, `sizeTypes` itself does not do the > `filterOutInvisibleTypes` when it finds a `TyConApp`. > > I tried doing it both ways and fell into a swamp. > > Fails plan A: > > * `rebindable/T5908` has `instance (Category w, ...) => Monad (WriterT w > m)`. With kind arguments this is actualy `instance (Category @(TYPE > LiftedRep) w, ...) => Monad (WriterT w m)`, and now the predicate in the > context and the head both ahve size 4. So under (B) this is OK but not > under (A). > * `deriving/should_compile/T11833` is similar > * So is `overloadedrecflds/should_run/hasfieldrun02`. > > Fails plan B > > * `polykinds/T12718` has `instance Prelude.Num a => XNum a`, where `XNum` > is poly-kinded. Under (A) this would be OK, but not under B. > > * `typecheck/should_compile/T14441` is tricky. Putting in explicit kinds > we have > {{{ > type family Demote (k :: Type) :: Type > -- Demote :: forall k -> Type > > type family DemoteX (a :: k) :: Demote k > -- DemoteX :: forall k. k -> Demote k > > data Prox (a :: k) = P > -- P :: forall k (a:k). Prox @k a > > type instance DemoteX P = P > -- type instance DemoteX (Prox @k a) (P @k @a) > -- = P @(Demote k) @(DemoteX @k a) > }}} > So the LHS has 2 visible constructors and variables, namely `DemoteX` > and `P`. But the type-family applications in the RHS also each have two > visible, e.g. `Demote` and `k` for `Demote k`. Confusingly, these > applications are hidden inside the invisible argument of `P`; but we > really must look at them to ensure termination. Aaargh. > > * `dependent/should_compile/T13910` is similar, but a lot more > complicated. > > Currently, because of the bug, these all pass. But I think it should be > possible to exploit the bug to defeat the termination check, so things > are not good at all. New description: When checking the [http://downloads.haskell.org/~ghc/master/users- guide/glasgow_exts.html#instance-termination-rules Paterson conditions] for termination an instance declaration, we check for the number of "constructors and variables" in the instance head and constraints. '''Question''': Do we look at A. All the arguments, visible or invisible? B. Just the visible arguments? I think both will ensure termination, provided we are consistent. A current bug in GHC means that we are not consistent. In particular in `TcValidity.checkInstTermination` we see {{{ checkInstTermination tys theta = check_preds theta where ... head_size = sizeTypes tys ... check pred = case classifyPredType pred of ... -> check2 pred (sizeTypes $ filterOutInvisibleTypes (classTyCon cls) tys) }}} Notice the `filterOutInvisibleTypes` in the context predicate, but not for the `head_size`! Similarly in `sizePred` (which itself looks very ad hoc; used only for 'deriving'). Moreover, `sizeTypes` itself does not do the `filterOutInvisibleTypes` when it finds a `TyConApp`. Bottom line: GHC mostly uses Plan A, except for an inconsistent use of Plan B at top level of `checkInstTermination` and `sizePred`. I tried doing it both ways and fell into a swamp. Fails plan A: * `rebindable/T5908` has `instance (Category w, ...) => Monad (WriterT w m)`. With kind arguments this is actualy `instance (Category @(TYPE LiftedRep) w, ...) => Monad (WriterT w m)`, and now the predicate in the context and the head both ahve size 4. So under (B) this is OK but not under (A). * `deriving/should_compile/T11833` is similar * So is `overloadedrecflds/should_run/hasfieldrun02`. Fails plan B * `polykinds/T12718` has `instance Prelude.Num a => XNum a`, where `XNum` is poly-kinded. Under (A) this would be OK, but not under B. * `typecheck/should_compile/T14441` is tricky. Putting in explicit kinds we have {{{ type family Demote (k :: Type) :: Type -- Demote :: forall k -> Type type family DemoteX (a :: k) :: Demote k -- DemoteX :: forall k. k -> Demote k data Prox (a :: k) = P -- P :: forall k (a:k). Prox @k a type instance DemoteX P = P -- type instance DemoteX (Prox @k a) (P @k @a) -- = P @(Demote k) @(DemoteX @k a) }}} So the LHS has 2 visible constructors and variables, namely `DemoteX` and `P`. But the type-family applications in the RHS also each have two visible, e.g. `Demote` and `k` for `Demote k`. Confusingly, these applications are hidden inside the invisible argument of `P`; but we really must look at them to ensure termination. Aaargh. * `dependent/should_compile/T13910` is similar, but a lot more complicated. Currently, because of the bug, these all pass. But I think it should be possible to exploit the bug to defeat the termination check, so things are not good at all. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 22 12:10:16 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 May 2018 12:10:16 -0000 Subject: [GHC] #15175: ghc: panic! (the 'impossible' happened) In-Reply-To: <048.878b0f4dc853207e744a4ed01c5bc85a@haskell.org> References: <048.878b0f4dc853207e744a4ed01c5bc85a@haskell.org> Message-ID: <063.2fd8cb1291798ab904240b935ab14abb@haskell.org> #15175: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: MADjestic | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sighingnow): * Attachment "ObjectBehavior.hs" added. Minimal program that can trigger core lint error on ghc-head. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 22 12:12:09 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 May 2018 12:12:09 -0000 Subject: [GHC] #15175: ghc: panic! (the 'impossible' happened) In-Reply-To: <048.878b0f4dc853207e744a4ed01c5bc85a@haskell.org> References: <048.878b0f4dc853207e744a4ed01c5bc85a@haskell.org> Message-ID: <063.23dd304c887bc03ab7f735f0a074e457@haskell.org> #15175: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: MADjestic | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sighingnow): The code lint error message: {{{ λ inplace\bin\ghc-stage2.exe --make ObjectBehavior.hs -dcore-lint -fforce- recomp [1 of 1] Compiling ObjectBehavior ( ObjectBehavior.hs, ObjectBehavior.o ) *** Core Lint errors : in result of Desugar (before optimization) *** : warning: In the expression: $WPoint2 @ Double $dRealFloat_a2Zv (x_a1iF @ Double) (+ @ Double $dNum_a2Zy y0_a1iC (/ @ Double $dFractional_a2ZA (D# 0.0##) (D# 2.0##))) $dRealFloat_a2Zv :: RealFloat Double [LclId] is out of scope : warning: In the expression: + @ Double $dNum_a2Zy y0_a1iC (/ @ Double $dFractional_a2ZA (D# 0.0##) (D# 2.0##)) $dNum_a2Zy :: Num Double [LclId] is out of scope *** Offending Program *** }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 22 12:26:54 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 May 2018 12:26:54 -0000 Subject: [GHC] #15175: ghc: panic! (the 'impossible' happened) In-Reply-To: <048.878b0f4dc853207e744a4ed01c5bc85a@haskell.org> References: <048.878b0f4dc853207e744a4ed01c5bc85a@haskell.org> Message-ID: <063.191cb8d358d382625a794ea15db29796@haskell.org> #15175: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: MADjestic | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Arrows Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #5777, #13547 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => Arrows * os: Linux => Unknown/Multiple * architecture: x86_64 (amd64) => Unknown/Multiple * related: => #5777, #13547 Comment: Thanks, sighingnow. My suspicion is that this is a duplicate of #5777 or #13547, since: 1. This requires `proc`-notation 2. This involves a GADT (`Point2`) I'm not confident enough in this analysis to conclude it's an exact duplicate, but maybe someone more familiar with arrows than I can do so. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 22 12:27:20 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 May 2018 12:27:20 -0000 Subject: [GHC] #5777: core lint error with arrow notation and GADTs In-Reply-To: <045.ddc610a1c7376d3ac8e7cf64940c7d90@haskell.org> References: <045.ddc610a1c7376d3ac8e7cf64940c7d90@haskell.org> Message-ID: <060.fccffbd319d632c224ec881709ab6bc6@haskell.org> #5777: core lint error with arrow notation and GADTs -------------------------------------+------------------------------------- Reporter: benmos | Owner: ross Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.4.2 checker) | Keywords: arrows, Resolution: | GADTs, Arrows Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #13547, #15175 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #13547 => #13547, #15175 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 22 12:27:46 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 May 2018 12:27:46 -0000 Subject: [GHC] #13547: Lint error in arrows program In-Reply-To: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> References: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> Message-ID: <064.193ea632d7b87060171bcfb2a07ccc30@haskell.org> #13547: Lint error in arrows program -------------------------------------+------------------------------------- Reporter: cipher1024 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (CodeGen) | Resolution: | Keywords: Arrows Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #5777, #10158, | Differential Rev(s): #15175 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #5777, #10158 => #5777, #10158, #15175 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 22 12:34:51 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 May 2018 12:34:51 -0000 Subject: [GHC] #15178: Implement DerivingVia Message-ID: <050.e1bb998ddf8ec1616d3dc71e43dcc2db@haskell.org> #15178: Implement DerivingVia -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Keywords: deriving | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The `DerivingVia` GHC proposal [https://github.com/ghc-proposals/ghc- proposals/pull/120 has been accepted]. This ticket serves as a reminder to get the corresponding patch into GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 22 12:35:41 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 May 2018 12:35:41 -0000 Subject: [GHC] #15178: Implement DerivingVia In-Reply-To: <050.e1bb998ddf8ec1616d3dc71e43dcc2db@haskell.org> References: <050.e1bb998ddf8ec1616d3dc71e43dcc2db@haskell.org> Message-ID: <065.c9eeb6092c5c7271574e0a30967cf124@haskell.org> #15178: Implement DerivingVia -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4684 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * owner: (none) => RyanGlScott * differential: => Phab:D4684 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 22 12:35:55 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 May 2018 12:35:55 -0000 Subject: [GHC] #15178: Implement DerivingVia In-Reply-To: <050.e1bb998ddf8ec1616d3dc71e43dcc2db@haskell.org> References: <050.e1bb998ddf8ec1616d3dc71e43dcc2db@haskell.org> Message-ID: <065.0837927904bc794026f44e48348123a7@haskell.org> #15178: Implement DerivingVia -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: feature request | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4684 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 22 14:36:10 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 May 2018 14:36:10 -0000 Subject: [GHC] #14381: Consider making ghc-pkg fill in abi-depends based on depends In-Reply-To: <045.a757b4d974e51bd6ab6f6869ba65de4c@haskell.org> References: <045.a757b4d974e51bd6ab6f6869ba65de4c@haskell.org> Message-ID: <060.8a3d11217335f4375b888e9d159304bd@haskell.org> #14381: Consider making ghc-pkg fill in abi-depends based on depends -------------------------------------+------------------------------------- Reporter: ezyang | Owner: tdammers Type: bug | Status: new Priority: highest | Milestone: 8.4.2 Component: ghc-pkg | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4159 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): As discussed in person: this can produce a lot of warnings that may not be very useful in practice. `ghc-pkg` is essentially always doing the "right thing" here, overriding declared dependencies with inferred ones, and we are more confident on the inferred ones than the declared ones (the latter essentially being subject to human error). The way it works now, we will also see a lot of unnecessary warnings: when the declared and inferred dependencies agree, `ghc-pkg` will still do the overriding and issue a warning, but that warning will be pointless, because we aren't making any effective changes. Because of this, we will only raise this warning in debug mode, which should also take care of the now-failing tests. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 22 14:36:46 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 May 2018 14:36:46 -0000 Subject: [GHC] #15137: Install the "primitive" package on CI before running tests In-Reply-To: <043.133b68846e07c2a28062d962181dcdcc@haskell.org> References: <043.133b68846e07c2a28062d962181dcdcc@haskell.org> Message-ID: <058.94bd12563244b73b14090bbd7987d947@haskell.org> #15137: Install the "primitive" package on CI before running tests -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-index): I needed to run this test locally, so I installed `primitive`: {{{ ghc2(master)*$ cabal install --with-compiler=$(pwd)/inplace/bin/ghc-stage2 --package-db=$(pwd)/inplace/lib/package.conf.d primitive --allow-newer Resolving dependencies... Configuring primitive-0.6.3.0... Building primitive-0.6.3.0... Installed primitive-0.6.3.0 }}} and tried to run the test; unfortunately, it failed: {{{ [nix-shell:~/Projects/ghc2/testsuite]$ make TEST=T15038 make -C ./tests all make[1]: Entering directory '/home/int- index/Projects/ghc2/testsuite/tests' PYTHON="python3" "python3" ../driver/runtests.py -e "ghc_compiler_always_flags='-dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output'" -e config.compiler_debugged=False -e ghc_with_native_codegen=1 -e config.have_vanilla=True -e config.have_dynamic=True -e config.have_profiling=False -e ghc_with_threaded_rts=1 -e ghc_with_dynamic_rts=1 -e config.have_interp=True -e config.unregisterised=False -e config.have_gdb=False -e config.have_readelf=True -e config.ghc_dynamic_by_default=False -e config.ghc_dynamic=True -e ghc_with_smp=1 -e ghc_with_llvm=0 -e windows=False -e darwin=False -e config.in_tree_compiler=True -e config.cleanup=True -e config.local=True --rootdir=. --config- file=../config/ghc -e 'config.confdir="../config"' -e 'config.platform="x86_64-unknown-linux"' -e 'config.os="linux"' -e 'config.arch="x86_64"' -e 'config.wordsize="64"' -e 'config.timeout=int() or config.timeout' -e 'config.exeext=""' -e 'config.top="/home/int- index/Projects/ghc2/testsuite"' --config 'compiler="/home/int- index/Projects/ghc2/inplace/test spaces/ghc-stage2"' --config 'ghc_pkg="/home/int-index/Projects/ghc2/inplace/test spaces/ghc-pkg"' --config 'haddock=' --config 'hp2ps="/home/int- index/Projects/ghc2/inplace/test spaces/hp2ps"' --config 'hpc="/home /int-index/Projects/ghc2/inplace/test spaces/hpc"' --config 'gs="gs"' --config 'timeout_prog="../timeout/install-inplace/bin/timeout"' -e "config.stage=2" --rootdir=../../libraries/array/tests --rootdir=../../libraries/base/tests --rootdir=../../libraries/binary/tests --rootdir=../../libraries/bytestring/tests --rootdir=../../libraries/containers/tests --rootdir=../../libraries/deepseq/tests --rootdir=../../libraries/directory/tests --rootdir=../../libraries/filepath/tests --rootdir=../../libraries/ghc- compact/tests --rootdir=../../libraries/ghc-heap/tests --rootdir=../../libraries/ghc-prim/tests --rootdir=../../libraries/haskeline/tests --rootdir=../../libraries/hpc/tests --rootdir=../../libraries/pretty/tests --rootdir=../../libraries/process/tests --rootdir=../../libraries/stm/tests --rootdir=../../libraries/template- haskell/tests --rootdir=../../libraries/text/tests --rootdir=../../libraries/unix/tests \ --only=T15038 \ \ \ \ \ \ locale: Cannot set LC_ALL to default locale: No such file or directory Timeout is 300 Found 403 .T files... Beginning test run at Tue May 22 17:32:43 2018 MSK ====> Scanning ./ado/all.T ====> Scanning ./annotations/should_compile/all.T ====> Scanning ./annotations/should_compile/T13818/all.T ====> Scanning ./annotations/should_compile/th/all.T ====> Scanning ./annotations/should_fail/all.T ====> Scanning ./annotations/should_run/all.T ====> Scanning ./array/should_run/all.T ====> Scanning ./arrows/should_compile/all.T ====> Scanning ./arrows/should_fail/all.T ====> Scanning ./arrows/should_run/all.T ====> Scanning ./backpack/cabal/T14304/all.T ====> Scanning ./backpack/cabal/bkpcabal01/all.T ====> Scanning ./backpack/cabal/bkpcabal02/all.T ====> Scanning ./backpack/cabal/bkpcabal03/all.T ====> Scanning ./backpack/cabal/bkpcabal04/all.T ====> Scanning ./backpack/cabal/bkpcabal05/all.T ====> Scanning ./backpack/cabal/bkpcabal06/all.T ====> Scanning ./backpack/cabal/bkpcabal07/all.T ====> Scanning ./backpack/reexport/all.T ====> Scanning ./backpack/should_compile/all.T ====> Scanning ./backpack/should_fail/all.T ====> Scanning ./backpack/should_run/all.T ====> Scanning ./boxy/all.T ====> Scanning ./cabal/all.T ====> Scanning ./cabal/T12485/all.T ====> Scanning ./cabal/T12733/all.T ====> Scanning ./cabal/cabal01/all.T ====> Scanning ./cabal/cabal03/all.T ====> Scanning ./cabal/cabal04/all.T ====> Scanning ./cabal/cabal05/all.T ====> Scanning ./cabal/cabal06/all.T ====> Scanning ./cabal/cabal08/all.T ====> Scanning ./cabal/cabal09/all.T ====> Scanning ./cabal/pkg02/all.T ====> Scanning ./cabal/sigcabal01/all.T ====> Scanning ./callarity/perf/all.T ====> Scanning ./callarity/should_run/all.T ====> Scanning ./callarity/unittest/all.T ====> Scanning ./cmm/should_run/all.T ====> Scanning ./codeGen/should_compile/all.T ====> Scanning ./codeGen/should_fail/all.T ====> Scanning ./codeGen/should_gen_asm/all.T ====> Scanning ./codeGen/should_run/all.T ====> Scanning ./codeGen/should_run/T15038/all.T ====> Scanning ./concurrent/T13615/all.T ====> Scanning ./concurrent/T2317/all.T ====> Scanning ./concurrent/prog001/all.T ====> Scanning ./concurrent/prog002/all.T ====> Scanning ./concurrent/prog003/all.T ====> Scanning ./concurrent/should_run/all.T ====> Scanning ./cpranal/should_compile/all.T ====> Scanning ./cpranal/should_run/all.T ====> Scanning ./cps/all.T ====> Scanning ./deSugar/should_compile/all.T ====> Scanning ./deSugar/should_fail/all.T ====> Scanning ./deSugar/should_run/all.T ====> Scanning ./dependent/ghci/all.T ====> Scanning ./dependent/should_compile/all.T ====> Scanning ./dependent/should_fail/all.T ====> Scanning ./dependent/should_run/all.T ====> Scanning ./deriving/perf/all.T ====> Scanning ./deriving/should_compile/all.T ====> Scanning ./deriving/should_fail/all.T ====> Scanning ./deriving/should_run/all.T ====> Scanning ./determinism/T13807/all.T ====> Scanning ./determinism/determ001/all.T ====> Scanning ./determinism/determ002/all.T ====> Scanning ./determinism/determ003/all.T ====> Scanning ./determinism/determ004/all.T ====> Scanning ./determinism/determ005/all.T ====> Scanning ./determinism/determ006/all.T ====> Scanning ./determinism/determ007/all.T ====> Scanning ./determinism/determ008/all.T ====> Scanning ./determinism/determ009/all.T ====> Scanning ./determinism/determ010/all.T ====> Scanning ./determinism/determ011/all.T ====> Scanning ./determinism/determ012/all.T ====> Scanning ./determinism/determ013/all.T ====> Scanning ./determinism/determ014/all.T ====> Scanning ./determinism/determ015/all.T ====> Scanning ./determinism/determ016/all.T ====> Scanning ./determinism/determ017/all.T ====> Scanning ./determinism/determ018/all.T ====> Scanning ./determinism/determ019/all.T ====> Scanning ./determinism/determ021/all.T ====> Scanning ./determinism/determ022/all.T ====> Scanning ./dph/classes/dph-classes.T ====> Scanning ./dph/diophantine/dph-diophantine.T ====> Scanning ./dph/dotp/dph-dotp.T ====> Scanning ./dph/enumfromto/dph-enumfromto.T ====> Scanning ./dph/modules/dph-modules.T ====> Scanning ./dph/nbody/dph-nbody.T ====> Scanning ./dph/primespj/dph-primespj.T ====> Scanning ./dph/quickhull/dph-quickhull.T ====> Scanning ./dph/smvm/dph-smvm.T ====> Scanning ./dph/sumnats/dph-sumnats.T ====> Scanning ./dph/words/dph-words.T ====> Scanning ./driver/all.T ====> Scanning ./driver/T12062/all.T ====> Scanning ./driver/T13392/all.T ====> Scanning ./driver/T13710/all.T ====> Scanning ./driver/T1372/all.T ====> Scanning ./driver/T13803/all.T ====> Scanning ./driver/T13914/all.T ====> Scanning ./driver/T14075/all.T ====> Scanning ./driver/T1959/test.T ====> Scanning ./driver/T3007/all.T ====> Scanning ./driver/T437/all.T ====> Scanning ./driver/T5147/all.T ====> Scanning ./driver/T7373/all.T ====> Scanning ./driver/T7835/all.T ====> Scanning ./driver/T8184/all.T ====> Scanning ./driver/T8526/T8526.T ====> Scanning ./driver/T8602/T8602.T ====> Scanning ./driver/T9562/all.T ====> Scanning ./driver/bug1677/all.T ====> Scanning ./driver/conflicting_flags/test.T ====> Scanning ./driver/dynamicToo/all.T ====> Scanning ./driver/dynamicToo/dynamicToo001/test.T ====> Scanning ./driver/dynamicToo/dynamicToo002/test.T ====> Scanning ./driver/dynamicToo/dynamicToo004/test.T ====> Scanning ./driver/dynamicToo/dynamicToo005/test.T ====> Scanning ./driver/dynamic_flags_001/all.T ====> Scanning ./driver/dynamic_flags_002/all.T ====> Scanning ./driver/linkwhole/all.T ====> Scanning ./driver/objc/all.T ====> Scanning ./driver/recomp001/all.T ====> Scanning ./driver/recomp002/all.T ====> Scanning ./driver/recomp003/all.T ====> Scanning ./driver/recomp004/all.T ====> Scanning ./driver/recomp005/all.T ====> Scanning ./driver/recomp006/all.T ====> Scanning ./driver/recomp007/all.T ====> Scanning ./driver/recomp008/all.T ====> Scanning ./driver/recomp009/all.T ====> Scanning ./driver/recomp010/all.T ====> Scanning ./driver/recomp011/all.T ====> Scanning ./driver/recomp012/all.T ====> Scanning ./driver/recomp013/all.T ====> Scanning ./driver/recomp015/all.T ====> Scanning ./driver/recomp016/all.T ====> Scanning ./driver/recomp017/all.T ====> Scanning ./driver/retc001/all.T ====> Scanning ./driver/retc002/all.T ====> Scanning ./driver/retc003/all.T ====> Scanning ./driver/should_fail/all.T ====> Scanning ./dynlibs/all.T ====> Scanning ./ffi/should_compile/all.T ====> Scanning ./ffi/should_fail/all.T ====> Scanning ./ffi/should_run/all.T ====> Scanning ./gadt/all.T ====> Scanning ./generics/all.T ====> Scanning ./generics/GEq/test.T ====> Scanning ./generics/GFunctor/test.T ====> Scanning ./generics/GMap/test.T ====> Scanning ./generics/GShow/test.T ====> Scanning ./generics/T10604/all.T ====> Scanning ./generics/Uniplate/test.T ====> Scanning ./ghc-api/all.T ====> Scanning ./ghc-api/T10052/all.T ====> Scanning ./ghc-api/T4891/all.T ====> Scanning ./ghc-api/T7478/all.T ====> Scanning ./ghc-api/annotations/all.T ====> Scanning ./ghc-api/annotations-literals/all.T ====> Scanning ./ghc-api/apirecomp001/all.T ====> Scanning ./ghc-api/dynCompileExpr/all.T ====> Scanning ./ghc-api/show-srcspan/all.T ====> Scanning ./ghc-e/should_fail/all.T ====> Scanning ./ghc-e/should_run/all.T ====> Scanning ./ghci/T11827/all.T ====> Scanning ./ghci/linking/all.T ====> Scanning ./ghci/linking/dyn/all.T ====> Scanning ./ghci/prog001/prog001.T ====> Scanning ./ghci/prog002/prog002.T ====> Scanning ./ghci/prog003/prog003.T ====> Scanning ./ghci/prog004/prog004.T ====> Scanning ./ghci/prog005/prog005.T ====> Scanning ./ghci/prog006/prog006.T ====> Scanning ./ghci/prog007/prog007.T ====> Scanning ./ghci/prog008/prog008.T ====> Scanning ./ghci/prog009/ghci.prog009.T ====> Scanning ./ghci/prog010/all.T ====> Scanning ./ghci/prog011/prog011.T ====> Scanning ./ghci/prog012/all.T ====> Scanning ./ghci/prog013/prog013.T ====> Scanning ./ghci/prog014/prog014.T ====> Scanning ./ghci/prog015/prog015.T ====> Scanning ./ghci/prog016/prog016.T ====> Scanning ./ghci/prog017/prog017.T ====> Scanning ./ghci/scripts/all.T ====> Scanning ./ghci/should_fail/all.T ====> Scanning ./ghci/should_run/all.T ====> Scanning ./ghci.debugger/scripts/all.T ====> Scanning ./ghci.debugger/scripts/break022/all.T ====> Scanning ./ghci.debugger/scripts/break023/all.T ====> Scanning ./haddock/haddock_examples/test.T ====> Scanning ./haddock/should_compile_flag_haddock/all.T ====> Scanning ./haddock/should_compile_flag_nohaddock/all.T ====> Scanning ./haddock/should_compile_noflag_haddock/all.T ====> Scanning ./haddock/should_compile_noflag_nohaddock/all.T ====> Scanning ./haddock/should_fail_flag_haddock/all.T ====> Scanning ./hpc/all.T ====> Scanning ./hsc2hs/all.T ====> Scanning ./indexed-types/should_compile/all.T ====> Scanning ./indexed-types/should_compile/T13092b/all.T ====> Scanning ./indexed-types/should_fail/all.T ====> Scanning ./indexed-types/should_fail/T13092/all.T ====> Scanning ./indexed-types/should_fail/T13092c/all.T ====> Scanning ./indexed-types/should_fail/T13102/all.T ====> Scanning ./indexed-types/should_run/all.T ====> Scanning ./layout/all.T ====> Scanning ./lib/integer/all.T ====> Scanning ./llvm/should_compile/all.T ====> Scanning ./llvm/should_run/subsections_via_symbols/all.T ====> Scanning ./mdo/should_compile/all.T ====> Scanning ./mdo/should_fail/all.T ====> Scanning ./mdo/should_run/all.T ====> Scanning ./module/all.T ====> Scanning ./module/base01/all.T ====> Scanning ./module/mod175/all.T ====> Scanning ./monadfail/all.T ====> Scanning ./numeric/should_compile/all.T ====> Scanning ./numeric/should_run/all.T ====> Scanning ./overloadedlists/should_fail/all.T ====> Scanning ./overloadedlists/should_run/all.T ====> Scanning ./overloadedrecflds/ghci/all.T ====> Scanning ./overloadedrecflds/should_compile/all.T ====> Scanning ./overloadedrecflds/should_fail/all.T ====> Scanning ./overloadedrecflds/should_run/all.T ====> Scanning ./overloadedstrings/should_run/all.T ====> Scanning ./package/all.T ====> Scanning ./parser/prog001/test.T ====> Scanning ./parser/should_compile/all.T ====> Scanning ./parser/should_compile/T7476/all.T ====> Scanning ./parser/should_fail/all.T ====> Scanning ./parser/should_run/all.T ====> Scanning ./parser/unicode/all.T ====> Scanning ./partial-sigs/should_compile/all.T ====> Scanning ./partial-sigs/should_fail/all.T ====> Scanning ./partial-sigs/should_run/all.T ====> Scanning ./patsyn/should_compile/all.T ====> Scanning ./patsyn/should_compile/T13350/all.T ====> Scanning ./patsyn/should_fail/all.T ====> Scanning ./patsyn/should_run/all.T ====> Scanning ./perf/compiler/all.T ====> Scanning ./perf/haddock/all.T ====> Scanning ./perf/join_points/all.T ====> Scanning ./perf/should_run/all.T ====> Scanning ./perf/space_leaks/all.T ====> Scanning ./plugins/all.T ====> Scanning ./pmcheck/complete_sigs/all.T ====> Scanning ./pmcheck/should_compile/all.T ====> Scanning ./polykinds/all.T ====> Scanning ./primops/should_compile/all.T ====> Scanning ./primops/should_run/all.T ====> Scanning ./printer/all.T ====> Scanning ./profiling/should_compile/all.T ====> Scanning ./profiling/should_fail/all.T ====> Scanning ./profiling/should_run/all.T ====> Scanning ./programs/10queens/test.T ====> Scanning ./programs/Queens/test.T ====> Scanning ./programs/andre_monad/test.T ====> Scanning ./programs/andy_cherry/test.T ====> Scanning ./programs/barton-mangler-bug/test.T ====> Scanning ./programs/cholewo-eval/test.T ====> Scanning ./programs/cvh_unboxing/test.T ====> Scanning ./programs/fast2haskell/test.T ====> Scanning ./programs/fun_insts/test.T ====> Scanning ./programs/galois_raytrace/test.T ====> Scanning ./programs/hs-boot/all.T ====> Scanning ./programs/jl_defaults/test.T ====> Scanning ./programs/joao-circular/test.T ====> Scanning ./programs/jq_readsPrec/test.T ====> Scanning ./programs/jtod_circint/test.T ====> Scanning ./programs/jules_xref/test.T ====> Scanning ./programs/jules_xref2/test.T ====> Scanning ./programs/launchbury/test.T ====> Scanning ./programs/lennart_range/test.T ====> Scanning ./programs/lex/test.T ====> Scanning ./programs/life_space_leak/test.T ====> Scanning ./programs/maessen-hashtab/test.T ====> Scanning ./programs/north_array/test.T ====> Scanning ./programs/okeefe_neural/test.T ====> Scanning ./programs/record_upd/test.T ====> Scanning ./programs/rittri/test.T ====> Scanning ./programs/sanders_array/test.T ====> Scanning ./programs/seward-space-leak/test.T ====> Scanning ./programs/strict_anns/test.T ====> Scanning ./programs/thurston-modular-arith/test.T ====> Scanning ./quasiquotation/all.T ====> Scanning ./quasiquotation/T13863/all.T ====> Scanning ./quasiquotation/T4491/test.T ====> Scanning ./quasiquotation/qq001/test.T ====> Scanning ./quasiquotation/qq002/test.T ====> Scanning ./quasiquotation/qq003/test.T ====> Scanning ./quasiquotation/qq004/test.T ====> Scanning ./quasiquotation/qq005/test.T ====> Scanning ./quasiquotation/qq006/test.T ====> Scanning ./quasiquotation/qq007/test.T ====> Scanning ./quasiquotation/qq008/test.T ====> Scanning ./quasiquotation/qq009/test.T ====> Scanning ./quotes/all.T ====> Scanning ./quotes/TH_spliceViewPat/test.T ====> Scanning ./rebindable/all.T ====> Scanning ./regalloc/all.T ====> Scanning ./rename/prog001/test.T ====> Scanning ./rename/prog002/test.T ====> Scanning ./rename/prog003/test.T ====> Scanning ./rename/prog004/test.T ====> Scanning ./rename/prog005/test.T ====> Scanning ./rename/prog006/all.T ====> Scanning ./rename/should_compile/all.T ====> Scanning ./rename/should_compile/T3103/test.T ====> Scanning ./rename/should_fail/all.T ====> Scanning ./roles/should_compile/all.T ====> Scanning ./roles/should_fail/all.T ====> Scanning ./rts/all.T ====> Scanning ./rts/T10672/all.T ====> Scanning ./rts/T11223/all.T ====> Scanning ./rts/T12031/all.T ====> Scanning ./rts/T12771/all.T ====> Scanning ./rts/T13082/all.T ====> Scanning ./rts/T13287/all.T ====> Scanning ./rts/T14611/all.T ====> Scanning ./rts/T1791/all.T ====> Scanning ./rts/T5644/all.T ====> Scanning ./rts/T7289/all.T ====> Scanning ./rts/T8308/all.T ====> Scanning ./rts/T9579/all.T ====> Scanning ./rts/flags/all.T ====> Scanning ./runghc/all.T ====> Scanning ./safeHaskell/check/all.T ====> Scanning ./safeHaskell/check/pkg01/all.T ====> Scanning ./safeHaskell/flags/all.T ====> Scanning ./safeHaskell/ghci/all.T ====> Scanning ./safeHaskell/overlapping/all.T ====> Scanning ./safeHaskell/safeInfered/all.T ====> Scanning ./safeHaskell/safeLanguage/all.T ====> Scanning ./safeHaskell/unsafeLibs/all.T ====> Scanning ./showIface/all.T ====> Scanning ./simplCore/T9646/test.T ====> Scanning ./simplCore/prog001/test.T ====> Scanning ./simplCore/prog002/test.T ====> Scanning ./simplCore/prog003/test.T ====> Scanning ./simplCore/should_compile/all.T ====> Scanning ./simplCore/should_fail/all.T ====> Scanning ./simplCore/should_run/all.T ====> Scanning ./simplStg/should_compile/all.T ====> Scanning ./simplStg/should_run/all.T ====> Scanning ./stage1/all.T ====> Scanning ./stranal/should_compile/all.T ====> Scanning ./stranal/should_run/all.T ====> Scanning ./stranal/should_run/T8425/all.T ====> Scanning ./stranal/sigs/all.T ====> Scanning ./th/all.T ====> Scanning ./th/T2014/all.T ====> Scanning ./th/TH_import_loop/TH_import_loop.T ====> Scanning ./th/TH_linker/all.T ====> Scanning ./th/should_compile/T13949/all.T ====> Scanning ./th/should_compile/T8025/all.T ====> Scanning ./typecheck/T11824/all.T ====> Scanning ./typecheck/T12441/all.T ====> Scanning ./typecheck/T13168/all.T ====> Scanning ./typecheck/bug1465/all.T ====> Scanning ./typecheck/prog001/test.T ====> Scanning ./typecheck/prog002/test.T ====> Scanning ./typecheck/should_compile/all.T ====> Scanning ./typecheck/should_fail/all.T ====> Scanning ./typecheck/should_run/all.T ====> Scanning ./typecheck/testeq1/test.T ====> Scanning ./unboxedsums/all.T ====> Scanning ./unboxedsums/module/all.T ====> Scanning ./warnings/minimal/all.T ====> Scanning ./warnings/should_compile/all.T ====> Scanning ./warnings/should_compile/T10637/all.T ====> Scanning ./warnings/should_compile/T10890/all.T ====> Scanning ./warnings/should_compile/T13727/all.T ====> Scanning ./warnings/should_fail/all.T ====> Scanning ./wcompat-warnings/all.T ====> Scanning ../../libraries/array/tests/all.T ====> Scanning ../../libraries/base/tests/all.T ====> Scanning ../../libraries/base/tests/Concurrent/all.T ====> Scanning ../../libraries/base/tests/IO/all.T ====> Scanning ../../libraries/base/tests/IO/T12010/test.T ====> Scanning ../../libraries/base/tests/Numeric/all.T ====> Scanning ../../libraries/base/tests/System/all.T ====> Scanning ../../libraries/base/tests/Text.Printf/all.T ====> Scanning ../../libraries/ghc-compact/tests/all.T ====> Scanning ../../libraries/ghc-heap/tests/all.T ====> Scanning ../../libraries/hpc/tests/fork/test.T ====> Scanning ../../libraries/hpc/tests/function/test.T ====> Scanning ../../libraries/hpc/tests/function2/test.T ====> Scanning ../../libraries/hpc/tests/ghc_ghci/test.T ====> Scanning ../../libraries/hpc/tests/raytrace/test.T ====> Scanning ../../libraries/hpc/tests/raytrace/tixs/test.T ====> Scanning ../../libraries/hpc/tests/simple/test.T ====> Scanning ../../libraries/hpc/tests/simple/tixs/test.T ====> Scanning ../../libraries/process/tests/all.T ====> Scanning ../../libraries/process/tests/T9775/all.T ====> Scanning ../../libraries/stm/tests/all.T ====> Scanning ../../libraries/template-haskell/tests/all.T ====> Scanning ../../libraries/unix/tests/all.T ====> Scanning ../../libraries/unix/tests/libposix/all.T =====> T15038(normal) 1 of 1 [0, 0, 0] cd "./codeGen/should_run/T15038/T15038.run" && $MAKE -s --no-print- directory T15038 Wrong exit code for T15038()(expected 0 , actual 2 ) Stderr ( T15038 ): ghc-stage2: no input files Usage: For basic information, try the `--help' option. make[2]: *** [Makefile:7: T15038] Error 1 *** unexpected failure for T15038(normal) Unexpected results from: TEST="T15038" SUMMARY for test run started at Tue May 22 17:32:43 2018 MSK 0:00:02 spent to go through 1 total tests, which gave rise to 1 test cases, of which 0 were skipped 0 had missing libraries 0 expected passes 0 expected failures 0 caused framework failures 0 caused framework warnings 0 unexpected passes 1 unexpected failures 0 unexpected stat failures Unexpected failures: codeGen/should_run/T15038/T15038.run T15038 [bad exit code] (normal) make[1]: *** [../mk/test.mk:329: test] Error 1 make[1]: Leaving directory '/home/int-index/Projects/ghc2/testsuite/tests' make: *** [Makefile:20: all] Error 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 22 15:05:52 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 May 2018 15:05:52 -0000 Subject: [GHC] #10869: Option to dump preprocessed source In-Reply-To: <046.34bba2c2c1e4ccec0498d1f1e04c25f9@haskell.org> References: <046.34bba2c2c1e4ccec0498d1f1e04c25f9@haskell.org> Message-ID: <061.7039a8a0cdc31556bdcaa503672a8e31@haskell.org> #10869: Option to dump preprocessed source -------------------------------------+------------------------------------- Reporter: phischu | Owner: RolandSenn Type: feature request | Status: new Priority: low | Milestone: Component: Driver | Version: 7.10.2 Resolution: | Keywords: easy Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * owner: (none) => RolandSenn Comment: I'll try to implement this: * A new compiler flag `--ddump-preprocessed` will be defined and documented. * With the new flag set, GHC will generate the .hspp file with the same content as the one created with the GHC option `-E`. * Opposite to the `-E` processing, GHC will not stop, but continue its processing normally. * If you specify both `-E` and `--ddump-preprocessed`, there will be the same processing as with only the GHC option `-E`: GHC will stop after producing the .hspp file. No error/warning message will be issued. * A test case will be added. As usual, if you disagree, please do holler... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 22 15:21:14 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 May 2018 15:21:14 -0000 Subject: [GHC] #15173: Tests are failing with segfaults under CircleCI In-Reply-To: <046.ba1f8d097fee9d45bfa33d6a3fa79280@haskell.org> References: <046.ba1f8d097fee9d45bfa33d6a3fa79280@haskell.org> Message-ID: <061.28cb9f3c34bf411fddf9498e2871fa0e@haskell.org> #15173: Tests are failing with segfaults under CircleCI -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4721 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * differential: => Phab:D4721 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 22 15:21:46 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 May 2018 15:21:46 -0000 Subject: [GHC] #15168: GHC HEAD crashes on Windows 64 after the SRT overhaul (May 16, 2018 and newer) In-Reply-To: <044.deabc7a4c199713a6195b6ed0eaae792@haskell.org> References: <044.deabc7a4c199713a6195b6ed0eaae792@haskell.org> Message-ID: <059.5ca4db305a11379a595fbc2831d7a258@haskell.org> #15168: GHC HEAD crashes on Windows 64 after the SRT overhaul (May 16, 2018 and newer) -------------------------------------+------------------------------------- Reporter: awson | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4721 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * differential: => Phab:D4721 Comment: Found a bug, see Phab:D4721. Hopefully this will fix Windows too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 22 15:35:47 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 May 2018 15:35:47 -0000 Subject: [GHC] #15179: Unwinding info for stg_ap_v_info is wrong Message-ID: <046.8fd4224ffbd164208a65672323b41cb5@haskell.org> #15179: Unwinding info for stg_ap_v_info is wrong -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 (Debugging) | Keywords: | Operating System: Linux Architecture: | Type of failure: Debugging Unknown/Multiple | information is incorrect Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The `readelf --debug-dump=frames-interp` output for `stg_ap_v_info` is: {{{ 00000018 0000000000000034 00000000 FDE cie=00000000 pc=000000000000000f..000000000000021d LOC CFA rbp rsp ra 000000000000000f rbp+0 v+0 u c+0 0000000000000037 rbp+0 v+0 vexp c+0 0000000000000047 rbp+0 v+0 s c+0 }}} It's wrong because it unwinds to the same frame, see `cfa = rbp + 0`. I know the reason, I will put it in the comments below. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 22 16:02:12 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 May 2018 16:02:12 -0000 Subject: [GHC] #15179: Unwinding info for stg_ap_v_info is wrong In-Reply-To: <046.8fd4224ffbd164208a65672323b41cb5@haskell.org> References: <046.8fd4224ffbd164208a65672323b41cb5@haskell.org> Message-ID: <061.135014e2ad432f13eb743b1e91710829@haskell.org> #15179: Unwinding info for stg_ap_v_info is wrong -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 (Debugging) | Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Debugging | Unknown/Multiple information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): The beginning of `stg_ap_v_info` looks like this: {{{ INFO_TABLE_RET(stg_ap_v, RET_SMALL, W_ info_ptr, ) { W_ info; W_ arity; unwind Sp = Sp + WDS(1); IF_DEBUG(apply,foreign "C" debugBelch("stg_ap_v_ret... "); foreign "C" printClosure(R1 "ptr")); IF_DEBUG(sanity,foreign "C" checkStackFrame(Sp+WDS(1)"ptr")); again: if (GETTAG(R1)==1) { Sp_adj(1); jump %GET_ENTRY(R1-1) [R1]; } ... }}} This looks reasonable, and you'd expect the beginning to unwind to the next word on the stack based on the manual annotation here. The Parsed Cmm also looks reasonable: {{{ ==================== Parsed Cmm ==================== [section ""cstring" . c8_str" { c8_str: I8[] [115,116,103,95,97,112,95,118,95,114,101,116] }, stg_ap_v_ret() // [] { info_tbl: [(c13, label: stg_ap_v_info rep:tag:30 StackRep [])] stack_info: arg_space: 8 updfr_space: Just 8 } {offset c13: // c1 //tick src unwind Sp = Just Sp + 1 * 8; // CmmUnwind goto c4; // CmmBranch c4: // c1 if (R1 & ((1 << 3) - 1) == 1) goto c5; else goto c7; // CmmCondBranch c5: // c1 //tick src //tick src Sp = Sp + 1 * 8; // CmmAssign call (I64[R1 - 1])(R1) args: 8, res: 0, upd: 8; // CmmCall ... }}} and it survives in this form till the very end of the Cmm pipeline, that is into Optimised Cmm: {{{ ==================== Optimised Cmm ==================== stg_ap_v_ret() // [] { [(c13, stg_ap_v_info: const 0; const 30;)] } {offset c13: // c1 //tick src unwind Sp = Just Sp + 8; // CmmUnwind goto c4; // CmmBranch c4: // c1 if (R1 & 7 == 1) goto c5; else goto c7; // CmmCondBranch c5: // c1 //tick src //tick src Sp = Sp + 8; // CmmAssign call (I64[R1 - 1])(R1) args: 8, res: 0, upd: 8; // CmmCall ... }}} The Native code preserves the c13 label which is where we have our unwind info: {{{ ==================== Native code ==================== .section .text .align 8 .align 8 .loc 1 8 1 .quad 0 .quad 30 .globl stg_ap_v_info .type stg_ap_v_info, @object stg_ap_v_info: _c13: .loc 1 8 1 _n1b: jmp _c4 .Lc13_end: _c4: .loc 1 8 1 movq %rbx,%vI_n1d andl $7,%vI_n1d cmpq $1,%vI_n1d je _c5 jmp _c7 .Lc4_end: _c5: .loc 1 8 1 addq $8,%rbp jmp *-1(%rbx) .Lc5_end: ... ==================== Asm code ==================== .file 1 "AutoApply.cmm" .section .text .align 8 .align 8 .loc 1 8 1 .quad 0 .quad 30 .globl stg_ap_v_info .type stg_ap_v_info, @object stg_ap_v_info: _c13: .loc 1 8 1 _n1b: .Lc13_end: _c4: .loc 1 8 1 movq %rbx,%rax andl $7,%eax cmpq $1,%rax je _c5 .Lc4_end: _c7: .loc 1 8 1 andq $-8,%rbx movq (%rbx),%rax cmpl $58,-8(%rax) jb _u14 .Lc7_end: }}} Debug Infos keeps our unwind info attached to c13: {{{ ==================== Debug Infos ==================== proc c13 (stg_ap_v_info) src removed [{_n1b: Sp=Just Sp+8}] [blk c4 (_c4) src pos 0 [], blk c7 (_c7) src pos 1 [], blk u18 (_u18) src pos 2 [], blk u14 (_u14) src pos 4 [], blk u17 (_u17) src pos 5 [], blk u15 (_u15) src pos 35 [], blk u16 (_u16) src pos 36 [], blk c5 (_c5) src pos 34 [], blk cb (_cb) src pos 3 [{_n1f: MachSp=Just MachSp+8}, {_n1g: MachSp=Just MachSp}], blk cp (_cp) src pos 27 [] [blk ce (_ce) src pos 28 [], blk ck (_ck) src pos 29 [], blk cl (_cl) src pos 30 [], blk cm (_cm) src pos 31 [], blk cc (_cc) src pos 32 []], blk cG (_cG) src pos 20 [] [blk cs (_cs) src pos 21 [], blk ct (_ct) src pos 22 [], blk cu (_cu) src pos 23 [], blk cB (_cB) src pos 24 [], blk cC (_cC) src pos 25 [], blk cD (_cD) src pos 26 [], blk cq (_cq) src pos 18 [], blk co (_co) src pos 19 [], blk cO (_cO) src pos 16 []], }}} But c4 is the first label we generate the debug info for: {{{ ==================== Asm code ==================== .Lsection_info: .section .debug_info,"", at progbits _n1H: .long .Ln1H_end-_n1H-4 .short 3 .long .Lsection_abbrev .byte 8 .byte 1 .asciz "/tmp/ghc802745_0/ghc_1.cmm" .asciz "The Glorious Glasgow Haskell Compilation System 8.5.20180514" .long 24 .asciz "/data/users/bnitka/ghc-unwind-asm-2/" .quad stg_ap_v_info .quad .Lstg_ap_v_info_end .long .Lsection_line .Lstg_ap_v_info_die: .byte 2 .asciz "stg_ap_v_ret" .asciz "stg_ap_v_info" .byte 255 .quad stg_ap_v_info .quad .Lstg_ap_v_info_end .byte 1 .byte 156 .Lc4_die: .byte 5 .asciz "_c4" .quad _c4 .quad .Lc4_end .byte 6 .asciz "AutoApply.cmm" .long 8 .short 1 .long 95 .short 2 .byte 6 .asciz "AutoApply.cmm" .long 24 .short 8 .long 24 .short 33 .byte 6 .asciz "AutoApply.cmm" .long 25 .short 10 .long 25 .short 26 .byte 6 .asciz "AutoApply.cmm" .long 17 .short 35 .long 20 .short 6 .byte 6 .asciz "AutoApply.cmm" .long 18 .short 12 .long 18 .short 27 .byte 0 }}} Going back to the Debug Info's dump you can see that c13 has `"removed"` in it, which refers to the `dblPosition` field which keeps the relative position of the block in a procedure. Later when we see that `dblPosition` is `"removed"` we don't generate a debug info for it. `blockToDwarf` is where we decide not to use removed blocks. [0] But the block is clearly there in the Cmm and Asm output, so there's some mismatch here. The part of code that declares them missing is `cmmDebugLabels` [1]. It does so because the block only consists of "meta" instructions. One way to avoid this problem is to say that `unwind` is not a meta instruction. Another workaround is to add unwind info under `again:` label, that puts the `unwind` pseudo-instruction in the c4 block which has some real code. I'm speculating here, but I think the reason that c13 block didn't disappear in assembly is because we generate `.loc` from the tick. I don't know where that happens yet, so a pointer would be helpful. I don't know how to fix this in a robust way yet. [0] https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/nativeGen/Dwarf.hs$198-199 [1] https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/cmm/Debug.hs$235 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 22 16:17:57 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 May 2018 16:17:57 -0000 Subject: [GHC] #15176: Superclass `Monad m =>` makes program run 100 times slower In-Reply-To: <046.1ae5a16457a25527a576b82200e29a09@haskell.org> References: <046.1ae5a16457a25527a576b82200e29a09@haskell.org> Message-ID: <061.3c46021d557b28fb1f29091ee665f582@haskell.org> #15176: Superclass `Monad m =>` makes program run 100 times slower -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 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 simonpj): I agree that predictable performance is super-important. So we give a high priority to unexpected performance lossage. I'd love to know what is going on in your application, but I wonder if you or someone else can help characterise what is going on, and perhaps distil into a smaller test case? What I can say is that the difference between your two classes is the difference between {{{ newtype LayersFoldableBuilder__ t (layers :: [Type]) m = MkD (SomePtr -> m (Fold.Result t) -> m (Fold.Result t)) }}} and {{{ data LayersFoldableBuilder__ t (layers :: [Type]) m = MkD (Monad m) (SomePtr -> m (Fold.Result t) -> m (Fold.Result t)) }}} That is, without the superclass a `LayersFoldableBuilder__` dictionary is represented just by the `buildLayersFold__` function itself; when you add the superclass, it turns into a heap-allocated pair of that function and a `Monad m` dictionary. This might change perf slightly, but a factor of 100 is ridiculous. I have literally no idea why that is happening. The change is so egregious that profiling ought to lead you right to it. (Or use `-ticky` which is faster and less invasive.) You are using 8.4, right? Does it happen with 8.2? (Or is that hard to find out?) Also does it also happen if, instead of adding `Monad m =>` you add a dummy method to the class, like this {{{ class LayersFoldableBuilder__ t (layers :: [Type]) m where buildLayersFold__ :: SomePtr -> m (Fold.Result t) -> m (Fold.Result t) dummy :: t -> t }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 22 16:50:30 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 May 2018 16:50:30 -0000 Subject: [GHC] #15164: Slowdown in ghc compile times from GHC 8.0.2 to GHC 8.2.1 when doing Called arity analysis In-Reply-To: <046.d99bd58e6ad83ef24f9a7879b45c43ac@haskell.org> References: <046.d99bd58e6ad83ef24f9a7879b45c43ac@haskell.org> Message-ID: <061.59d31111ef2717149765232d5386f00c@haskell.org> #15164: Slowdown in ghc compile times from GHC 8.0.2 to GHC 8.2.1 when doing Called arity analysis -------------------------------------+------------------------------------- Reporter: flip101 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Compile-time | Test Case: performance bug | perf/compiler/T15164 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"db6085b84139f4454cebf34f887cb5560a4fbc7b/ghc" db6085b8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="db6085b84139f4454cebf34f887cb5560a4fbc7b" Improve performance of CallArity the hot path contained a call to v `elemUnVarSet` (neighbors g v) and creating the set of neighbors just to check if `v` is inside accounted for half the allocations of the test case of #15164. By introducing a non-allocating function `hasLoopAt` for this we shave off half the allocations. This brings the total cost of Call Arity down to 20% of time and 23% of allocations, according to a profiled run. Not amazing, but still much better. Differential Revision: https://phabricator.haskell.org/D4718 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 22 16:57:11 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 May 2018 16:57:11 -0000 Subject: [GHC] #15164: Slowdown in ghc compile times from GHC 8.0.2 to GHC 8.2.1 when doing Called arity analysis In-Reply-To: <046.d99bd58e6ad83ef24f9a7879b45c43ac@haskell.org> References: <046.d99bd58e6ad83ef24f9a7879b45c43ac@haskell.org> Message-ID: <061.ab9d8d5efa8d443a1f1a332b057d851a@haskell.org> #15164: Slowdown in ghc compile times from GHC 8.0.2 to GHC 8.2.1 when doing Called arity analysis -------------------------------------+------------------------------------- Reporter: flip101 | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Compile-time | Test Case: performance bug | perf/compiler/T15164 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => merge Comment: This should fix most of the cost of running Call Arity. The patch is small and self-contained, so maybe a good candidate for a merge into stable. Of course more could be done about the cost of running Call Arity, but not here and now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 22 17:23:40 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 May 2018 17:23:40 -0000 Subject: [GHC] #9980: TcS monad is too heavy In-Reply-To: <046.9f2f16945c1ea3d5dff728997ee3b117@haskell.org> References: <046.9f2f16945c1ea3d5dff728997ee3b117@haskell.org> Message-ID: <061.b44497864bf7510cfcbac31101e3669e@haskell.org> #9980: TcS monad is too heavy -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: | TypeCheckerPlugins Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by diatchki): I hand't seen this ticket until Adam updated it a couple of days ago. Is that still the plan? The main things I can think of that a plugin might want from `TcM` are: 1. access to variable "sort" (e.g., `isTouchableMetaVar`) 2. a way to lookup things in the environment so that a plugin can recognize the types it supposed to work with (e.g., a plugin might know that it wants to work on type `T` defined in module `X.Y.Z`, but it needs to lookup this type's `TyCon` so that it can recognize the type in a constraint). On the second point: it is probably better if a plugin looks up this information only once (on startup) and stores the info somewhere, rather than looking it up all the time. So we could probably change the plugin API to add some initialization in `TcM`, but then keep the actual plugin execution in `TcS`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 22 18:47:38 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 May 2018 18:47:38 -0000 Subject: [GHC] #9539: TQueue can lead to thread starvation In-Reply-To: <045.f4dc0af39dea75bc36dee0474a4ea69f@haskell.org> References: <045.f4dc0af39dea75bc36dee0474a4ea69f@haskell.org> Message-ID: <060.ceba8ac0f227583880c8cdf174384ef4@haskell.org> #9539: TQueue can lead to thread starvation -------------------------------------+------------------------------------- Reporter: jwlato | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.2 Resolution: | Keywords: stm Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: closed => new * resolution: fixed => Comment: I'm 90% confident this is not actually fixed. We now get good results from `atomically $ do {...; readTQueue q}`. Unfortunately, I believe the exact same problem will still occur as soon as we go a little further, with `atomically $ do {... ; !x <- readTQueue q; return x}`. I believe the only true solution is to base `TQueue` on a real-time queue rather than an amortized one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 22 18:53:07 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 May 2018 18:53:07 -0000 Subject: [GHC] #9539: TQueue can lead to thread starvation In-Reply-To: <045.f4dc0af39dea75bc36dee0474a4ea69f@haskell.org> References: <045.f4dc0af39dea75bc36dee0474a4ea69f@haskell.org> Message-ID: <060.ffe05a08b745569e59b4605464a41d6c@haskell.org> #9539: TQueue can lead to thread starvation -------------------------------------+------------------------------------- Reporter: jwlato | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.2 Resolution: | Keywords: stm Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 22 19:22:53 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 May 2018 19:22:53 -0000 Subject: [GHC] #9980: TcS monad is too heavy In-Reply-To: <046.9f2f16945c1ea3d5dff728997ee3b117@haskell.org> References: <046.9f2f16945c1ea3d5dff728997ee3b117@haskell.org> Message-ID: <061.0248d8dd8b5141cf9ba67b3d5949f842@haskell.org> #9980: TcS monad is too heavy -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: | TypeCheckerPlugins Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'd be delighted if someone wanted to make progress on this line. I don't have the capacity to drive it myself, but it seems like the right direction. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 22 20:28:36 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 May 2018 20:28:36 -0000 Subject: [GHC] #15137: Install the "primitive" package on CI before running tests In-Reply-To: <043.133b68846e07c2a28062d962181dcdcc@haskell.org> References: <043.133b68846e07c2a28062d962181dcdcc@haskell.org> Message-ID: <058.9bf3588c954fefbd9eb3a906fd1949db@haskell.org> #15137: Install the "primitive" package on CI before running tests -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): It looks to me like the failure in comment:2 is rather orthogonal to this ticket. Rather the failure is due to this test's rather peculiar use of `find`. Patch coming to fix this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 22 20:32:33 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 May 2018 20:32:33 -0000 Subject: [GHC] #15168: GHC HEAD crashes on Windows 64 after the SRT overhaul (May 16, 2018 and newer) In-Reply-To: <044.deabc7a4c199713a6195b6ed0eaae792@haskell.org> References: <044.deabc7a4c199713a6195b6ed0eaae792@haskell.org> Message-ID: <059.c901d36b2873e6b6e7412780dfb63674@haskell.org> #15168: GHC HEAD crashes on Windows 64 after the SRT overhaul (May 16, 2018 and newer) -------------------------------------+------------------------------------- Reporter: awson | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4721 Wiki Page: | -------------------------------------+------------------------------------- Comment (by awson): Have rebuilt with the patch. No problems so far. Great! Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 22 20:56:39 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 May 2018 20:56:39 -0000 Subject: [GHC] #14899: Significant compilation time regression between 8.4 and HEAD due to coverage checking In-Reply-To: <050.9e589019d6eb1fc4987004e5aa20a3e4@haskell.org> References: <050.9e589019d6eb1fc4987004e5aa20a3e4@haskell.org> Message-ID: <065.5d5f7a9e1d320b1e463e1d5f76aa1483@haskell.org> #14899: Significant compilation time regression between 8.4 and HEAD due to coverage checking -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Does this sound plausible? Yes, something like that looks plausible, except that I think the last line should be more like {{{ Δ' = Δ ∪ u_0 ≈ (y |> co) }}} (patterns `p` don't appear in expressions). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 22 21:13:01 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 May 2018 21:13:01 -0000 Subject: [GHC] #9539: TQueue can lead to thread starvation In-Reply-To: <045.f4dc0af39dea75bc36dee0474a4ea69f@haskell.org> References: <045.f4dc0af39dea75bc36dee0474a4ea69f@haskell.org> Message-ID: <060.26cd9419c898db0d8e099a7d9899c8c6@haskell.org> #9539: TQueue can lead to thread starvation -------------------------------------+------------------------------------- Reporter: jwlato | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.2 Resolution: | Keywords: stm Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Working through this some more, I think we need 1. A real-time queue, to prevent the starvation problem 2. That allows `N` reads or writes to occur without contention. The simple scheduled real-time queue Okasaki describes won't do the trick, because both reads and writes inspect and modify the schedule each time. We need something a bit more flexible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 22 21:14:05 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 May 2018 21:14:05 -0000 Subject: [GHC] #15142: GHC HEAD regression: tcTyVarDetails In-Reply-To: <050.e98a1ae073f44bf5c57814edebb43575@haskell.org> References: <050.e98a1ae073f44bf5c57814edebb43575@haskell.org> Message-ID: <065.5ede3524752e136e0107e42d74db749f@haskell.org> #15142: GHC HEAD regression: tcTyVarDetails -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: TypeInType, Resolution: | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Oh dear, there are lots of thigs wrong here. I looked at {{{ {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind class C (a :: Type) (b :: k) where type T b }}} * First, `C` has a CUSK. But does `T`? Well `hsCeclHasCusk` reports True for the class decl, without even looking at `T`. This seems wrong. * `C` has a CUSK, but in `class C (a :: Type) (b :: k)`, I'm not sore how we get to know that `k :: Type`. Yet, without that `C` would not ahve a CUSK. * `getInitialKinds` returns this very bogus kind for `T`: {{{ kcTyClGroup: initial kinds C :: forall k. * -> k -> Constraint T :: forall (k :: k_aWH[tau:1]) (co :: k_aWH[tau:1] GHC.Prim.~# *). (k |> {co_aWL}) -> * }}} * What is that `co` binder? It's created in the mysterious `kcLHsQTyVars` function, which does something very like `quantifyTyVars`, but by steam. It uses `tyCoVarsOfTypeWellScoped`, but neglects to filter out coercion variables; hence the bugos quantification over `co_aWL`. ------------------ I'm reluctant to reach for a quick fix here. It all looks very dodgy to me. The `getInitialKinds` function, which is the bit misbehaving here, should be very simple: * For CUSKs, the idea is that it's a ''complete, user-specified kind'', just like a top-level type signature for a term variable. II expect to do something very akin to `tcHsSigType`: that is, type-check the kind, solve any constraints that arise, and kind-generalise the result. It's made a bit trickier by the fact that instead of a `LHsSigType` like `forall a. a->a` we have some `LHsQTyVars` like `data T (a :: k) (b :: *)`. But it's basically all one kind signature, pretty much the same as `forall (a::k) (b::*). blah` * For non-CUSKs, we can safely simply make `T :: kappa`, without looking at the declaration at all! We can perhaps save ourselves a bit of fruitless unification by seeing that if its `data T (a :: ...) (b :: ...)` then we can make `T :: kappa1 -> kappa2 -> *`. But we don't have to look into those "..." parts; that's going to happen later. No `solveEqualities` for non-CUSKs. * Associated types should not be allowed to mess things up! They must be treated as CUSK-ish only if they are in fact complete. Fundamentally, the same rules should apply: every type variable should be annotated. But maybe we can make an exception for variables from the parent class, if the parent class has a CUSK. Eg {{{ class C (a :: *) where type F a (b :: * -> *) :: * }}} Here perhaps we can allow `a` not to be annotated in `F`'s defn because it comes from `C` which itself has a CUSK. The present code does not do this, and it's buggy as this ticket shows. Let's discuss. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 22 22:10:31 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 May 2018 22:10:31 -0000 Subject: [GHC] #14381: Consider making ghc-pkg fill in abi-depends based on depends In-Reply-To: <045.a757b4d974e51bd6ab6f6869ba65de4c@haskell.org> References: <045.a757b4d974e51bd6ab6f6869ba65de4c@haskell.org> Message-ID: <060.af3110cbe1d7e08ef3ea0c7742eee47b@haskell.org> #14381: Consider making ghc-pkg fill in abi-depends based on depends -------------------------------------+------------------------------------- Reporter: ezyang | Owner: tdammers Type: bug | Status: new Priority: highest | Milestone: 8.4.2 Component: ghc-pkg | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4159 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I have reverted the patch in comment:9 on `master` as the warning caused validation issues. That being said, we will ship it in 8.4.3 to allow distributions to drop their patches. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 22 23:24:04 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 May 2018 23:24:04 -0000 Subject: [GHC] #9539: TQueue can lead to thread starvation In-Reply-To: <045.f4dc0af39dea75bc36dee0474a4ea69f@haskell.org> References: <045.f4dc0af39dea75bc36dee0474a4ea69f@haskell.org> Message-ID: <060.891bb6b53bffb0d9342906687c4ff3ce@haskell.org> #9539: TQueue can lead to thread starvation -------------------------------------+------------------------------------- Reporter: jwlato | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.2 Resolution: | Keywords: stm Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Aha! We ''don't'' necessarily need a real-time queue, but we do need to use something more like a ''persistent'' queue. Why? If a transaction does queue maintenance work that was deferred before the transaction began (e.g., rotating the queue because it arrived in a poor state), we need that work to survive even if the transaction itself fails because the maintenance work goes on too long. The only way that can happen is through laziness: the transaction must be forcing ''pre-existing'' thunks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 23 00:26:23 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 May 2018 00:26:23 -0000 Subject: [GHC] #9539: TQueue can lead to thread starvation In-Reply-To: <045.f4dc0af39dea75bc36dee0474a4ea69f@haskell.org> References: <045.f4dc0af39dea75bc36dee0474a4ea69f@haskell.org> Message-ID: <060.ac2c8a1c5231385cadd89a7ed031750f@haskell.org> #9539: TQueue can lead to thread starvation -------------------------------------+------------------------------------- Reporter: jwlato | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.2 Resolution: | Keywords: stm Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Sorry to be thinking out loud so long... I suspect the trick is for the read end and the write end to each have an ''estimate'' of the queue balance. Start with the usual Okasaki concept: {{{#!hs data PlainQueue a = PlainQueue !(TVar Int) !(TVar [a]) !(TVar [a]) }}} where the `Int` is the difference in length between the front list (read end) and the rear list. We would rotate the queue when that counter goes to -1. But the `TVar Int` is a contention point. So let's try this: {{{#!hs data End a = End !Int [a] data Queue a = Queue { prev_len :: !(TVar Int) , front :: !(TVar (End a)) , rear :: !(TVar (End a))} }}} When the queue is rotated, the `prev_len` counter is set to the length of the queue. The front of the queue holds a count of how many items have been ''removed'' (read) since the last rotation, while the rear holds a count of how many items have been ''added''. When we've added half as many items as we had at the last rotation, or we've removed half as many as we had at the last rotation, we rotate the queue. (Ratios subject to further analysis). The idea is that we can be sure that the balance factor will be in a fixed range when we rotate, even though neither end can see the other. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 23 00:46:52 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 May 2018 00:46:52 -0000 Subject: [GHC] #15105: `typecheckModule` from GHC API crashes on MacOS for files with TH In-Reply-To: <050.a57b50b77df5fd7c6386ac1485c8460f@haskell.org> References: <050.a57b50b77df5fd7c6386ac1485c8460f@haskell.org> Message-ID: <065.b49a2a604fd09ce8319a117171c31ba0@haskell.org> #15105: `typecheckModule` from GHC API crashes on MacOS for files with TH ----------------------------------+---------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHC API | Version: 8.4.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+---------------------------------------- Changes (by lerkok): * cc: lerkok (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 23 01:32:39 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 May 2018 01:32:39 -0000 Subject: [GHC] #15105: `typecheckModule` from GHC API crashes on MacOS for files with TH In-Reply-To: <050.a57b50b77df5fd7c6386ac1485c8460f@haskell.org> References: <050.a57b50b77df5fd7c6386ac1485c8460f@haskell.org> Message-ID: <065.d6810ea102bc44f64a758036dbaf782a@haskell.org> #15105: `typecheckModule` from GHC API crashes on MacOS for files with TH ----------------------------------+---------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHC API | Version: 8.4.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+---------------------------------------- Comment (by bgamari): Any updates on this harpocrates? Judging by the haddock ticket it sounds like you are pretty close. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 23 01:37:50 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 May 2018 01:37:50 -0000 Subject: [GHC] #15167: DerivClause list is not populated for (TyConI (DataD ...)) In-Reply-To: <049.1da123fe6825387f79a8e9ada4e3ab34@haskell.org> References: <049.1da123fe6825387f79a8e9ada4e3ab34@haskell.org> Message-ID: <064.bcdf4b628b7090e75ad924e809ee71d5@haskell.org> #15167: DerivClause list is not populated for (TyConI (DataD ...)) -------------------------------------+------------------------------------- Reporter: 0xd34df00d | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Template Haskell | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Unfortunately I don't think we currently have a good way to get this information. When we are asked to reify the tycon the original Haskell AST (which would contain the `deriving` information) that we typechecked to produce the type is gone. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 23 01:41:28 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 May 2018 01:41:28 -0000 Subject: [GHC] #15105: `typecheckModule` from GHC API crashes on MacOS for files with TH In-Reply-To: <050.a57b50b77df5fd7c6386ac1485c8460f@haskell.org> References: <050.a57b50b77df5fd7c6386ac1485c8460f@haskell.org> Message-ID: <065.566230e1650ecde5986df3fb24ea7499@haskell.org> #15105: `typecheckModule` from GHC API crashes on MacOS for files with TH ----------------------------------+---------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHC API | Version: 8.4.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+---------------------------------------- Comment (by bgamari): On ​https://github.com/haskell/haddock/issues/767 harpocrates said, > Alright, I think I'm close to nailing this. I think there is something suspicious about the `HSinteger-gmp-1.0.2.0.o` file from GHC's `integer- gmp` lib folder. I think all that we need to do to fix this issue is remove this file. When I do that, everything starts working again. > > Note that the symbols provided by this object file are already in the static library of the same name. Furthermore, when I manually install GHC (after building from source), this troublesome file is not present. > > I'm obviously still investigating, but I figured I'd ask if anyone knows any reason `HSinteger-gmp-1.0.2.0.o` should not be deleted... This object is a monolithic relocatable object used by statically-linked GHCi. Are you seeing it being loaded? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 23 02:12:23 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 May 2018 02:12:23 -0000 Subject: [GHC] #14381: Consider making ghc-pkg fill in abi-depends based on depends In-Reply-To: <045.a757b4d974e51bd6ab6f6869ba65de4c@haskell.org> References: <045.a757b4d974e51bd6ab6f6869ba65de4c@haskell.org> Message-ID: <060.6291a394fc3f6c3fde726595e4fca8fd@haskell.org> #14381: Consider making ghc-pkg fill in abi-depends based on depends -------------------------------------+------------------------------------- Reporter: ezyang | Owner: tdammers Type: bug | Status: new Priority: highest | Milestone: 8.4.2 Component: ghc-pkg | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4159 Wiki Page: | -------------------------------------+------------------------------------- Comment (by juhpetersen): Thanks a lot this sounds good to me. Do you want to set the milestone to 8.4.3 then? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 23 02:25:38 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 May 2018 02:25:38 -0000 Subject: [GHC] #14381: Consider making ghc-pkg fill in abi-depends based on depends In-Reply-To: <045.a757b4d974e51bd6ab6f6869ba65de4c@haskell.org> References: <045.a757b4d974e51bd6ab6f6869ba65de4c@haskell.org> Message-ID: <060.32430b89563d5c74f3edb241ae98ed79@haskell.org> #14381: Consider making ghc-pkg fill in abi-depends based on depends -------------------------------------+------------------------------------- Reporter: ezyang | Owner: tdammers Type: bug | Status: new Priority: highest | Milestone: 8.4.3 Component: ghc-pkg | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4159 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.4.2 => 8.4.3 Comment: Indeed I do. Good catch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 23 13:51:39 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 May 2018 13:51:39 -0000 Subject: [GHC] #14492: Tiered memory allocation restricts available memory In-Reply-To: <044.e21e37476590d999c81ca942af908658@haskell.org> References: <044.e21e37476590d999c81ca942af908658@haskell.org> Message-ID: <059.d91ef8d3182dcae73678f959656771ee@haskell.org> #14492: Tiered memory allocation restricts available memory -------------------------------------+------------------------------------- Reporter: unode | Owner: bgamari Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: memory ulimit Operating System: Linux | Architecture: x86_64 Type of failure: Poor/confusing | (amd64) error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4215 Wiki Page: | -------------------------------------+------------------------------------- Comment (by luispedro): Just to ping everyone on this. We are still having to over allocate memory on our servers to work around this bug, while the simple 1-liner above (`*len -= *len/8`) would get us a 90% solution. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 23 14:11:26 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 May 2018 14:11:26 -0000 Subject: [GHC] #15163: non coercion variable in coVarKindsTypesRole In-Reply-To: <048.b3dbe8c60de34c10b2c3141afc368cad@haskell.org> References: <048.b3dbe8c60de34c10b2c3141afc368cad@haskell.org> Message-ID: <063.c4e3d52e7815d12b3b4d7405ef02b2bc@haskell.org> #15163: non coercion variable in coVarKindsTypesRole -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T14732 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"86bba7d519fb6050f78b7e3bac2b3f54273fd70e/ghc" 86bba7d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="86bba7d519fb6050f78b7e3bac2b3f54273fd70e" Add missing check to isReflCoVar_maybe isReflCoVar_maybe is called, by CoreLint, on all sorts of Vars (tyvars, term vars, coercion vars). But it was silently assuming that it was always called on a CoVar, and as a result could crash fatally. This is the immediate cause of the panic in Trac #15163. It's easy to fix. NB: this does not completely fix Trac #15163; more to come }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 23 14:11:26 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 May 2018 14:11:26 -0000 Subject: [GHC] #15163: non coercion variable in coVarKindsTypesRole In-Reply-To: <048.b3dbe8c60de34c10b2c3141afc368cad@haskell.org> References: <048.b3dbe8c60de34c10b2c3141afc368cad@haskell.org> Message-ID: <063.0635f9c97ae32a0066505e88bc84f23a@haskell.org> #15163: non coercion variable in coVarKindsTypesRole -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T14732 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"d191db48c43469ee1818887715bcbc5c0eb1d91f/ghc" d191db48/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d191db48c43469ee1818887715bcbc5c0eb1d91f" Don't expose strictness when sm_inline is False This is very much a corner case, but Trac #15163 showed that if you have a RULE like forall x. f (g x) = ..x.. and g = undefined, then the simplifier is likely to discard that 'x' argument. It is usually right to do so; but not here because then x is used on the right but not bound on the left. The fix is a narrow one, aimed at this rather pathalogical case. See Note [Do not expose strictness if sm_inline=False] in SimplUtils. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 23 14:11:55 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 May 2018 14:11:55 -0000 Subject: [GHC] #15122: GHC HEAD typechecker regression In-Reply-To: <046.6b6ee0b02b0ede932ee344925ca869d9@haskell.org> References: <046.6b6ee0b02b0ede932ee344925ca869d9@haskell.org> Message-ID: <061.0d112275e0ddb0d673a73463290158dd@haskell.org> #15122: GHC HEAD typechecker regression -------------------------------------+------------------------------------- Reporter: fmixing | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"a32c8f7514c8192fa064537fb93d5a5c224991a0/ghc" a32c8f75/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a32c8f7514c8192fa064537fb93d5a5c224991a0" Use dischargeFunEq consistently Trac #15122 turned out to be interesting. * Were calling dischargeFmv in three places. * In all three cases we dealt with the Given case separately. * In two of the three cases the Given code was right, (albeit duplicated). * In the third case (in TcCanonical.canCFunEqCan), we had ; case flav of Given -> return () -- nothing more to do. which was utterly wrong. The solution is easy: move the Given-case handling into dischargeFmv (now reenamed dischargeFunEq), and delete it from the call sites. Result: less code, easier to understand (dischargeFunEq handles all three cases, not just two out of three), and Trac #15122 is fixed. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 23 14:12:20 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 May 2018 14:12:20 -0000 Subject: [GHC] #15163: non coercion variable in coVarKindsTypesRole In-Reply-To: <048.b3dbe8c60de34c10b2c3141afc368cad@haskell.org> References: <048.b3dbe8c60de34c10b2c3141afc368cad@haskell.org> Message-ID: <063.b5479ef46daed1c9f0787539f63424fd@haskell.org> #15163: non coercion variable in coVarKindsTypesRole -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T14732 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I believe I've fixed this. Would anyone care to check and close? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 23 14:13:29 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 May 2018 14:13:29 -0000 Subject: [GHC] #15122: GHC HEAD typechecker regression In-Reply-To: <046.6b6ee0b02b0ede932ee344925ca869d9@haskell.org> References: <046.6b6ee0b02b0ede932ee344925ca869d9@haskell.org> Message-ID: <061.91bf80045d45bf42857bebaf3cd0c77c@haskell.org> #15122: GHC HEAD typechecker regression -------------------------------------+------------------------------------- Reporter: fmixing | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: indexed- valid program | types/should_compile/T15122 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => indexed-types/should_compile/T15122 * resolution: => fixed Comment: Richard, I think you might enjoy the fix here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 23 14:17:27 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 May 2018 14:17:27 -0000 Subject: [GHC] #816: Weird fundep behavior (with -fallow-undecidable-instances) In-Reply-To: <044.3c70b416f57f6840427c7f7466886ae7@haskell.org> References: <044.3c70b416f57f6840427c7f7466886ae7@haskell.org> Message-ID: <059.a1dd3cd14784275f88005c936f1bd2e4@haskell.org> #816: Weird fundep behavior (with -fallow-undecidable-instances) -------------------------------------+------------------------------------- Reporter: nibro | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler (Type | Version: 6.4.2 checker) | Resolution: | Keywords: FunDeps Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/tc216, | indexed-types/should_compile/Gentle Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => FunDeps -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 23 14:18:18 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 May 2018 14:18:18 -0000 Subject: [GHC] #3108: Do a better job of solving recursive type-class constraints with functional dependencies In-Reply-To: <046.b4958716db42be5102822b5e113eaa5b@haskell.org> References: <046.b4958716db42be5102822b5e113eaa5b@haskell.org> Message-ID: <061.5f50b7bd7e1cea39ab128221eee275be@haskell.org> #3108: Do a better job of solving recursive type-class constraints with functional dependencies -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 7.6.1 Component: Compiler (Type | Version: 6.10.1 checker) | Resolution: fixed | Keywords: FunDeps Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T3108.hs Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => FunDeps -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 23 14:20:40 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 May 2018 14:20:40 -0000 Subject: [GHC] #15180: Make Control.Exception.throw levity polymorphic Message-ID: <049.93e817224f99000e45e381c766dae62b@haskell.org> #15180: Make Control.Exception.throw levity polymorphic -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple LevityPolymorphism | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The `error` function has a levity-polymorphic type. I propose that the same be done for `throw`. I just encountered a situation where I needed this, and instead of calling `throw x`, I had to call `raise# (toException x)` because `throw` is unnecessarily restrictive. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 23 14:25:58 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 May 2018 14:25:58 -0000 Subject: [GHC] #7102: Type family instance overlap accepted in ghci In-Reply-To: <044.1bce8102b22a465aacd2599a3c22a7da@haskell.org> References: <044.1bce8102b22a465aacd2599a3c22a7da@haskell.org> Message-ID: <059.dfcb5e78b8b54890653f7b84c667ea78@haskell.org> #7102: Type family instance overlap accepted in ghci -------------------------------------+------------------------------------- Reporter: exbb2 | Owner: rwbarton Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.4.1 Resolution: | Keywords: TypeFamilies, | Instances Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: T7102a, T7102 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2994 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: TypeFamilies => TypeFamilies, Instances -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 23 14:26:22 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 May 2018 14:26:22 -0000 Subject: [GHC] #9918: GHC chooses an instance between two overlapping, but cannot resolve a clause within the similar closed type family In-Reply-To: <045.8b42c360bfa608017b9b2986029ca51e@haskell.org> References: <045.8b42c360bfa608017b9b2986029ca51e@haskell.org> Message-ID: <060.ec7050c612e3ba0553c564155e026720@haskell.org> #9918: GHC chooses an instance between two overlapping, but cannot resolve a clause within the similar closed type family -------------------------------------+------------------------------------- Reporter: qnikst | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Keywords: TypeFamilies, Resolution: | Instances Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: TypeFamilies => TypeFamilies, Instances -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 23 14:26:50 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 May 2018 14:26:50 -0000 Subject: [GHC] #12201: Wrong instance selection with overlapping instance in a superclass In-Reply-To: <045.8161628fc6b893165b02a8d6ec3bacef@haskell.org> References: <045.8161628fc6b893165b02a8d6ec3bacef@haskell.org> Message-ID: <060.03fc77d73eda5c1836aa67b01f7dd5aa@haskell.org> #12201: Wrong instance selection with overlapping instance in a superclass -------------------------------------+------------------------------------- Reporter: kanetw | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: invalid | Keywords: Instances Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => Instances -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 23 14:27:26 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 May 2018 14:27:26 -0000 Subject: [GHC] #10089: feature: warn about unused data definitions (with typeclass instances) In-Reply-To: <045.113d906ba3b76ec22ad2f715d9c6da96@haskell.org> References: <045.113d906ba3b76ec22ad2f715d9c6da96@haskell.org> Message-ID: <060.8639f19f0b0980446addca7378b50169@haskell.org> #10089: feature: warn about unused data definitions (with typeclass instances) -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Instances Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #3221 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => Instances -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 23 14:28:06 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 May 2018 14:28:06 -0000 Subject: [GHC] #15177: Faulty instance termination check, with PolyKinds and/or TypeInType In-Reply-To: <046.c24a808ae6f672394489dfaa7b18ebab@haskell.org> References: <046.c24a808ae6f672394489dfaa7b18ebab@haskell.org> Message-ID: <061.362e27e10b048229ca266f49e6771f9b@haskell.org> #15177: Faulty instance termination check, with PolyKinds and/or TypeInType -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Instances Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => Instances -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 23 14:28:54 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 May 2018 14:28:54 -0000 Subject: [GHC] #15180: Make Control.Exception.throw levity polymorphic In-Reply-To: <049.93e817224f99000e45e381c766dae62b@haskell.org> References: <049.93e817224f99000e45e381c766dae62b@haskell.org> Message-ID: <064.6cb60c1389fc105c886bef164395b04e@haskell.org> #15180: Make Control.Exception.throw levity polymorphic -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Sounds ok to me! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 23 14:44:25 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 May 2018 14:44:25 -0000 Subject: [GHC] #15181: Levity Polymorphic type signatures in GHC.Prim Message-ID: <049.9d5115f8fd0acdb98743ac6aad20a082@haskell.org> #15181: Levity Polymorphic type signatures in GHC.Prim -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Some of the type signatures in the haddocks for GHC.Prim are misleading. Here are a few: {{{ unsafeCoerce# :: a -> b mkWeak# :: o -> b -> (State# RealWorld -> (#State# RealWorld, c#)) -> State# RealWorld -> (#State# RealWorld, Weak# b#) raise# :: b -> o }}} The type signatures for these lead one to believe that all of the arguments must be **lifted** types, but this is not actually the case. For example, `raise#` is levity polymorphic in its returned value and should actually have the type: {{{ raise# :: forall (r :: RuntimeRep) (o :: TYPE r). b -> o }}} It's not just the haddocks that show an inaccurate type. Even in GHCi, we get this: {{{ >>> :set -XMagicHash >>> :set -fprint-explicit-kinds >>> :set -fprint-explicit-runtime-reps >>> import GHC.Exts >>> :t raise# raise# :: b -> a }}} Similarly, `unsafeCoerce#` is levity polymorphic in both types. Unfortunately, `mkWeak#` is more difficult to assign a correct type to. It should be possible for it to be broken into two separate functions (which each do the exact same thing), one of which operates on values of type `LiftedRep` and other on `UnliftedRep`. But this would be a breaking change, and it may not be worth the breakage it would introduce. At the very least, I feel like fixing `raise#` is worthwhile, since it wouldn't break anything. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 23 14:45:43 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 May 2018 14:45:43 -0000 Subject: [GHC] #15181: Levity Polymorphic type signatures in GHC.Prim In-Reply-To: <049.9d5115f8fd0acdb98743ac6aad20a082@haskell.org> References: <049.9d5115f8fd0acdb98743ac6aad20a082@haskell.org> Message-ID: <064.a6569bcd099fb6fe615b4224a45380dc@haskell.org> #15181: Levity Polymorphic type signatures in GHC.Prim -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by andrewthad): * keywords: => LevityPolymorphism -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 23 14:47:22 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 May 2018 14:47:22 -0000 Subject: [GHC] #15151: Better Interaction Between Specialization and GND In-Reply-To: <049.4c9d715f37d1146ca95fc1f1e65b6621@haskell.org> References: <049.4c9d715f37d1146ca95fc1f1e65b6621@haskell.org> Message-ID: <064.3c37cf7b23f7df17a32c3ff30b4e5f62@haskell.org> #15151: Better Interaction Between Specialization and GND -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: infoneeded Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): What Andrew means is that the desired machine-code for `sortPeople` is bit-for-bit identical with that of `sortInt`; and the SPECIALISE pragma in `Sort.hs` has already made a nice specialised copy of the latter. He just wants to reuse it. Of course, the reason for creating the `PersonId` newtype might be precisely the have a ''different'' `Ord` instance that the underlying `Int` type. Then it would be wrong to use `sortInt`. But if the `Ord` instance is derived, esp via GND, then it ''is'' sound to use `sortInt`. I don't see an easy way to achieve exactly what you want. But there are two workarounds. * As you say, use INLINABLE on `sort`; and specialise (even with an explicit SPECIALISE pragma) in the module where `PersonId` is defined. * Define `sortPeople` like this {{{ sortPeople :: MutablePrimArray s PersonId -> MutablePrimArray s PersonId sortPeople = coerce (sort @Int) }}} The `sort @Int` will get the efficient specialised version you want; and the `coerce` will lift it to the type you want. And if you want GHC to use `sortPeople` you'd have to add {{{ {-# RULES "sort/PersonId" sort @PersonId = sortPeople #-} }}} Interestingly, this would ''completely ignore'' any `Ord` instance for `PersonId`; indeed it doesn't need to have one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 23 14:47:36 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 May 2018 14:47:36 -0000 Subject: [GHC] #15151: Better Interaction Between Specialization and GND In-Reply-To: <049.4c9d715f37d1146ca95fc1f1e65b6621@haskell.org> References: <049.4c9d715f37d1146ca95fc1f1e65b6621@haskell.org> Message-ID: <064.935181e7141743020457fccdd823c7ad@haskell.org> #15151: Better Interaction Between Specialization and GND -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: infoneeded Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => deriving -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 23 15:01:23 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 May 2018 15:01:23 -0000 Subject: [GHC] #15151: Better Interaction Between Specialization and GND In-Reply-To: <049.4c9d715f37d1146ca95fc1f1e65b6621@haskell.org> References: <049.4c9d715f37d1146ca95fc1f1e65b6621@haskell.org> Message-ID: <064.59431b69eff61001b061a2cec06f75a4@haskell.org> #15151: Better Interaction Between Specialization and GND -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Research | needed Component: Compiler | Version: 8.4.2 Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: infoneeded => new * milestone: 8.6.1 => Research needed Comment: OK. I think I'm inclined to agree with Simon here that isn't at all simple to achieve. GHC doesn't track whether an instance was derived or not (let alone whether it was GND'd or not), and moreover, it's questionable that we'd even want to do this. After all, why should a GND'd instance receive special privileges? If I defined this instance manually: {{{#!hs instance Eq PersonId where (==) = coerce @Int @PersonId (==) }}} Then why shouldn't GHC be able to recognize that that instance has the same representation the `Eq Int` instance? A similar problem arises when you try to `coerce` from a `Map Int ()` to a `Map PersonId ()`. The nominal role on `Map`'s first type argument prevents this from typechecking, which is rather unsatisfying, since the `Ord PersonId` instance has the same representation as the `Ord Int` instance. Again, folks have asked if there is a way we could carve out an exception here to allow this to typecheck if `Ord PersonId` was GND'd, but I have similar reservations about that idea as I do the one proposed in this ticket. In short, it feels like there ought to be a more general guiding principle here to determine whether two instance dictionaries are representationally equivalent. I'm not sure what that would be, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 23 15:02:49 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 May 2018 15:02:49 -0000 Subject: [GHC] #15180: Make Control.Exception.throw levity polymorphic In-Reply-To: <049.93e817224f99000e45e381c766dae62b@haskell.org> References: <049.93e817224f99000e45e381c766dae62b@haskell.org> Message-ID: <064.f9b2f9cbea433fb3defbb3554097193a@haskell.org> #15180: Make Control.Exception.throw levity polymorphic -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | LevityPolymorphism, newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: LevityPolymorphism => LevityPolymorphism, newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 23 15:07:17 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 May 2018 15:07:17 -0000 Subject: [GHC] #11786: Need -fno-print-explicit-runtime-reps to work on IfaceType, else RuntimeRep leaks In-Reply-To: <046.943657e3f9ed3d83fd8aca1ffc9a9fa0@haskell.org> References: <046.943657e3f9ed3d83fd8aca1ffc9a9fa0@haskell.org> Message-ID: <061.26134be614ea0b63200a11e14bae52d3@haskell.org> #11786: Need -fno-print-explicit-runtime-reps to work on IfaceType, else RuntimeRep leaks -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13275, #15181 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => LevityPolymorphism * related: => #13275, #15181 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 23 15:07:49 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 May 2018 15:07:49 -0000 Subject: [GHC] #13275: ghci ignores -fprint-explicit-runtime-reps In-Reply-To: <045.9c5f6f92d9ccfac27eb19f38ae2cdb47@haskell.org> References: <045.9c5f6f92d9ccfac27eb19f38ae2cdb47@haskell.org> Message-ID: <060.e5d2400c168ad5c400f991f355412065@haskell.org> #13275: ghci ignores -fprint-explicit-runtime-reps -------------------------------------+------------------------------------- Reporter: kgadek | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: duplicate | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #11786 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * keywords: levity => LevityPolymorphism * resolution: => duplicate * related: => #11786 Comment: I'll close this in favor of #11786. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 23 15:10:33 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 May 2018 15:10:33 -0000 Subject: [GHC] #15181: Levity Polymorphic type signatures in GHC.Prim In-Reply-To: <049.9d5115f8fd0acdb98743ac6aad20a082@haskell.org> References: <049.9d5115f8fd0acdb98743ac6aad20a082@haskell.org> Message-ID: <064.51d74f7612b329dcd87ab583f5ab4952@haskell.org> #15181: Levity Polymorphic type signatures in GHC.Prim -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: duplicate | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11786 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #11786 Comment: Indeed. Note that the correct type signatures are actually displayed with `:info`: {{{ λ> :info raise# raise# :: forall b (q :: GHC.Types.RuntimeRep) (a :: TYPE q). b -> a -- Defined in ‘GHC.Prim’ λ> :info unsafeCoerce# unsafeCoerce# :: forall (k0 :: GHC.Types.RuntimeRep) (k1 :: GHC.Types.RuntimeRep) (a :: TYPE k0) (b :: TYPE k1). a -> b -- Defined in ‘GHC.Prim’ λ> :info mkWeak# mkWeak# :: forall (q :: GHC.Types.RuntimeRep) (a :: TYPE q) b c. a -> b -> (State# RealWorld -> (# State# RealWorld, c #)) -> State# RealWorld -> (# State# RealWorld, Weak# b #) -- Defined in ‘GHC.Prim’ }}} However, `:type` does not show the same thing with `-fprint-explicit- runtime-reps` enabled. In short, this is a pretty-printing issue with `:type`, the subject of #11786. I'll close this ticket in favor of that one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 23 15:41:58 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 May 2018 15:41:58 -0000 Subject: [GHC] #15151: Better Interaction Between Specialization and GND In-Reply-To: <049.4c9d715f37d1146ca95fc1f1e65b6621@haskell.org> References: <049.4c9d715f37d1146ca95fc1f1e65b6621@haskell.org> Message-ID: <064.bd4d7f567f102128c6ab87fb3fb0a870@haskell.org> #15151: Better Interaction Between Specialization and GND -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Research | needed Component: Compiler | Version: 8.4.2 Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): > In short, it feels like there ought to be a more general guiding principle here to determine whether two instance dictionaries are representationally equivalent. I'm not sure what that would be, though. That seems to sum up the difficulty pretty well. I agree that giving GNDed instances special standing would be bad (and difficult, since that's currently not even tracked). I have no idea what a good way to check instance equality would be. I don't expect that this will be doable in the immediate or even in the far future, but maybe it's a research problem someone may try to tackle one day. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 23 15:43:47 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 May 2018 15:43:47 -0000 Subject: [GHC] #11786: Need -fno-print-explicit-runtime-reps to work on IfaceType, else RuntimeRep leaks In-Reply-To: <046.943657e3f9ed3d83fd8aca1ffc9a9fa0@haskell.org> References: <046.943657e3f9ed3d83fd8aca1ffc9a9fa0@haskell.org> Message-ID: <061.5e3816925dbe46482637751af4b89a39@haskell.org> #11786: Need -fno-print-explicit-runtime-reps to work on IfaceType, else RuntimeRep leaks -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13275, #15181 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Hmm, interesting. I wonder what regressed; the logic to instantiate runtime-reps certainly exists (see `IfaceType.defaultRuntimeRepVars`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 23 15:44:01 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 May 2018 15:44:01 -0000 Subject: [GHC] #15181: Levity Polymorphic type signatures in GHC.Prim In-Reply-To: <049.9d5115f8fd0acdb98743ac6aad20a082@haskell.org> References: <049.9d5115f8fd0acdb98743ac6aad20a082@haskell.org> Message-ID: <064.a1406cf60a3894c5bd20e3244e12006f@haskell.org> #15181: Levity Polymorphic type signatures in GHC.Prim -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: duplicate | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11786 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): The haddocks are also inaccurate for these functions, which #11786 does not address. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 23 15:47:32 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 May 2018 15:47:32 -0000 Subject: [GHC] #15181: Levity Polymorphic type signatures in GHC.Prim In-Reply-To: <049.9d5115f8fd0acdb98743ac6aad20a082@haskell.org> References: <049.9d5115f8fd0acdb98743ac6aad20a082@haskell.org> Message-ID: <064.01c84614db8901f59de8806582580b25@haskell.org> #15181: Levity Polymorphic type signatures in GHC.Prim -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: duplicate | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11786 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): True, but that's a Haddock problem, not a GHC one. I'd encourage opening an instance at https://github.com/haskell/haddock/issues. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 23 15:55:33 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 May 2018 15:55:33 -0000 Subject: [GHC] #15181: Levity Polymorphic type signatures in GHC.Prim In-Reply-To: <049.9d5115f8fd0acdb98743ac6aad20a082@haskell.org> References: <049.9d5115f8fd0acdb98743ac6aad20a082@haskell.org> Message-ID: <064.30389546f7a9e7e507a1ef408c4cd1f7@haskell.org> #15181: Levity Polymorphic type signatures in GHC.Prim -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: duplicate | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11786 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): I'll do that. Do you happen to you where in the GHC source the real type signatures of these are found? In primops.txt, https://ghc.haskell.org/trac/ghc/browser/ghc/compiler/prelude/primops.txt.pp#L2282, which is where I had always assumed the type signatures came from, the types in the signature for `raise#` do not mention their true kinds. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 23 16:02:15 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 May 2018 16:02:15 -0000 Subject: [GHC] #15181: Levity Polymorphic type signatures in GHC.Prim In-Reply-To: <049.9d5115f8fd0acdb98743ac6aad20a082@haskell.org> References: <049.9d5115f8fd0acdb98743ac6aad20a082@haskell.org> Message-ID: <064.d9e79a7ad919b8873ba4caa90a4eaeb0@haskell.org> #15181: Levity Polymorphic type signatures in GHC.Prim -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: duplicate | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11786 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): Haddock issue: https://github.com/haskell/haddock/issues/838 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 23 16:05:49 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 May 2018 16:05:49 -0000 Subject: [GHC] #15168: GHC HEAD crashes on Windows 64 after the SRT overhaul (May 16, 2018 and newer) In-Reply-To: <044.deabc7a4c199713a6195b6ed0eaae792@haskell.org> References: <044.deabc7a4c199713a6195b6ed0eaae792@haskell.org> Message-ID: <059.a531ce93d28f820ddc1eadfc44733a35@haskell.org> #15168: GHC HEAD crashes on Windows 64 after the SRT overhaul (May 16, 2018 and newer) -------------------------------------+------------------------------------- Reporter: awson | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4721 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Marlow ): In [changeset:"d424d4a46a729f8530e9273282d22b6b8f34daaa/ghc" d424d4a4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d424d4a46a729f8530e9273282d22b6b8f34daaa" Fix a bug in SRT generation Summary: I had good intentions, but they were not being followed. In particular, this comment: ``` --- - we never resolve a reference to a CAF to the contents of its SRT, since --- the point of SRTs is to keep CAFs alive. ``` was not true, because we updated the srtMap after generating the SRT for a CAF. Therefore it was possible for another CAF to refer to an earlier CAF, and the reference to the earlier CAF would be shortcutted to refer to its SRT instead of pointing to the CAF itself. The fix is just to not update the srtMap when generating the SRT for a CAF, but I also refactored the code and comments around this to be a bit better organised. Test Plan: Harbourmaster Reviewers: bgamari, michalt, simonpj, erikd Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15173, #15168 Differential Revision: https://phabricator.haskell.org/D4721 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 23 16:05:49 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 May 2018 16:05:49 -0000 Subject: [GHC] #15173: Tests are failing with segfaults under CircleCI In-Reply-To: <046.ba1f8d097fee9d45bfa33d6a3fa79280@haskell.org> References: <046.ba1f8d097fee9d45bfa33d6a3fa79280@haskell.org> Message-ID: <061.326e98b1b21f6aaca02bda419ef5bbd4@haskell.org> #15173: Tests are failing with segfaults under CircleCI -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4721 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Marlow ): In [changeset:"d424d4a46a729f8530e9273282d22b6b8f34daaa/ghc" d424d4a4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d424d4a46a729f8530e9273282d22b6b8f34daaa" Fix a bug in SRT generation Summary: I had good intentions, but they were not being followed. In particular, this comment: ``` --- - we never resolve a reference to a CAF to the contents of its SRT, since --- the point of SRTs is to keep CAFs alive. ``` was not true, because we updated the srtMap after generating the SRT for a CAF. Therefore it was possible for another CAF to refer to an earlier CAF, and the reference to the earlier CAF would be shortcutted to refer to its SRT instead of pointing to the CAF itself. The fix is just to not update the srtMap when generating the SRT for a CAF, but I also refactored the code and comments around this to be a bit better organised. Test Plan: Harbourmaster Reviewers: bgamari, michalt, simonpj, erikd Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15173, #15168 Differential Revision: https://phabricator.haskell.org/D4721 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 23 16:09:34 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 May 2018 16:09:34 -0000 Subject: [GHC] #15181: Levity Polymorphic type signatures in GHC.Prim In-Reply-To: <049.9d5115f8fd0acdb98743ac6aad20a082@haskell.org> References: <049.9d5115f8fd0acdb98743ac6aad20a082@haskell.org> Message-ID: <064.2813e7fcf8b42199240186ff3cd2a24c@haskell.org> #15181: Levity Polymorphic type signatures in GHC.Prim -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: duplicate | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11786 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I'm not intimately familiar with the specifics, but I do know that `GHC.Prim` (and other code which adds magical properties to functions defined therein) is generated through the [http://git.haskell.org/ghc.git/tree/a32c8f7514c8192fa064537fb93d5a5c224991a0:/utils/genprimopcode genprimopcode] utility. `genprimopcode` has a convention that any type variable named `o` is levity polymorphic, so that's why `a -> o` gets a wired-in levity polymorphic type. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 23 16:26:35 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 May 2018 16:26:35 -0000 Subject: [GHC] #2893: Implement "Quantified constraints" proposal In-Reply-To: <045.2638646abdcf216191d07c9810407703@haskell.org> References: <045.2638646abdcf216191d07c9810407703@haskell.org> Message-ID: <060.c320270143f29337e3a58f30892db503@haskell.org> #2893: Implement "Quantified constraints" proposal -------------------------------------+------------------------------------- Reporter: porges | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.10.1 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5927 | Differential Rev(s): Phab:D4724 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * differential: Phab:D4353 => Phab:D4724 Comment: OK, finally I have a single squashed commit, rebased on master, ready to push to HEAD. It's in Phab:D4724. Please review! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 23 17:12:11 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 May 2018 17:12:11 -0000 Subject: [GHC] #15163: non coercion variable in coVarKindsTypesRole In-Reply-To: <048.b3dbe8c60de34c10b2c3141afc368cad@haskell.org> References: <048.b3dbe8c60de34c10b2c3141afc368cad@haskell.org> Message-ID: <063.e154665236aab9298d19bf42f3cca3f7@haskell.org> #15163: non coercion variable in coVarKindsTypesRole -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T14732 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alpmestan): I ran the test with a (quickest flavoured) GHC from commit a32c8f7514c8192fa064537fb93d5a5c224991a0, and I do get: {{{ Unexpected passes: typecheck/should_compile/T14732.run T14732 [unexpected] (profasm) }}} I'll change that expectation in a new diff soon and close this ticket when it's merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 23 17:21:48 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 May 2018 17:21:48 -0000 Subject: [GHC] #15163: non coercion variable in coVarKindsTypesRole In-Reply-To: <048.b3dbe8c60de34c10b2c3141afc368cad@haskell.org> References: <048.b3dbe8c60de34c10b2c3141afc368cad@haskell.org> Message-ID: <063.470ecebb8f34700d6854c409c3487bc8@haskell.org> #15163: non coercion variable in coVarKindsTypesRole -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T14732 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D4725 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alpmestan): * status: new => patch * differential: => D4725 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 23 17:22:14 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 May 2018 17:22:14 -0000 Subject: [GHC] #15163: non coercion variable in coVarKindsTypesRole In-Reply-To: <048.b3dbe8c60de34c10b2c3141afc368cad@haskell.org> References: <048.b3dbe8c60de34c10b2c3141afc368cad@haskell.org> Message-ID: <063.827c87997dcce45b14f8842ab18d84b1@haskell.org> #15163: non coercion variable in coVarKindsTypesRole -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T14732 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab D4725 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alpmestan): * differential: D4725 => Phab D4725 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 23 17:22:31 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 May 2018 17:22:31 -0000 Subject: [GHC] #15163: non coercion variable in coVarKindsTypesRole In-Reply-To: <048.b3dbe8c60de34c10b2c3141afc368cad@haskell.org> References: <048.b3dbe8c60de34c10b2c3141afc368cad@haskell.org> Message-ID: <063.09607b86bbbcf123de1861d876a76bdb@haskell.org> #15163: non coercion variable in coVarKindsTypesRole -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T14732 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab: D4725 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alpmestan): * differential: Phab D4725 => Phab: D4725 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 23 18:05:22 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 May 2018 18:05:22 -0000 Subject: [GHC] #15173: Tests are failing with segfaults under CircleCI In-Reply-To: <046.ba1f8d097fee9d45bfa33d6a3fa79280@haskell.org> References: <046.ba1f8d097fee9d45bfa33d6a3fa79280@haskell.org> Message-ID: <061.db17a895bfae2fc076152f055a72fa4e@haskell.org> #15173: Tests are failing with segfaults under CircleCI -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4721 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 23 18:06:12 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 May 2018 18:06:12 -0000 Subject: [GHC] #15168: GHC HEAD crashes on Windows 64 after the SRT overhaul (May 16, 2018 and newer) In-Reply-To: <044.deabc7a4c199713a6195b6ed0eaae792@haskell.org> References: <044.deabc7a4c199713a6195b6ed0eaae792@haskell.org> Message-ID: <059.0ea3602be9b2dda9b72a350ecb588143@haskell.org> #15168: GHC HEAD crashes on Windows 64 after the SRT overhaul (May 16, 2018 and newer) -------------------------------------+------------------------------------- Reporter: awson | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4721 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Thanks for all the help with diagnosing and testing folks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 23 18:06:54 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 May 2018 18:06:54 -0000 Subject: [GHC] #15149: Identical distinct type family fields miscompiled In-Reply-To: <051.0ce70e3fb52ab219faaf194260ba75f3@haskell.org> References: <051.0ce70e3fb52ab219faaf194260ba75f3@haskell.org> Message-ID: <066.06f2caf9ae05133fd6f8ec14bba01efd@haskell.org> #15149: Identical distinct type family fields miscompiled -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: ORF 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: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: adamgundry (added) Comment: I investigated. Here is what is going on: * When compiling module `An`, there are two `an`'s in scope * You might resaonably think that with `DisamgiguateRecordFields`, the `an` in `AnInt { an = 1 }` is ''obviously'' the `an` from module `AnInt`. * But in fact GHC's renamer uses the ''type constructor'', not the ''data constructor'' to disambiguate which `an` you mean. And both `an`'s have the same "parent", namely the type constructor `An`. This was fine before data families, because a single type constructor could not have data constructors with distinct `an` record fields. But now it can. A short term fix is to complain about ambiguity rather than arbitrarily picking one (as is done now). This happens here in `TcExpr`: {{{ tcRecordField con_like flds_w_tys (L loc (FieldOcc sel_name lbl)) rhs | Just field_ty <- assocMaybe flds_w_tys sel_name = ... }}} That `assocMaybe` just picks the first. So we could fix that. But how can we fix it properly? After all, all the information is there, staring us in the face. * One way forward might be to say that the data constructor `AnInt` is the "parent" of `AnInt.an`, and the type constructor `An` is the parent of the data constructor `AnInt`. But that change would mean we had a multi-level parent structure, with consequences that are hard to foresee. * But I think a better way is to ''stop'' trying to make the choice in the renamer. Instead in a `HsRecordFields` structure, keep the field names as not-yet-looked-up `OccNames` in the renamer, and look them up in the typechecker. At that point, we have the data constructor available in its full glory and don't need to bother with the tricky parent structures in the renamer. Adam, do you think that would work? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 23 19:22:56 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 May 2018 19:22:56 -0000 Subject: [GHC] #15163: non coercion variable in coVarKindsTypesRole In-Reply-To: <048.b3dbe8c60de34c10b2c3141afc368cad@haskell.org> References: <048.b3dbe8c60de34c10b2c3141afc368cad@haskell.org> Message-ID: <063.c88dacd86e691b097a8ed3dde0088176@haskell.org> #15163: non coercion variable in coVarKindsTypesRole -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T14732 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4725 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: Phab: D4725 => Phab:D4725 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 23 19:56:54 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 May 2018 19:56:54 -0000 Subject: [GHC] #15163: non coercion variable in coVarKindsTypesRole In-Reply-To: <048.b3dbe8c60de34c10b2c3141afc368cad@haskell.org> References: <048.b3dbe8c60de34c10b2c3141afc368cad@haskell.org> Message-ID: <063.05ee20d8d1ad1deca990539315bc631a@haskell.org> #15163: non coercion variable in coVarKindsTypesRole -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T14732 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4725 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alpmestan): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 23 20:50:07 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 May 2018 20:50:07 -0000 Subject: [GHC] #15169: SRT offset optimisation breaks on MachO platforms In-Reply-To: <046.f2a576c45e77082d3e47dbc39c359c13@haskell.org> References: <046.f2a576c45e77082d3e47dbc39c359c13@haskell.org> Message-ID: <061.bade0de67e90b6fb293265744ad94da1@haskell.org> #15169: SRT offset optimisation breaks on MachO platforms ---------------------------------+-------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by Ben Gamari ): In [changeset:"bf10456edaa03dc010821cd4c3d9f49cb11d89da/ghc" bf10456/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bf10456edaa03dc010821cd4c3d9f49cb11d89da" Disable the SRT offset optimisation on MachO platforms Unfortunately, this optimisation is infeasible on MachO platforms (e.g. Darwin) due to an object format limitation. Specifically, linking fails with errors of the form: error: unsupported relocation with subtraction expression, symbol '_integerzmgmp_GHCziIntegerziType_quotInteger_closure' can not be undefined in a subtraction expression Apparently MachO does not permit relocations' subtraction expressions to refer to undefined symbols. As far as I can tell this means that it is essentially impossible to express an offset between symbols living in different compilation units. This means that we lively can't use this optimisation on MachO platforms. Test Plan: Validate on Darwin Reviewers: simonmar, erikd Subscribers: rwbarton, thomie, carter, angerman GHC Trac Issues: #15169 Differential Revision: https://phabricator.haskell.org/D4715 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 23 20:54:39 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 May 2018 20:54:39 -0000 Subject: [GHC] #15149: Identical distinct type family fields miscompiled In-Reply-To: <051.0ce70e3fb52ab219faaf194260ba75f3@haskell.org> References: <051.0ce70e3fb52ab219faaf194260ba75f3@haskell.org> Message-ID: <066.e3a8a77a1a8785d7722a0b17e7332e58@haskell.org> #15149: Identical distinct type family fields miscompiled -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: ORF 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: | -------------------------------------+------------------------------------- Comment (by adamgundry): I think this would work, and would amount to eliminating the distinction between `HsRecField` (containing `FieldOcc`) and `HsRecUpdField` (containing `AmbiguousFieldOcc`). At the moment, the former is used for record construction and pattern matching (fields always resolved by the renamer), while the latter is used for selection and update (ambiguous fields resolved by the type-checker). Here "ambiguous" really means "ambiguous from the renamer's perspective, but not necessarily the type- checker". It would probably be simpler to defer all field resolution to the type- checker, though we've also considered going in the opposite direction, and moving all field resolution back to the renamer (see https://github.com /ghc-proposals/ghc-proposals/pull/84). I'm not really sure which is better! There's an awkward corner if we were to defer all field resolution to the type-checker, which is that `Ambiguous` fields are not currently supported by `DsMeta`. That is, using them inside a TH bracket will fail with a "not supported" error. The basic problem is that `DsMeta` works on renamed syntax, even though it runs after type-checking. Would that be difficult to change? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 23 21:22:02 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 May 2018 21:22:02 -0000 Subject: [GHC] #15124: Improve block layout for the NCG In-Reply-To: <047.b2a760b384d29a2bc137285a934c2d79@haskell.org> References: <047.b2a760b384d29a2bc137285a934c2d79@haskell.org> Message-ID: <062.dc24864804b2228dfec9b5e431c07baa@haskell.org> #15124: Improve block layout for the NCG -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (NCG) | Version: 8.2.2 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8082 #14672 | Differential Rev(s): Phab:D4726 Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * differential: => Phab:D4726 * related: #8082 => #8082 #14672 Comment: I've wrote up a patch implementing an experimental code layout algorithm, which hopefully is easy to adjust to take advantage of additional information about control flow. Code is at Phab:D4726. As it stands: * It works (only) on x64. * Performance is around the same. (Better but within the margin of error). * Compiler performance is slightly worse. There are a lot of knobs to tune this approach further but verifying any results is tedious so I stopped eventually. For now I hope to use this eventually as a substrate for the work on #14672. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 23 21:32:01 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 May 2018 21:32:01 -0000 Subject: [GHC] #9980: TcS monad is too heavy In-Reply-To: <046.9f2f16945c1ea3d5dff728997ee3b117@haskell.org> References: <046.9f2f16945c1ea3d5dff728997ee3b117@haskell.org> Message-ID: <061.547927870a40ef83338e8a04c92352ac@haskell.org> #9980: TcS monad is too heavy -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: | TypeCheckerPlugins Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * cc: darchon, nfrisby (added) Comment: I don't think `unsafeTcPluginTcM` should block this refactoring, provided we can provide `unsafeTcPluginTcS` and make sure that `TcS` is still sufficiently well-equipped. What "sufficiently well-equipped" means is a bit hard to pin down, but it should at least support the existing `TcPluginM` API. I think we should preserve the ability to do lookups in `TcPluginM`. For example, `ghc-typelits-knownnat` needs `mkNaturalExpr`, which relies on lookup (via `MonadThings`). I guess in that case one could copy code and refactor so as to do the lookups once, but in general I can imagine a plugin wanting to look up things that are not known at initialisation time. We should probably just make `TcPluginM` instantiate `MonadThings`. Perhaps Christiaan or Nick can comment on other use cases for `unsafeTcPluginTcM`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 24 04:58:23 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 May 2018 04:58:23 -0000 Subject: [GHC] #15105: `typecheckModule` from GHC API crashes on MacOS for files with TH In-Reply-To: <050.a57b50b77df5fd7c6386ac1485c8460f@haskell.org> References: <050.a57b50b77df5fd7c6386ac1485c8460f@haskell.org> Message-ID: <065.f9c8a465c864488f2707d820cb595efb@haskell.org> #15105: `typecheckModule` from GHC API crashes on MacOS for files with TH ----------------------------------+---------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHC API | Version: 8.4.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+---------------------------------------- Changes (by chak): * cc: chak (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 24 05:13:47 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 May 2018 05:13:47 -0000 Subject: [GHC] #14963: ghci -fdefer-type-errors can't run IO action from another module In-Reply-To: <047.c258bd8a8d43881f32b193f6cbfcf8f0@haskell.org> References: <047.c258bd8a8d43881f32b193f6cbfcf8f0@haskell.org> Message-ID: <062.6244e98539235feef49f14541bc14592@haskell.org> #14963: ghci -fdefer-type-errors can't run IO action from another module -------------------------------------+------------------------------------- Reporter: elaforge | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.2 Component: GHCi | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by chak): Given that this didn't make it into 8.4.2, may I ask, what is the plan here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 24 08:24:32 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 May 2018 08:24:32 -0000 Subject: [GHC] #15124: Improve block layout for the NCG In-Reply-To: <047.b2a760b384d29a2bc137285a934c2d79@haskell.org> References: <047.b2a760b384d29a2bc137285a934c2d79@haskell.org> Message-ID: <062.0e9213067d488bccdf8fc53076f36592@haskell.org> #15124: Improve block layout for the NCG -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (NCG) | Version: 8.2.2 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8082 #14672 | Differential Rev(s): Phab:D4726 Wiki Page: | -------------------------------------+------------------------------------- Comment (by AndreasK): Ater a bit of tweaking runtime difference is at -0.5%. The next step is to verify if this holds up on a different machines as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 24 08:33:01 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 May 2018 08:33:01 -0000 Subject: [GHC] #14672: Make likelyhood of branches/conditions available throughout the compiler. In-Reply-To: <047.de2c13e36902d9be8400d9448aa09671@haskell.org> References: <047.de2c13e36902d9be8400d9448aa09671@haskell.org> Message-ID: <062.04633dbb5fdacf02c57ada369f233573@haskell.org> #14672: Make likelyhood of branches/conditions available throughout the compiler. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4316 Wiki Page: | Phab:D4324 Phab:D4327 -------------------------------------+------------------------------------- Comment (by AndreasK): > - Find a good layout algorithm which can make use of partial information. There are descriptions for algorithms which work with full information about block entry counts. But Implementing one which works well on partial information is something I couldn't find anything on yet. Rolling my own is not out of the question but seems like something for a few weeks and not a few days. > * Chose a design for lowering likelyhood information to the asm level. How isn't yet clear. Annotate the instructions? Add information about blocks in a sidechannel? It's also not static since things like the register allocator also generate new blocks on the fly. Shortcutting might remove blocks and so on. > * Besides block layout if we lower that information it should also be used by the register allocators. It wrote up a patch for #15124 (Phab:D4726) which implements a new code layout algorithm. Putting the implementation for likelyhood detection (Phab:D4327) on top of the new layout code lead to runtime improvements of about -0.7%. However until I have verified these results on another machine I wouldn't consider them actionable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 24 09:15:54 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 May 2018 09:15:54 -0000 Subject: [GHC] #13895: "Illegal constraint in a type" error - is it fixable? In-Reply-To: <050.ce595caa9b871911009a7eed084d4706@haskell.org> References: <050.ce595caa9b871911009a7eed084d4706@haskell.org> Message-ID: <065.bdbe0221b115a5380d5364e42e1f855c@haskell.org> #13895: "Illegal constraint in a type" error - is it fixable? -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: TypeInType, Resolution: | ImpredicativeTypes Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12045, #14845, | Differential Rev(s): #14859 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: TypeInType => TypeInType, ImpredicativeTypes * related: #12045, #14845 => #12045, #14845, #14859 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 24 09:23:49 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 May 2018 09:23:49 -0000 Subject: [GHC] #11319: ImpredicativeTypes even more broken than usual In-Reply-To: <051.bdfa9dd4904b1999b29695de7c490ac6@haskell.org> References: <051.bdfa9dd4904b1999b29695de7c490ac6@haskell.org> Message-ID: <066.a3782eedd4262d08cfa9daeb6cfb6454@haskell.org> #11319: ImpredicativeTypes even more broken than usual -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: fixed | ImpredicativeTypes Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T11319 Blocked By: | Blocking: Related Tickets: #14859 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => fixed * related: => #14859 Comment: Note that: * The test case in comment:2 passes as of b612da667fe8fa5277fc78e972a86d4b35f98364, and has been checked into the test suite. * There is now a dedicated ticket (#14859) for tracking the request to allow explicit impredicativity. Therefore, let's close this, and move the discussion about the latter point to #14859. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 24 10:14:40 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 May 2018 10:14:40 -0000 Subject: [GHC] #13895: "Illegal constraint in a type" error - is it fixable? In-Reply-To: <050.ce595caa9b871911009a7eed084d4706@haskell.org> References: <050.ce595caa9b871911009a7eed084d4706@haskell.org> Message-ID: <065.5d0e62a718a5b561b67e945f41371159@haskell.org> #13895: "Illegal constraint in a type" error - is it fixable? -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: TypeInType, Resolution: | ImpredicativeTypes Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12045, #14845, | Differential Rev(s): Phab:D4728 #14859 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D4728 Comment: Phab:D4728 adds a test case for the latter part of the ticket (catching an illegal use of a constraint in a kind, as in `forall (t :: forall (k :: Type). Typeable k => ...)`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 24 10:17:40 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 May 2018 10:17:40 -0000 Subject: [GHC] #14845: TypeInType, index GADT by constraint witness In-Reply-To: <051.fa74d2bc56c185aedc6d84b6531239e7@haskell.org> References: <051.fa74d2bc56c185aedc6d84b6531239e7@haskell.org> Message-ID: <066.9fdb8cba4f260bf3e25085baf34ce717@haskell.org> #14845: TypeInType, index GADT by constraint witness -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13895 | Differential Rev(s): Phab:D4728 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D4728 Comment: Phab:D4728 attempts to provide a better error message when promoting a data constructor with an unpromotable context. Note that I didn't attempt to change `checkValidType` in this patch, since that would require a significant amount of plumbing to check whether `checkValidType` was being called on a type or a kind. I felt that the existing error message from `tcInstBinder` (which I tweaked slightly in this Diff to say "kind" instead of "type") was sufficient. This patch also doesn't check for type synonyms, as suggested in comment:15, since that would require changing the checks in `tcInstBinder` accordingly, and I don't know how to do that. But in any case, this is a solid improvement over the status quo. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 24 12:45:48 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 May 2018 12:45:48 -0000 Subject: [GHC] #11968: Document AMP in the deviations from the standard In-Reply-To: <047.56b750184d2d8910d5a6ee861076f297@haskell.org> References: <047.56b750184d2d8910d5a6ee861076f297@haskell.org> Message-ID: <062.875e973ec7b1b1e7b42aff4eb50b0eef@haskell.org> #11968: Document AMP in the deviations from the standard -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 8.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13196 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #13196 Comment: Closing as a duplicate of #13196 (which has been fixed). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 24 12:57:32 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 May 2018 12:57:32 -0000 Subject: [GHC] #14672: Make likelyhood of branches/conditions available throughout the compiler. In-Reply-To: <047.de2c13e36902d9be8400d9448aa09671@haskell.org> References: <047.de2c13e36902d9be8400d9448aa09671@haskell.org> Message-ID: <062.7174a55cefc2a67426238c900027f6ad@haskell.org> #14672: Make likelyhood of branches/conditions available throughout the compiler. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #849 #15124 | Differential Rev(s): Phab:D4316 Wiki Page: | Phab:D4324 Phab:D4327 -------------------------------------+------------------------------------- Changes (by AndreasK): * keywords: => CodeGen * related: => #849 #15124 * milestone: => 8.8.1 Comment: Turns out this is an old idea: #849 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 24 12:59:51 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 May 2018 12:59:51 -0000 Subject: [GHC] #849: Offer control over branch prediction In-Reply-To: <046.9c1a3dec0191543ee72b98b43c5f5f89@haskell.org> References: <046.9c1a3dec0191543ee72b98b43c5f5f89@haskell.org> Message-ID: <061.054393878bf0a2bc3057e06b6dc90191@haskell.org> #849: Offer control over branch prediction -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: N/A Blocked By: | Blocking: Related Tickets: #14672 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * related: => #14672 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 24 13:02:07 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 May 2018 13:02:07 -0000 Subject: [GHC] #11786: Need -fno-print-explicit-runtime-reps to work on IfaceType, else RuntimeRep leaks In-Reply-To: <046.943657e3f9ed3d83fd8aca1ffc9a9fa0@haskell.org> References: <046.943657e3f9ed3d83fd8aca1ffc9a9fa0@haskell.org> Message-ID: <061.9f160fbac698c81b49d5f872f3a75574@haskell.org> #11786: Need -fno-print-explicit-runtime-reps to work on IfaceType, else RuntimeRep leaks -------------------------------------+------------------------------------- Reporter: simonpj | Owner: sighingnow Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13275, #15181 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sighingnow): * owner: (none) => sighingnow Comment: I have looked into this ticket. This `:set -fprint-explicit-runtime-reps` **doesn't** work in ghc 8.0.1/8.0.2/8.2.2/8.4.2/head. ------------------------------------------------- In IfaceType.hs, we use `pprIfaceSigmaType` to pretty print a type: {{{#!hs pprIfaceSigmaType :: ShowForAllFlag -> IfaceType -> SDoc pprIfaceSigmaType show_forall ty = ppr_iface_forall_part show_forall tvs theta (ppr tau) where (tvs, theta, tau) = splitIfaceSigmaTy ty }}} The kind signatures are not feed into `eliminateRuntimeRep` and `defaultRuntimeRepVars`. The `forall (r :: GHC.Types.RuntimeRep) a (b :: TYPE r)` is pretty printed by `pprUserIfaceForAll` (invoked by `ppr_iface_forall_part`). {{{#!hs pprUserIfaceForAll :: [IfaceForAllBndr] -> SDoc pprUserIfaceForAll tvs = sdocWithDynFlags $ \dflags -> -- See Note [When to print foralls] ppWhen (any tv_has_kind_var tvs || any tv_is_required tvs || gopt Opt_PrintExplicitForalls dflags) $ pprIfaceForAll tvs where tv_has_kind_var (TvBndr (_,kind) _) = not (ifTypeIsVarFree kind) tv_is_required = isVisibleArgFlag . binderArgFlag }}} So, for `($)`, we always print `($) :: forall (r :: GHC.Types.RuntimeRep) a (b :: TYPE r) (a -> b) -> a -> b`. ----------------------------------------- As for why `:t` and `:i` print different result, in f2a2b79fa8d1c702b17e195a70734b06625e0153, we instantiate deeply for `:type`, then `:t` and `:i` have different behaviour for `($)`. If we revert this commit, `:t ($)` will produce same result as `:i ($)`. ------------------------------------------------ In ticket:11376#comment:34, Simon wrote: > OK, well we can both live with > > * `:type var` prints the original type of `var`, whereas `:type expr` typechecks, instantiates, and re-generalises the type of `expr`. > > > But how long will it be until someone posts a bug report complaining that `:t (blah)` is different from `:t blah`? > > Maybe not long, but we can just point to the user manual. Having two commands is a pain when you can get the second by adding parens to the first. > > Now we just need someone to do it. I will try this and optimistically assign this ticket to myself. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 24 13:31:15 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 May 2018 13:31:15 -0000 Subject: [GHC] #9980: TcS monad is too heavy In-Reply-To: <046.9f2f16945c1ea3d5dff728997ee3b117@haskell.org> References: <046.9f2f16945c1ea3d5dff728997ee3b117@haskell.org> Message-ID: <061.b93c95f4a7a14bb8f1894a7557425925@haskell.org> #9980: TcS monad is too heavy -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: | TypeCheckerPlugins Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by darchon): I had no need for `unsafeTcPluginTcM` until GHC 8.5, and only because: * The evidence for `KnownNat` is a `Natural`, even though Core doesn't have "first-class" support for Natural literals (but if I understand correctly, somebody is working on improving this situation) * Evidence is no longer a separate data type, but just a normal core expressions (except for evidence for `Typeable`). So the causes for my need `unsafeTcPluginTcM` can simply be classified as a "series of unfortunate/unforeseen events". However, isn't that exactly the reason for `unsafeTcPluginTcM`s existence in the first place? To have an escape hatch for situations that weren't easily foreseeable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 24 14:02:47 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 May 2018 14:02:47 -0000 Subject: [GHC] #15169: SRT offset optimisation breaks on MachO platforms In-Reply-To: <046.f2a576c45e77082d3e47dbc39c359c13@haskell.org> References: <046.f2a576c45e77082d3e47dbc39c359c13@haskell.org> Message-ID: <061.b2cbfb98936904a75419b1305128c173@haskell.org> #15169: SRT offset optimisation breaks on MachO platforms ---------------------------------+-------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 24 14:14:51 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 May 2018 14:14:51 -0000 Subject: [GHC] #15182: Lazier Semigroup instance for Maybe Message-ID: <049.b98d5b58497e8723252874a5a0f696f8@haskell.org> #15182: Lazier Semigroup instance for Maybe -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Mailing list discussion here: https://mail.haskell.org/pipermail/libraries/2018-May/028818.html The existing `Semigroup` instance for `Maybe` is: {{{ instance Semigroup a => Semigroup (Maybe a) where Nothing <> b = b a <> Nothing = a Just a <> Just b = Just (a <> b) }}} It has been proposed that it be replaced by: {{{ instance Semigroup a => Semigroup (Maybe a) where Nothing <> b = b Just a <> b = Just (maybe a (a<>) b) }}} This is lazier in the second argument, making it more consistent with the strictness of the `Semigroup` instances for `And`,`Or`,`Ord`,`Either`,`Proxy` and `()`. Equivalently, we could write: {{{ instance Semigroup a => Semigroup (Maybe a) where Nothing <> b = b Just a <> Nothing = Just a Just a <> Just b = Just (a <> b) }}} This makes it a little more clear that we aren't building a closure for partial function application, but it should have the same behavior. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 24 14:23:23 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 May 2018 14:23:23 -0000 Subject: [GHC] #14419: Check kinds for ambiguity In-Reply-To: <047.d18eb04be9d12ce25dfa15e5d81080b3@haskell.org> References: <047.d18eb04be9d12ce25dfa15e5d81080b3@haskell.org> Message-ID: <062.12e8f2240e261e1e865fe731ebf26178@haskell.org> #14419: Check kinds for ambiguity -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): OK, I think I know what is going on here. The reason that neither of these declarations: {{{#!hs data T2 :: F a -> Type data T3 (b :: F a) }}} Were flagged as ambiguously kinded is because `checkValidType` was only being called on the kinds of the individual arguments and result. In the former case, that would be `F a[sk] -> Type`, and in the latter case, it would be `F a[sig]`. What we need to be doing to catch the ambiguity in those cases is to call `checkValidType` on the //entire// kind of the declaration—in both cases, `forall a. F a -> Type`. I even whipped up a patch for doing so, which is essentially as simple as sticking an extra check in `kcTyClGroup`: {{{#!diff diff --git a/compiler/typecheck/TcTyClsDecls.hs b/compiler/typecheck/TcTyClsDecls.hs index 7e523a7..2d4dfc5 100644 --- a/compiler/typecheck/TcTyClsDecls.hs +++ b/compiler/typecheck/TcTyClsDecls.hs @@ -535,10 +535,13 @@ kcTyClGroup decls ; checkValidTelescope all_binders user_tyvars extra -- Make sure tc_kind' has the final, zonked kind variables + ; let tc_kind' = mkTyConKind all_binders' tc_res_kind' + ; checkValidType (DeclKindCtxt name) tc_kind' + ; traceTc "Generalise kind" $ vcat [ ppr name, ppr tc_binders, ppr (mkTyConKind tc_binders tc_res_kind) , ppr kvs, ppr all_binders, ppr tc_res_kind - , ppr all_binders', ppr tc_res_kind' + , ppr all_binders', ppr tc_res_kind', ppr tc_kind' , ppr scoped_tvs ] ; return (mkTcTyCon name user_tyvars all_binders' tc_res_kind' }}} That catches both of the examples above. But there's a gotcha that I didn't anticipate: consider these: {{{#!hs {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} module Bug where type family F (x :: a) type family T1 (x :: a) :: F a -- Kind: forall a. a -> F a type family T2 (x :: a) :: F x -- Kind: forall a. forall (x :: a) -> F x }}} After my patch, GHC flags `T2` as ambiguous: {{{ $ ghc/inplace/bin/ghc-stage2 --interactive Bug.hs GHCi, version 8.5.20180521: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:8:1: error: • Couldn't match expected type ‘F x’ with actual type ‘F x0’ NB: ‘F’ is a non-injective type family The type variable ‘x0’ is ambiguous • In the ambiguity check for the top-level kind for ‘T2’ To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the type family declaration for ‘T2’ | 8 | type family T2 (x :: a) :: F x | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} I find this somewhat surprising, since I would expect that the `forall (x :: a)` argument in the kind of `T2` would fully determine `x`. Perhaps this is a deficiency in the code which checks for ambiguity? I tried taking a look myself, but quickly became lost, since it relies on `tcSubType_NC` (something that is completely impenetrable to me). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 24 15:19:31 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 May 2018 15:19:31 -0000 Subject: [GHC] #12387: Template Haskell ignores class instance definitions with methods that don't belong to the class In-Reply-To: <050.eb69c313a059df9b62466d07df30fd0b@haskell.org> References: <050.eb69c313a059df9b62466d07df30fd0b@haskell.org> Message-ID: <065.724aca903b254361d17d13cddc2608aa@haskell.org> #12387: Template Haskell ignores class instance definitions with methods that don't belong to the class -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4710 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"1879d9d2c95239f6705af0cbac5fed7d9b220f28/ghc" 1879d9d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1879d9d2c95239f6705af0cbac5fed7d9b220f28" Check for mismatched class methods during typechecking Summary: Template Haskell provides a wormhole through which you can sneak methods that don't belong to a class into an instance for that class, bypassing the renamer's validity checks. The solution adopted here is to mirror the treatment for associated type family instances, which have an additional check in the typechecker which catch mismatched associated type families that were snuck through using Template Haskell. I've put a similar check for class methods into `tcMethods`. Test Plan: make test TEST=T12387 Reviewers: bgamari, simonpj Reviewed By: bgamari, simonpj Subscribers: simonpj, rwbarton, thomie, carter GHC Trac Issues: #12387 Differential Revision: https://phabricator.haskell.org/D4710 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 24 15:19:32 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 May 2018 15:19:32 -0000 Subject: [GHC] #14179: "Conflicting family instance" error pretty prints data family instances poorly In-Reply-To: <050.3b34f958a96d53100d1cde9c870ee0f4@haskell.org> References: <050.3b34f958a96d53100d1cde9c870ee0f4@haskell.org> Message-ID: <065.739c55579172e0e578fec1164e0d4256@haskell.org> #14179: "Conflicting family instance" error pretty prints data family instances poorly -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4711 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"979f085c4f87a93f48d6b567076d3c556d490fa8/ghc" 979f085c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="979f085c4f87a93f48d6b567076d3c556d490fa8" Clean up the conflicting data family instances error message Summary: The way we were pretty-printing conflicting data family instances in an error message was far from ideal: 1. If a data type had no constructors, it would print an equals sign with nothing to the right of it. 2. It would try to print GADTs using Haskell98 syntax. 3. It eta-reduced away some type variables from the LHS. This patch addresses these three issues: 1. We no longer print constructors at all in this error message. There's really no reason to do so in the first place, since duplicate data family instances always conflict, regardless of their constructors. 2. Since we no longer print constructors, we no longer have to worry about whether we're using GADT or Haskell98 syntax. 3. I've put in a fix to ensure that type variables are no longer eta-reduced away from the LHS. Test Plan: make test TEST=T14179 Reviewers: goldfire, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14179 Differential Revision: https://phabricator.haskell.org/D4711 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 24 15:21:07 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 May 2018 15:21:07 -0000 Subject: [GHC] #14179: "Conflicting family instance" error pretty prints data family instances poorly In-Reply-To: <050.3b34f958a96d53100d1cde9c870ee0f4@haskell.org> References: <050.3b34f958a96d53100d1cde9c870ee0f4@haskell.org> Message-ID: <065.5108beb66d529a54aa5a22ba44f3a94f@haskell.org> #14179: "Conflicting family instance" error pretty prints data family instances poorly -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: fixed | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Poor/confusing | Test Case: indexed- error message | types/should_fail/T14179 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4711 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * testcase: => indexed-types/should_fail/T14179 * resolution: => fixed * milestone: => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 24 15:21:37 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 May 2018 15:21:37 -0000 Subject: [GHC] #14381: Consider making ghc-pkg fill in abi-depends based on depends In-Reply-To: <045.a757b4d974e51bd6ab6f6869ba65de4c@haskell.org> References: <045.a757b4d974e51bd6ab6f6869ba65de4c@haskell.org> Message-ID: <060.21ad138b9dd054d183022fe5b30af5dc@haskell.org> #14381: Consider making ghc-pkg fill in abi-depends based on depends -------------------------------------+------------------------------------- Reporter: ezyang | Owner: tdammers Type: bug | Status: patch Priority: highest | Milestone: 8.4.3 Component: ghc-pkg | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4159 Wiki Page: | Phab:D4729 -------------------------------------+------------------------------------- Changes (by tdammers): * status: new => patch * differential: Phab:D4159 => Phab:D4159 Phab:D4729 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 24 15:21:43 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 May 2018 15:21:43 -0000 Subject: [GHC] #12387: Template Haskell ignores class instance definitions with methods that don't belong to the class In-Reply-To: <050.eb69c313a059df9b62466d07df30fd0b@haskell.org> References: <050.eb69c313a059df9b62466d07df30fd0b@haskell.org> Message-ID: <065.92e8bc636f5bb5a5950f4decc59827b0@haskell.org> #12387: Template Haskell ignores class instance definitions with methods that don't belong to the class -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Template Haskell | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: th/T12387 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4710 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * testcase: => th/T12387 * resolution: => fixed * milestone: => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 24 15:53:31 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 May 2018 15:53:31 -0000 Subject: [GHC] #10778: GHC doesn't infer all constrains In-Reply-To: <046.c3c6007a301d4e9f2bfd6528e390abd4@haskell.org> References: <046.c3c6007a301d4e9f2bfd6528e390abd4@haskell.org> Message-ID: <061.58c7bfbc708c56c4c0324faf3b801cd0@haskell.org> #10778: GHC doesn't infer all constrains -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: 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: | -------------------------------------+------------------------------------- Changes (by George): * failure: None/Unknown => GHC rejects valid program -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 24 16:34:24 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 May 2018 16:34:24 -0000 Subject: [GHC] #15105: `typecheckModule` from GHC API crashes on MacOS for files with TH In-Reply-To: <050.a57b50b77df5fd7c6386ac1485c8460f@haskell.org> References: <050.a57b50b77df5fd7c6386ac1485c8460f@haskell.org> Message-ID: <065.7dbbd9e8bd38c0f23c702f1ea4343fd1@haskell.org> #15105: `typecheckModule` from GHC API crashes on MacOS for files with TH ----------------------------------+---------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHC API | Version: 8.4.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+---------------------------------------- Comment (by harpocrates): After removing `HSinteger-gmp-1.0.2.0.o` more than two weeks ago, I stopped having this issue. Since then, I haven't encountered any other issues/side-effects (isn't a statically linked GHCi the default? GHCi is still working for me...). Everything has continued to function just fine and as expected. I confess I haven't really spent any time on this since that last comment on the Haddock ticket. I'd be glad to help (since I can replicate the bug quite easily), but I'm not sure what to investigate next. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 25 01:42:55 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 May 2018 01:42:55 -0000 Subject: [GHC] #14419: Check kinds for ambiguity In-Reply-To: <047.d18eb04be9d12ce25dfa15e5d81080b3@haskell.org> References: <047.d18eb04be9d12ce25dfa15e5d81080b3@haskell.org> Message-ID: <062.41fd9f5bedf4927eb1044f62bd64df6b@haskell.org> #14419: Check kinds for ambiguity -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Not sure offhand why you witnessed the failure that you did, but I think it's troublesome to put the ambiguity check where you did. Better would be in `checkValidTyCon`, where other validity checks are done. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 25 02:14:48 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 May 2018 02:14:48 -0000 Subject: [GHC] #14890: Make Linux slow validate green In-Reply-To: <046.a107a76cbb0183d36ada5ee5738b1b26@haskell.org> References: <046.a107a76cbb0183d36ada5ee5738b1b26@haskell.org> Message-ID: <061.12b24cb027621ccbcd0808599b8e9f77@haskell.org> #14890: Make Linux slow validate green -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alpmestan Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D4546, D4636, Wiki Page: | D4712 -------------------------------------+------------------------------------- Comment (by alpmestan): PR for enabling slow validate on linux in the Circle CI script [https://github.com/ghc/ghc/pull/141 on github]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 25 02:16:54 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 May 2018 02:16:54 -0000 Subject: [GHC] #15142: GHC HEAD regression: tcTyVarDetails In-Reply-To: <050.e98a1ae073f44bf5c57814edebb43575@haskell.org> References: <050.e98a1ae073f44bf5c57814edebb43575@haskell.org> Message-ID: <065.32b56a2aeb74005f43d2bdbd58348877@haskell.org> #15142: GHC HEAD regression: tcTyVarDetails -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: TypeInType, Resolution: | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Oh dear is right. No time to look right now. Will do so next week. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 25 02:57:16 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 May 2018 02:57:16 -0000 Subject: [GHC] #15183: Expose the SNat type and the natSing method Message-ID: <045.821e29bf2ba8cd01cfe0645e4dabde38@haskell.org> #15183: Expose the SNat type and the natSing method -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Core | Version: 8.2.2 Libraries | 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: -------------------------------------+------------------------------------- Currently, neither the `SNat` type nor the `natSing` method of `KnownNat` are exported from `GHC.TypeLits`. This is weird and awkward. There's no apparent reason not to expose the `SNat` ''type'', although it may make sense not to expose its definition. It also could possibly make sense not to expose the fact that `natSing` is a ''method'' of `KnownNat`, but there's no apparent reason not to export a function with its type. Can we just do those? 1. Export the `SNat` type. 2. Export a function with the type of `natSing`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 25 03:17:00 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 May 2018 03:17:00 -0000 Subject: [GHC] #11786: Need -fno-print-explicit-runtime-reps to work on IfaceType, else RuntimeRep leaks In-Reply-To: <046.943657e3f9ed3d83fd8aca1ffc9a9fa0@haskell.org> References: <046.943657e3f9ed3d83fd8aca1ffc9a9fa0@haskell.org> Message-ID: <061.df75ba8c50d0502c04becbfd06699311@haskell.org> #11786: Need -fno-print-explicit-runtime-reps to work on IfaceType, else RuntimeRep leaks -------------------------------------+------------------------------------- Reporter: simonpj | Owner: sighingnow Type: bug | Status: patch Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13275, #15181 | Differential Rev(s): Phab:D4733 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sighingnow): * status: new => patch * differential: => Phab:D4733 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 25 04:29:56 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 May 2018 04:29:56 -0000 Subject: [GHC] #10778: GHC doesn't infer all constrains In-Reply-To: <046.c3c6007a301d4e9f2bfd6528e390abd4@haskell.org> References: <046.c3c6007a301d4e9f2bfd6528e390abd4@haskell.org> Message-ID: <061.abee1477cb1b297468ca58ab11cd7c46@haskell.org> #10778: GHC doesn't infer all constrains -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: 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: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) Comment: Is this just waiting on a test case? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 25 08:18:15 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 May 2018 08:18:15 -0000 Subject: [GHC] #15183: Expose the SNat type and the natSing method In-Reply-To: <045.821e29bf2ba8cd01cfe0645e4dabde38@haskell.org> References: <045.821e29bf2ba8cd01cfe0645e4dabde38@haskell.org> Message-ID: <060.a17f1a15b1b1264fc3eafd2c600e985e@haskell.org> #15183: Expose the SNat type and the natSing method -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I don't necessarily object to this idea, but what exactly can one do with an `SNat` if it's exported abstractly? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 25 08:27:30 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 May 2018 08:27:30 -0000 Subject: [GHC] #15183: Expose the SNat type and the natSing method In-Reply-To: <045.821e29bf2ba8cd01cfe0645e4dabde38@haskell.org> References: <045.821e29bf2ba8cd01cfe0645e4dabde38@haskell.org> Message-ID: <060.ebbae78fc86c013f81d766bfbe754c6b@haskell.org> #15183: Expose the SNat type and the natSing method -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Well, clearly I missed a step. We'd also want a function to convert an `SNat` to a `Natural`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 25 08:51:03 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 May 2018 08:51:03 -0000 Subject: [GHC] #14419: Check kinds for ambiguity In-Reply-To: <047.d18eb04be9d12ce25dfa15e5d81080b3@haskell.org> References: <047.d18eb04be9d12ce25dfa15e5d81080b3@haskell.org> Message-ID: <062.b79ec7f1c286494bb7554df720c67a89@haskell.org> #14419: Check kinds for ambiguity -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): * I agree that `checkValidTyCon` is a better place. (It's outside "the knot".) * We should ''remove'' any `checkValidType` calls on the individual kind ascriptions. No point in calling it on the `a` in `data T (x::a) = ...`. I have not looked into just where we'd remove it. Your point about the ambiguity check is very interesting. At the term level, the ambiguity check models this: {{{ f :: forall a. F a -> Int f = ... f2 :: forall a. F a -> Int f2 = f }}} It's very confusing if `f2` does not typecheck; after all, it has the same type as `f`. The ambiguity check tests this. At the call of `f` we instantiate its foralls (say `a :-> alpha`); and then unify with a skolemised version of `f2`'s type. And thus we unify `F alpha ~ F a` and fail. Analogously, suppose we said (as you suggest) {{{ type family F (x :: a) type family T2 (x :: a) :: F x -- Kind: forall a. forall (x :: a) -> F x }}} I've changed your `T2` to be a data type. Occurrences of `T2` will look like `T2 {a} x`, where the `{a}` is invisible in the source language; it is implicitly instantiate. But not that the `x` argument is fully explicit. Now type T3 :: forall a. forall (x::a) -> F x type T3 x = T2 x }}} (I know we don't have separate kind signatures yet, but we will!) Notice that we must apply `T2` to its explicit args; the `forall (x::a) -> blah` behaves like an arrow not like an (implicitly-instantiated) forall from the point of view of ambiguity checking. Looking at `TcUnify.tc_sub_type_ds`, the culprit looks like the call to `topInstantiate`. It already comes in two variants: * `topInstantiate`: instantiate all outer foralls * `topInstantiateInferred`: instantiate all outer `Inferred` foralls But the former instantiates `Required` foralls, and '''I think it should never do so.''' NB: See `Note [TyVarBndrs, TyVarBinders, TyConBinders, and visibility]` in `TyCoRep` for a refresher on `Inferred/Specified/Required`. (NB: `Required` binders never occur in the foralls of a term variable, so this change cannot affect the term level.) Richard, do you agree? Ryan, would you like to try that (a one-line change in `should_inst` in `Inst.top_instantiate`)? Richard, I must say that I find it hard to be sure where we should call `topInstantiate` and where `topInstantiateInferred`. Some comments at the call sites would be very welcome. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 25 08:56:37 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 May 2018 08:56:37 -0000 Subject: [GHC] #15183: Expose the SNat type and the natSing method In-Reply-To: <045.821e29bf2ba8cd01cfe0645e4dabde38@haskell.org> References: <045.821e29bf2ba8cd01cfe0645e4dabde38@haskell.org> Message-ID: <060.6235d63d25e5d2b67e4a1fe13982ed3c@haskell.org> #15183: Expose the SNat type and the natSing method -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): OK. Is your intention to provide an alternative to the current `Proxy`-based API? (For instance, `natVal :: KnownNat n = Proxy n -> Natural`, and you're suggesting to augment it with something like `fromNatSing :: SNat n -> Natural`?) If so, it may also be worth considering adding `SNat`-consuming counterparts to `sameNat` and `someNatVal` (the latter of which would require something like `data SomeNatSing`, which is like `SomeNat`, but having an `SNat` as a field instead of `Proxy`). Also, `KnownSymbol`/`symbolSing` has similar design considerations. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 25 09:08:01 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 May 2018 09:08:01 -0000 Subject: [GHC] #15111: GHCi leaks the first modules loaded In-Reply-To: <047.0c4c39abd5bd384dc6fc34801a3d6baa@haskell.org> References: <047.0c4c39abd5bd384dc6fc34801a3d6baa@haskell.org> Message-ID: <062.51c92e89fe9f955c15607e096554057f@haskell.org> #15111: GHCi leaks the first modules loaded -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: ghci Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4658 Wiki Page: | Phab:D4659 -------------------------------------+------------------------------------- Comment (by Simon Marlow ): In [changeset:"5b6ef59f99590128394b9dd9717b07fa971f6fc0/ghc" 5b6ef59/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5b6ef59f99590128394b9dd9717b07fa971f6fc0" Add -fghci-leak-check to check for space leaks Summary: (re-applying this patch now that D4659 is committed) Space leaks in GHCi emerge from time to time and tend to come back again after they get fixed. This is an attempt to limit regressions by * adding a reliable detection for some classes of space leaks in GHCi * turning on leak checking for all GHCi tests in the test suite, so that we'll notice if the leak appears again. The idea for detecting space leaks is quite simple: * find some data that we expect to be GC'd later, make a weak pointer to it * when we expect the data to be dead, do a `performGC` and then check the status of the weak pointer. It would be nice to apply this trick to lots of things in GHC, e.g. ensuring that HsSyn is not retained after the desugarer, or ensuring that CoreSyn from the previous simplifier pass is not retained. Test Plan: validate Reviewers: bgamari, simonpj, erikd, niteria Subscribers: thomie, carter GHC Trac Issues: #15111 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 25 09:23:00 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 May 2018 09:23:00 -0000 Subject: [GHC] #14419: Check kinds for ambiguity In-Reply-To: <047.d18eb04be9d12ce25dfa15e5d81080b3@haskell.org> References: <047.d18eb04be9d12ce25dfa15e5d81080b3@haskell.org> Message-ID: <062.bd6e38306f2f0d381485af2dfada961c@haskell.org> #14419: Check kinds for ambiguity -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Simon, is this the one-line change you had in mind? {{{#!diff diff --git a/compiler/typecheck/Inst.hs b/compiler/typecheck/Inst.hs index 7b27dfa..30023b9 100644 --- a/compiler/typecheck/Inst.hs +++ b/compiler/typecheck/Inst.hs @@ -227,7 +227,7 @@ top_instantiate inst_all orig ty (theta, rho) = tcSplitPhiTy phi should_inst bndr - | inst_all = True + | inst_all = binderArgFlag bndr /= Required | otherwise = binderArgFlag bndr == Inferred deeplyInstantiate :: CtOrigin -> TcSigmaType -> TcM (HsWrapper, TcRhoType) }}} Unfortunately, that causes `tc_sub_type_ds` to loop on `type family T2` from comment:4. The `-ddump-tc-trace` output loops on: {{{ tc_sub_type_ds ty_actual = forall (x :: a_a1zH[tau:1]) -> F x ty_expected = F x_a1zG[sk:1] Instantiating all tyvars? True origin arising from a type equality forall a. forall (x :: a) -> F x ~ forall a. forall (x :: a) -> F x type forall x_a1za. F x_a1za theta [] leave_bndrs [x_a1za] with theta: [] tc_sub_type_ds ty_actual = forall (x :: a_a1zH[tau:1]) -> F x ty_expected = F x_a1zG[sk:1] ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 25 11:00:40 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 May 2018 11:00:40 -0000 Subject: [GHC] #10778: GHC doesn't infer all constrains In-Reply-To: <046.c3c6007a301d4e9f2bfd6528e390abd4@haskell.org> References: <046.c3c6007a301d4e9f2bfd6528e390abd4@haskell.org> Message-ID: <061.0e81700528766ad48a523fca936eee11@haskell.org> #10778: GHC doesn't infer all constrains -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: 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: | -------------------------------------+------------------------------------- Comment (by simonpj): > Is this just waiting on a test case? I think so, yes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 25 11:39:13 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 May 2018 11:39:13 -0000 Subject: [GHC] #15061: print022 testcase fails on i386 In-Reply-To: <046.070201c29a49dce5435517538bdcfad1@haskell.org> References: <046.070201c29a49dce5435517538bdcfad1@haskell.org> Message-ID: <061.7dbcb6b7073c66242729e56fec0546e5@haskell.org> #15061: print022 testcase fails on i386 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: GHCi | Version: 8.2.2 Resolution: | Keywords: ci-breakage Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I get a different failure: {{{ omer at i386-chroot:~/ghc/testsuite/tests/ghci.debugger/scripts$ ~/ghc/inplace/bin/ghc-stage2 --interactive GHCi, version 8.5.20180524: http://www.haskell.org/ghc/ :? for help Prelude> :l print022.hs [1 of 1] Compiling Main ( print022.hs, interpreted ) Ok, one module loaded. *Main> seq test () () *Main> :print test test = C*** Exception: Prelude.!!: index too large }}} The `!!` error is definitely not caused by the interpreted program. I think it may be GHCi driver bug (maybe in `InteractiveEval` or related modules). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 25 11:40:21 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 May 2018 11:40:21 -0000 Subject: [GHC] #14963: ghci -fdefer-type-errors can't run IO action from another module In-Reply-To: <047.c258bd8a8d43881f32b193f6cbfcf8f0@haskell.org> References: <047.c258bd8a8d43881f32b193f6cbfcf8f0@haskell.org> Message-ID: <062.e4b3df15fcff59969ae889b486782515@haskell.org> #14963: ghci -fdefer-type-errors can't run IO action from another module -------------------------------------+------------------------------------- Reporter: elaforge | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.2 Component: GHCi | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): As a short term fix how bad would it be to make `-fdefer-type-errors` incompatible with GHCi? We could apply that fix to HEAD (until we fix this ticket properly) and perhaps even to 8.4.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 25 12:01:33 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 May 2018 12:01:33 -0000 Subject: [GHC] #15149: Identical distinct type family fields miscompiled In-Reply-To: <051.0ce70e3fb52ab219faaf194260ba75f3@haskell.org> References: <051.0ce70e3fb52ab219faaf194260ba75f3@haskell.org> Message-ID: <066.d01d2edc960ec517682cd7594013c12b@haskell.org> #15149: Identical distinct type family fields miscompiled -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: ORF 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: | -------------------------------------+------------------------------------- Comment (by simonpj): > It would probably be simpler to defer all field resolution to the type- checker, though we've also considered going in the opposite direction, and moving all field resolution back to the renamer That proposal (!DuplicateRecordFields simplification) is about simplifying the DRF spec. Yes, it'd make it possible to resolve that particular aspect of record fields in the renamer -- but it by no means requires us to do so. > That is, using them inside a TH bracket will fail with a "not supported" error My baseline thought is that `C { x = e1, y = e2 }` should have `x` and `y` as `OccNames` right up to the type checker. And that would be so in TH syntax to. In TH we have {{{ data Exp = ... | RecConE [FieldExp] type FieldExp = (Name,Pat) }}} We could consider changing that `Name` to `OccName`, or just using the `NameS` variant of `Name`. No serious problem there. My notion of using `OccName` is a bit ''too'' simple. * It is in principle fine for `C { ... }` in both expressions and patterns, but in fact H98 syntax allows a qualified name there, thus `C { M.x = e }`. That suggests we need a `RdrName` there, not an `OccName`. The type checker can still resolve it, since the name to the LHS of the `=` need consider only the top-level `GlobalRdrEnv` and that is entirely available in the typechecker. * For record update `e { x = e2 }`, the same applies but now the use of qualified names to disambiguate is more important still. I think this boils down to * Remove the `extFieldOcc` field of `data FieldOcc`, leaving only a `Located RdrName`. (In fact we can then inline `FieldOcc`.) * Move the lookup machinery from the renamer to the typechecker Do you think that'd work? Any motivation to try it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 25 12:08:34 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 May 2018 12:08:34 -0000 Subject: [GHC] #15184: T4442 fails on i386 Message-ID: <043.2aff333ef7aff4746a063eeba88c2731@haskell.org> #15184: T4442 fails on i386 --------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: x86 | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+------------------------------------- {{{ omer at i386-chroot:~/ghc/testsuite/tests/primops/should_run$ ~/ghc/inplace/bin/ghc-stage2 T4442.hs [1 of 1] Compiling Main ( T4442.hs, T4442.o ) T4442.hs:135:14: error: Not in scope: data constructor `I64#' | 135 | (\arr i (I64# a) s -> write arr i a s) | ^^^^ }}} Looking at the code, it uses `Int` on 64-bit, but `Int64` on i386, probably to use 64-bit integers on both platforms. I think we can just use `Int64` on both platforms and get rid of the CPP to avoid further breakage in the future. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 25 12:13:43 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 May 2018 12:13:43 -0000 Subject: [GHC] #15062: num009 is incredibly platform-sensitive In-Reply-To: <046.fd26963ba1ba8046e379799dd9722c15@haskell.org> References: <046.fd26963ba1ba8046e379799dd9722c15@haskell.org> Message-ID: <061.22888af1170c1abee7e0176a45c4d93a@haskell.org> #15062: num009 is incredibly platform-sensitive -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Test Suite | Version: 8.2.2 Resolution: | Keywords: ci-breakage Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Also fails here on i386 chroot environment. > Perhaps we should instead test the output against the same evaluations performed by a C program. This would eliminate spurious failures due to platform or C library differences. Could you elaborate on this? This doesn't look like a spurious failure to me. I think either `sin`, `cos` etc. or C FFI when passing floats is broken on i386. Sounds pretty serious to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 25 14:15:08 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 May 2018 14:15:08 -0000 Subject: [GHC] #15155: How untagged pointers sneak into banged fields In-Reply-To: <048.7d229d504bd9df060a5294d6d9eccfdc@haskell.org> References: <048.7d229d504bd9df060a5294d6d9eccfdc@haskell.org> Message-ID: <063.696ceb337870b1bed3495fa33b66d896@haskell.org> #15155: How untagged pointers sneak into banged fields -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 14677 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by heisenbug): While investigating I came across http://blog.omega-prime.co.uk/2011/07/06 /the-sad-state-of-symbol-aliases from Max Bolingbroke. Looks like linux does not support aliasing of an external symbol. That is sad. Need to re- check linker script definitions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 25 14:23:11 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 May 2018 14:23:11 -0000 Subject: [GHC] #15155: How untagged pointers sneak into banged fields In-Reply-To: <048.7d229d504bd9df060a5294d6d9eccfdc@haskell.org> References: <048.7d229d504bd9df060a5294d6d9eccfdc@haskell.org> Message-ID: <063.03f2cd5434f3a62d266e61102f6dd282@haskell.org> #15155: How untagged pointers sneak into banged fields -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: heisenbug Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 14677 Related Tickets: 13027 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by heisenbug): * owner: (none) => heisenbug * related: => 13027 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 25 16:25:40 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 May 2018 16:25:40 -0000 Subject: [GHC] #15149: Identical distinct type family fields miscompiled In-Reply-To: <051.0ce70e3fb52ab219faaf194260ba75f3@haskell.org> References: <051.0ce70e3fb52ab219faaf194260ba75f3@haskell.org> Message-ID: <066.bbb6d1ebaf0723f52bfa2cca0bfec855@haskell.org> #15149: Identical distinct type family fields miscompiled -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: ORF 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: | -------------------------------------+------------------------------------- Comment (by simonpj): PS, Neil you say > I haven't been able to find any workarounds (without just avoiding clashing record fields). Can't you just not use `DisambiguateRecordFields` and instead say this? {{{ main = print (AnDouble{AnDouble.an=1}, AnInt{AnInt.an=1}) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 25 17:15:47 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 May 2018 17:15:47 -0000 Subject: [GHC] #15134: enumFrom... aren't really documented. In-Reply-To: <045.101e34e5570fe8f6e2839dfe4e91d13c@haskell.org> References: <045.101e34e5570fe8f6e2839dfe4e91d13c@haskell.org> Message-ID: <060.d3cbd1d06f8fad9722c3d26cbf412b45@haskell.org> #15134: enumFrom... aren't really documented. -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Azel Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4737 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Azel): * status: new => patch * differential: => Phab:D4737 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 25 17:16:35 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 May 2018 17:16:35 -0000 Subject: [GHC] #15078: base: Customary type class laws (e.g. for Eq) and non-abiding instances (e.g. Float) should be documented In-Reply-To: <046.a4c8c72c9e9d68a07b93ce24b1eed9ca@haskell.org> References: <046.a4c8c72c9e9d68a07b93ce24b1eed9ca@haskell.org> Message-ID: <061.05cef16768267e013178163c7e0baf32@haskell.org> #15078: base: Customary type class laws (e.g. for Eq) and non-abiding instances (e.g. Float) should be documented -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: Azel Type: feature request | Status: patch Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.4.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4736 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Azel): * status: new => patch * differential: => Phab:D4736 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 25 17:21:57 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 May 2018 17:21:57 -0000 Subject: [GHC] #15185: Enum instance for IntX / WordX are inefficient Message-ID: <045.8d849a48d67b73f64eaab8f541972e7c@haskell.org> #15185: Enum instance for IntX / WordX are inefficient -------------------------------------+------------------------------------- Reporter: guibou | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Core | Version: 8.4.2 Libraries | 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: -------------------------------------+------------------------------------- The following factorial benchmark show high discrepancy in performance between `Int` and `Int64` (and similarly between `Word` and `Word64`) when using `product [1..n]` to compute factorial: {{{#!haskell {-# LANGUAGE TypeApplications #-} import Criterion.Main import Data.Int import Data.Word import Numeric.Natural fact :: Integral t => t -> t fact n = product [1..n] fact2 :: Integral t => t -> t fact2 n = go 1 n where go acc 1 = acc go acc n = go (acc * n) (n - 1) main :: IO () main = defaultMain [ bgroup "fact 20" [ bench "Int" $ whnf (fact @Int) 20 , bench "Word" $ whnf (fact @Word) 20 , bench "Int64" $ whnf (fact @Int64) 20 , bench "Word64" $ whnf (fact @Word64) 20 , bench "Integer" $ whnf (fact @Integer) 20 , bench "Natural" $ whnf (fact @Natural) 20 ] , bgroup "fact2 20" [ bench "Int" $ whnf (fact @Int) 20 , bench "Word" $ whnf (fact @Word) 20 , bench "Int64" $ whnf (fact @Int64) 20 , bench "Word64" $ whnf (fact @Word64) 20 , bench "Integer" $ whnf (fact @Integer) 20 , bench "Natural" $ whnf (fact @Natural) 20 ] ] }}} {{{ benchmarking fact 20/Int time 17.33 ns (17.22 ns .. 17.41 ns) 1.000 R² (1.000 R² .. 1.000 R²) mean 17.21 ns (17.16 ns .. 17.29 ns) std dev 222.4 ps (184.5 ps .. 282.3 ps) variance introduced by outliers: 15% (moderately inflated) benchmarking fact 20/Word time 17.25 ns (17.01 ns .. 17.63 ns) 0.999 R² (0.997 R² .. 1.000 R²) mean 17.19 ns (17.11 ns .. 17.36 ns) std dev 358.6 ps (199.4 ps .. 674.3 ps) variance introduced by outliers: 32% (moderately inflated) benchmarking fact 20/Int64 time 166.7 ns (165.4 ns .. 168.5 ns) 0.999 R² (0.997 R² .. 1.000 R²) mean 166.8 ns (166.0 ns .. 168.5 ns) std dev 4.077 ns (1.854 ns .. 6.592 ns) variance introduced by outliers: 35% (moderately inflated) benchmarking fact 20/Word64 time 560.5 ns (550.6 ns .. 575.0 ns) 0.995 R² (0.989 R² .. 1.000 R²) mean 556.5 ns (549.1 ns .. 575.9 ns) std dev 36.08 ns (9.195 ns .. 60.69 ns) variance introduced by outliers: 78% (severely inflated) benchmarking fact 20/Integer time 421.9 ns (419.8 ns .. 425.3 ns) 1.000 R² (0.999 R² .. 1.000 R²) mean 427.7 ns (425.5 ns .. 431.3 ns) std dev 9.238 ns (6.311 ns .. 16.19 ns) variance introduced by outliers: 28% (moderately inflated) benchmarking fact 20/Natural time 534.5 ns (532.6 ns .. 536.3 ns) 1.000 R² (1.000 R² .. 1.000 R²) mean 533.7 ns (532.6 ns .. 535.3 ns) std dev 4.535 ns (3.652 ns .. 6.226 ns) benchmarking fact2 20/Int time 17.14 ns (17.07 ns .. 17.23 ns) 1.000 R² (1.000 R² .. 1.000 R²) mean 17.15 ns (17.10 ns .. 17.24 ns) std dev 227.1 ps (167.4 ps .. 286.9 ps) variance introduced by outliers: 16% (moderately inflated) benchmarking fact2 20/Word time 16.93 ns (16.86 ns .. 17.02 ns) 1.000 R² (1.000 R² .. 1.000 R²) mean 16.90 ns (16.86 ns .. 16.95 ns) std dev 149.8 ps (107.4 ps .. 192.5 ps) benchmarking fact2 20/Int64 time 165.1 ns (164.6 ns .. 165.7 ns) 1.000 R² (1.000 R² .. 1.000 R²) mean 164.8 ns (164.5 ns .. 165.1 ns) std dev 1.033 ns (778.6 ps .. 1.363 ns) benchmarking fact2 20/Word64 time 545.3 ns (542.8 ns .. 547.9 ns) 1.000 R² (1.000 R² .. 1.000 R²) mean 543.6 ns (542.4 ns .. 545.2 ns) std dev 4.741 ns (3.736 ns .. 5.824 ns) benchmarking fact2 20/Integer time 419.1 ns (417.2 ns .. 421.1 ns) 1.000 R² (1.000 R² .. 1.000 R²) mean 418.2 ns (416.8 ns .. 420.2 ns) std dev 5.415 ns (4.094 ns .. 7.147 ns) variance introduced by outliers: 12% (moderately inflated) benchmarking fact2 20/Natural time 533.8 ns (532.2 ns .. 536.1 ns) 1.000 R² (1.000 R² .. 1.000 R²) mean 533.2 ns (532.1 ns .. 534.8 ns) std dev 4.428 ns (3.217 ns .. 5.741 ns) }}} In `fact`, `Int` and `Word` are efficient, `Int64` and `Word64` are respectively 10x and 20x slowers, when they should be identical on 64 bit platform. `Word64` is even slower than `Integer`! Replacing `fact` by a handwritten recursion, in `fact2` gives something more coherent where all the 64 bits types have roughly the same efficiency. I observed in the source code that `Int` and `Int64` are not implemented as type synonym. Using `-ddump-rule-firings`, I observed that a rule `fold/build` fired and removed the `fold` for the `Int` case, and not for the `Int64`, I don't understand much ;( This is not dramatic because most people will use `Int` instead of `Int64`, but it is a surprising behavior. I also observed that smaller integral (such as `Int8`, `Int16`, `Int32`) behaves as badly as `Int64`) and this is much more important because there is no other default and more efficient type synonym. Note that I'll be interested to provide a patch myself if mentored a bit. Especially, I'm thinking about merging the `Int` and `Int64` implementation (with respect to the architecture default word size). Tested on GHC 8.4.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 25 17:30:29 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 May 2018 17:30:29 -0000 Subject: [GHC] #9607: Programs that require AllowAmbiguousTypes in 7.8 In-Reply-To: <048.5e8b94684e17f1fdfdeced3e3d614b17@haskell.org> References: <048.5e8b94684e17f1fdfdeced3e3d614b17@haskell.org> Message-ID: <063.b6f23f38c5ce2dbf7a706227e2af1bb3@haskell.org> #9607: Programs that require AllowAmbiguousTypes in 7.8 -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Resolution: | Keywords: TypeFamilies 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => TypeFamilies -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 25 17:32:00 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 May 2018 17:32:00 -0000 Subject: [GHC] #9587: Type checking with type functions introduces many type variables, which remain ambiguous. The code no longer type checks. In-Reply-To: <043.f69d596cc0abdaf73ad7a995b5399971@haskell.org> References: <043.f69d596cc0abdaf73ad7a995b5399971@haskell.org> Message-ID: <058.7f2215098212d8d7d36fbaaa003307fa@haskell.org> #9587: Type checking with type functions introduces many type variables, which remain ambiguous. The code no longer type checks. -------------------------------------+------------------------------------- Reporter: oleg | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Keywords: TypeFamilies, Resolution: | ambiguity check Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #9607 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: type family, ambiguity check => TypeFamilies, ambiguity check -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 25 17:46:48 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 May 2018 17:46:48 -0000 Subject: [GHC] #10490: Missing binder type check in coercion equality test? In-Reply-To: <045.88a8f8016d64e4642295e135154caccb@haskell.org> References: <045.88a8f8016d64e4642295e135154caccb@haskell.org> Message-ID: <060.4222a789a5b508457703b3de10f39b51@haskell.org> #10490: Missing binder type check in coercion equality test? -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => invalid Comment: As of 6746549772c5cc0ac66c0fce562f297f4d4b80a2, `coreEqCoercion2` is no more, so this issue is moot. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 25 17:50:46 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 May 2018 17:50:46 -0000 Subject: [GHC] #14857: GHC-8.4.1 release notes don't mention 'Div', 'Mod' and other type families In-Reply-To: <047.09b32790742451b61f5bc476fd1d389a@haskell.org> References: <047.09b32790742451b61f5bc476fd1d389a@haskell.org> Message-ID: <062.bceaef12aea711b9c8eaab2d625af9c9@haskell.org> #14857: GHC-8.4.1 release notes don't mention 'Div', 'Mod' and other type families -------------------------------------+------------------------------------- Reporter: chshersh | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Documentation | Version: 8.4.1-alpha3 Resolution: wontfix | Keywords: | base,documentation,div,mod,type | families,changelog,release notes Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => wontfix Comment: As mentioned above, this was by design, since this change wasn't deemed important enough to mention in the GHC release notes themselves. Closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 25 17:53:57 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 May 2018 17:53:57 -0000 Subject: [GHC] #10770: Typeable solver has strange effects In-Reply-To: <051.c272986722d18d60205f4faa0b3da2dc@haskell.org> References: <051.c272986722d18d60205f4faa0b3da2dc@haskell.org> Message-ID: <066.0794fb9128ac2abc4e83c911e4efae83@haskell.org> #10770: Typeable solver has strange effects -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 7.10.1 checker) | Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T10770{a,b} Blocked By: 5296 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => Typeable -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 25 18:44:52 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 May 2018 18:44:52 -0000 Subject: [GHC] #10778: GHC doesn't infer all constrains In-Reply-To: <046.c3c6007a301d4e9f2bfd6528e390abd4@haskell.org> References: <046.c3c6007a301d4e9f2bfd6528e390abd4@haskell.org> Message-ID: <061.bd27151cf80678ffd8031f1fd00983a8@haskell.org> #10778: GHC doesn't infer all constrains -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: 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: | -------------------------------------+------------------------------------- Comment (by dfeuer): Simon, I see pretty much the same error unless I enable `UndecidableInstances`. Should I enable that for the test, or do we still have a problem? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 25 19:11:33 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 May 2018 19:11:33 -0000 Subject: [GHC] #15078: base: Customary type class laws (e.g. for Eq) and non-abiding instances (e.g. Float) should be documented In-Reply-To: <046.a4c8c72c9e9d68a07b93ce24b1eed9ca@haskell.org> References: <046.a4c8c72c9e9d68a07b93ce24b1eed9ca@haskell.org> Message-ID: <061.5f16db28b0a16c08e1f666fda8557f06@haskell.org> #15078: base: Customary type class laws (e.g. for Eq) and non-abiding instances (e.g. Float) should be documented -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: Azel Type: feature request | Status: patch Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.4.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4736 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Expanding a bit in another direction, I think it probably makes sense to note that `Num` instances are typically expected to form rings. In fact, the `signum` and `abs` functions suggest even more structure, although I don't personally know what sort of structure that ''is''. I'd be very hesitant to document any expectations beyond the ring laws, because there are a number of exotic `Num` instances in the wild. The best-behaved law-breaker here is `Natural`, which does not have a sensible `negate` or `(-)`; it's a perfectly good semiring (more specifically, a ''rig''), but we don't have a class corresponding to that. As usual, `Float` and `Double` are truly flagrant law-breakers. It might also be worth mentioning that types that are well-behaved instances of both `Num` and `Ord` are ''not'' necessarily ordered rings. In particular, `Int`, `Word`, `Int8`, `Word8`, etc., are not ordered rings. As far as I know, the only `Num`+`Ord` instances in `base` that implement ordered rings are `Integer` and `Rational`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 25 20:48:01 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 May 2018 20:48:01 -0000 Subject: [GHC] #15183: Expose the SNat type and the natSing method In-Reply-To: <045.821e29bf2ba8cd01cfe0645e4dabde38@haskell.org> References: <045.821e29bf2ba8cd01cfe0645e4dabde38@haskell.org> Message-ID: <060.356bbef186d56e18ea9f1990a4ebb63d@haskell.org> #15183: Expose the SNat type and the natSing method -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): This was a design decision. In 2012 or so, Iavor was developing the TypeLits interface simultaneously with my development of singletons. We wanted to have one `Sing`, shared between the TypeLits stuff (built into GHC) and the singletons stuff (external). But the design considerations pulled at each other -- especially because `singletons` could make changes much more quickly than GHC could. So, instead of having built-in singletons and external singletons, it was decided to hide the built-in ones. Maybe now that we have more experience, this decision could be updated... but I still think that introducing any singletons into `base` will start a chain reaction of other feature requests. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 25 21:21:13 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 May 2018 21:21:13 -0000 Subject: [GHC] #15183: Expose the SNat type and the natSing method In-Reply-To: <045.821e29bf2ba8cd01cfe0645e4dabde38@haskell.org> References: <045.821e29bf2ba8cd01cfe0645e4dabde38@haskell.org> Message-ID: <060.eba8787f7c645f2ab1fe4cf39a973ac5@haskell.org> #15183: Expose the SNat type and the natSing method -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): goldfire, there are already two singletons for these, but one is uncomfortably buried where we need `unsafeCoerce` to get at it. Since we have built-in support for `Nat`, `Symbol`, `KnownNat`, and `KnownSymbol`, I don't really see the slippery slope. `singletons` should be able to use a newtype instance around the one in `base`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri May 25 22:57:44 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 May 2018 22:57:44 -0000 Subject: [GHC] #15186: ghc 8.4.2 panic in profiling build Message-ID: <045.764163a11088d02a8878689da6d8a04b@haskell.org> #15186: ghc 8.4.2 panic in profiling build -------------------------------------+------------------------------------- Reporter: kquick | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When building our crucible-llvm library (https://github.com/GaloisInc/crucible) with profiling enabled, we encounter the following: {{{ [19 of 21] Compiling Lang.Crucible.LLVM.Translation ( src/Lang/Crucible/LLVM/Translation.hs, dist/build/Lang/Crucible/LLVM/Translation.p_o ) ghc: panic! (the 'impossible' happened) (GHC version 8.4.2 for x86_64-unknown-linux): isUnliftedType r_a4IqS :: TYPE rep_a4IqR Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1939:10 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Procedure to reproduce: {{{ $ git clone https://github.com/GaloisInc/crucible $ cd crucible/crucible-llvm $ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.4.2 $ cabal --version cabal-install version 2.0.0.1 compiled using version 2.0.1.0 of the Cabal library $ cabal configure --enable-library-profiling $ cabal build }}} Note: the llvm-pretty dependency on Hackage is not compatible with GHC 8.4.2; use the latest from the github repo at http://github.com/elliottt /llvm-pretty. The crucible and what4 dependencies come from sibling subdirectories in the same crucible checkout. This builds successfully when using GHC 8.2.2 instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 02:24:45 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 02:24:45 -0000 Subject: [GHC] #15186: ghc 8.4.2 panic in profiling build In-Reply-To: <045.764163a11088d02a8878689da6d8a04b@haskell.org> References: <045.764163a11088d02a8878689da6d8a04b@haskell.org> Message-ID: <060.29d980bef8820347c1a027f5105ebfc0@haskell.org> #15186: ghc 8.4.2 panic in profiling build -------------------------------------+------------------------------------- Reporter: kquick | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.4.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * component: Compiler => Profiling Comment: I can trim this down to two modules, at least: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE PatternSynonyms #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE ViewPatterns #-} module Foo (Ctx, Assignment, pattern EmptyAssn, pattern (:>)) where import Data.Kind (Type) import Unsafe.Coerce (unsafeCoerce) data Ctx k = EmptyCtx | Ctx k ::> k type SingleCtx x = 'EmptyCtx '::> x type family (<+>) (x :: Ctx k) (y :: Ctx k) :: Ctx k where x <+> 'EmptyCtx = x x <+> (y '::> e) = (x <+> y) '::> e data Height = Zero | Succ Height data BinomialTree (h::Height) (f :: k -> Type) :: Ctx k -> Type where Empty :: BinomialTree h f 'EmptyCtx PlusOne :: !Int -> !(BinomialTree ('Succ h) f x) -> !(BalancedTree h f y) -> BinomialTree h f (x <+> y) PlusZero :: !Int -> !(BinomialTree ('Succ h) f x) -> BinomialTree h f x newtype Assignment (f :: k -> *) (ctx :: Ctx k) = Assignment (BinomialTree 'Zero f ctx) data AssignView f ctx where AssignEmpty :: AssignView f 'EmptyCtx AssignExtend :: Assignment f ctx -> f tp -> AssignView f (ctx '::> tp) data DropResult f (ctx :: Ctx k) where DropEmpty :: DropResult f 'EmptyCtx DropExt :: BinomialTree 'Zero f x -> f y -> DropResult f (x '::> y) data BalancedTree h (f :: k -> Type) (p :: Ctx k) where BalLeaf :: !(f x) -> BalancedTree 'Zero f (SingleCtx x) BalPair :: !(BalancedTree h f x) -> !(BalancedTree h f y) -> BalancedTree ('Succ h) f (x <+> y) tsize :: BinomialTree h f a -> Int tsize Empty = 0 tsize (PlusOne s _ _) = 2*s+1 tsize (PlusZero s _) = 2*s bal_drop :: forall h f x y . BinomialTree h f x -> BalancedTree h f y -> DropResult f (x <+> y) bal_drop t (BalLeaf e) = DropExt t e bal_drop t (BalPair x y) = unsafeCoerce (bal_drop (PlusOne (tsize t) (unsafeCoerce t) x) y) bin_drop :: forall h f ctx . BinomialTree h f ctx -> DropResult f ctx bin_drop Empty = DropEmpty bin_drop (PlusZero _ u) = bin_drop u bin_drop (PlusOne s t u) = let m = case t of Empty -> Empty _ -> PlusZero s t in bal_drop m u viewAssign :: forall f ctx . Assignment f ctx -> AssignView f ctx viewAssign (Assignment x) = case bin_drop x of DropEmpty -> AssignEmpty DropExt t v -> AssignExtend (Assignment t) v pattern EmptyAssn :: () => ctx ~ 'EmptyCtx => Assignment f ctx pattern EmptyAssn <- (viewAssign -> AssignEmpty) pattern (:>) :: () => ctx' ~ (ctx '::> tp) => Assignment f ctx -> f tp -> Assignment f ctx' pattern (:>) a v <- (viewAssign -> AssignExtend a v) }}} {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE PatternSynonyms #-} module Bar (pattern PointerExpr) where import Foo ------------------------------------------------------------------------------- pattern PointerExpr :: Expr tp pattern PointerExpr <- App (RollRecursive (EmptyAssn :> BVRepr) (App _)) ------------------------------------------------------------------------------- data CrucibleType where RecursiveType :: Ctx CrucibleType -> CrucibleType data TypeRepr (tp :: CrucibleType) where BVRepr :: TypeRepr tp TypeReprDummy :: TypeRepr tp data App (f :: CrucibleType -> *) (tp :: CrucibleType) where RollRecursive :: !(Assignment TypeRepr ctx) -> !(Expr tp) -> App f ('RecursiveType ctx) data Expr (tp :: CrucibleType) = App !(App Expr tp) | ExprDummy }}} {{{ $ /opt/ghc/8.4.2/bin/ghc -fforce-recomp -prof -fprof-auto -O Bar.hs [1 of 2] Compiling Foo ( Foo.hs, Foo.o ) [2 of 2] Compiling Bar ( Bar.hs, Bar.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.4.2 for x86_64-unknown-linux): isUnliftedType r_a22f :: TYPE rep_a22e Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1939:10 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug $ /opt/ghc/head/bin/ghc -fforce-recomp -prof -fprof-auto -O Bar.hs [1 of 2] Compiling Foo ( Foo.hs, Foo.o ) [2 of 2] Compiling Bar ( Bar.hs, Bar.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.5.20180501 for x86_64-unknown-linux): isUnliftedType r_a256 :: TYPE rep_a255 Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1162:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1922:10 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 05:51:53 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 05:51:53 -0000 Subject: [GHC] #15105: `typecheckModule` from GHC API crashes on MacOS for files with TH In-Reply-To: <050.a57b50b77df5fd7c6386ac1485c8460f@haskell.org> References: <050.a57b50b77df5fd7c6386ac1485c8460f@haskell.org> Message-ID: <065.5f9f013cc9bac8f186e9ab196b5507c9@haskell.org> #15105: `typecheckModule` from GHC API crashes on MacOS for files with TH ----------------------------------+---------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHC API | Version: 8.4.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+---------------------------------------- Comment (by lerkok): I can confirm that the workaround @harpocrates is describing works for me. (In particular, the doctest package on Mac.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 06:59:02 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 06:59:02 -0000 Subject: [GHC] #15182: Lazier Semigroup instance for Maybe In-Reply-To: <049.b98d5b58497e8723252874a5a0f696f8@haskell.org> References: <049.b98d5b58497e8723252874a5a0f696f8@haskell.org> Message-ID: <064.df3fe4d849709334d2dcc226057780b9@haskell.org> #15182: Lazier Semigroup instance for Maybe -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by oerjan): * cc: oerjan (added) Comment: The last version is ''not'' equivalent - it doesn't produce `Just` until the right argument has been evaluated. For example, with the former, I think `foldMap (Just . (:[])) [1..] = Just [1..]`, but with the latter (and with the current one) it diverges. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 08:05:10 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 08:05:10 -0000 Subject: [GHC] #15038: Memory Corruption (strange closure type) In-Reply-To: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> References: <049.b8a18bd60762ebaf32be38405c443d7c@haskell.org> Message-ID: <064.524e4f9ff2f3f2fce987742d02c05d24@haskell.org> #15038: Memory Corruption (strange closure type) -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.4.3 Component: Compiler | Version: 8.4.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #9718 | Differential Rev(s): Phab:D4680 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ömer Sinan Ağacan ): In [changeset:"11eed2f41f7a1ad461ab0717d2e4e46d0cca0f03/ghc" 11eed2f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="11eed2f41f7a1ad461ab0717d2e4e46d0cca0f03" testsuite: Don't rely on find command in T15038 Test Plan: Validate Reviewers: int-index, osa1 Reviewed By: osa1 Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15038 Differential Revision: https://phabricator.haskell.org/D4723 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 08:24:57 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 08:24:57 -0000 Subject: [GHC] #11786: Need -fno-print-explicit-runtime-reps to work on IfaceType, else RuntimeRep leaks In-Reply-To: <046.943657e3f9ed3d83fd8aca1ffc9a9fa0@haskell.org> References: <046.943657e3f9ed3d83fd8aca1ffc9a9fa0@haskell.org> Message-ID: <061.a64cdffe6f3c942b2422290efb31a595@haskell.org> #11786: Need -fno-print-explicit-runtime-reps to work on IfaceType, else RuntimeRep leaks -------------------------------------+------------------------------------- Reporter: simonpj | Owner: sighingnow Type: bug | Status: patch Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13275, #15181 | Differential Rev(s): Phab:D4733 Wiki Page: | -------------------------------------+------------------------------------- Comment (by sighingnow): I have just noticed that ticket:11376#comment:34 has already been implemented by Phab:2136, via :type +v. I have revised Phab:D4733 to fix `-fprint-explicit-runtime-reps` only. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 10:00:49 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 10:00:49 -0000 Subject: [GHC] #15187: HEAD: Validate failure when not TABLES_NEXT_TO_CODE Message-ID: <047.0475616412dd439857a1edcf6a1fa59f@haskell.org> #15187: HEAD: Validate failure when not TABLES_NEXT_TO_CODE -------------------------------------+------------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- On powerpc64 validating HEAD I see the following failure: {{{ libraries/ghci/GHCi/InfoTable.hsc:323:20: error: [-Wunused-matches, -Werror=unused-matches] Defined but not used: ‘ex_ptr’ | 323 | pokeConItbl wr_ptr ex_ptr itbl = do | ^^^^^^ libraries/ghci/ghc.mk:4: recipe for target 'libraries/ghci/dist- install/build/GHCi/InfoTable.o' failed }}} Patch is coming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 10:01:07 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 10:01:07 -0000 Subject: [GHC] #15187: HEAD: Validate failure when not TABLES_NEXT_TO_CODE In-Reply-To: <047.0475616412dd439857a1edcf6a1fa59f@haskell.org> References: <047.0475616412dd439857a1edcf6a1fa59f@haskell.org> Message-ID: <062.60c77a566a82a18beeb1c1c3c3684716@haskell.org> #15187: HEAD: Validate failure when not TABLES_NEXT_TO_CODE -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * owner: (none) => trommler -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 12:58:42 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 12:58:42 -0000 Subject: [GHC] #14777: panic when using a function defined in terms of `error` In-Reply-To: <045.edfc759cf3fa890282fee96e32a2a8f2@haskell.org> References: <045.edfc759cf3fa890282fee96e32a2a8f2@haskell.org> Message-ID: <060.76d5e54cb96cd914740514277fa40a75@haskell.org> #14777: panic when using a function defined in terms of `error` -------------------------------------+------------------------------------- Reporter: zilinc | Owner: simonpj Type: bug | Status: merge Priority: normal | Milestone: 8.4.3 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * milestone: 8.6.1 => 8.4.3 Comment: This was never merged to GHC 8.4.2. Is it slated for 8.4.3, or should this just be closed? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 13:07:21 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 13:07:21 -0000 Subject: [GHC] #7543: Constraint synonym instances In-Reply-To: <047.0a7aca76eb47f7ddaed31dae35ffdc3f@haskell.org> References: <047.0a7aca76eb47f7ddaed31dae35ffdc3f@haskell.org> Message-ID: <062.4950a57b6a79dc1ce9f3b868369c3d21@haskell.org> #7543: Constraint synonym instances -------------------------------------+------------------------------------- Reporter: monoidal | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13267 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #13267 Comment: In #13267, we decided to simply disallow instances for constraint synonyms. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 13:45:47 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 13:45:47 -0000 Subject: [GHC] #11498: GHC requires kind-polymorphic signatures on class head In-Reply-To: <047.c869cb625243c8891f031146b4e58720@haskell.org> References: <047.c869cb625243c8891f031146b4e58720@haskell.org> Message-ID: <062.bf4b89c0c6b960547e52b9e146970a10@haskell.org> #11498: GHC requires kind-polymorphic signatures on class head -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2-rc2 checker) | Resolution: | Keywords: 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: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): This is rather strange. Here is a slightly more compact example: {{{#!hs {-# LANGUAGE PolyKinds #-} module Prog1 where import Data.Proxy class C (a :: k) where c :: Proxy a -> Proxy (b :: k) }}} Let's see what GHCi thinks the type of `c` is: {{{ λ> :i C class C (a :: k) where c :: forall (b :: k). Proxy a -> Proxy b }}} So far, so good. But if you move the kind signature: {{{#!hs {-# LANGUAGE PolyKinds #-} module Prog2 where import Data.Proxy class C a where c :: Proxy (a :: k) -> Proxy (b :: k) }}} Then the type changes! {{{ λ> :i C class C (a :: k) where c :: forall k1 (b :: k1). Proxy a -> Proxy b }}} All of a sudden, the kinds of `a` and `b` have become entirely different. To add to the strangeness, `Prog2` doesn't compile at all on GHC HEAD: {{{ $ /opt/ghc/head/bin/ghci Prog2.hs GHCi, version 8.5.20180501: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Prog2 ( Prog2.hs, interpreted ) Prog2.hs:7:15: error: • Expected kind ‘k’, but ‘a’ has kind ‘k0’ • In the first argument of ‘Proxy’, namely ‘(a :: k)’ In the type signature: c :: Proxy (a :: k) -> Proxy (b :: k) In the class declaration for ‘C’ | 7 | c :: Proxy (a :: k) -> Proxy (b :: k) | ^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 13:57:24 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 13:57:24 -0000 Subject: [GHC] #12093: Wrong argument count in error message with TypeApplications In-Reply-To: <042.a2f0b0d456bcb1b521ee22a5876338d5@haskell.org> References: <042.a2f0b0d456bcb1b521ee22a5876338d5@haskell.org> Message-ID: <057.0ec69f1de79d0ba213afa1c58f9fedcd@haskell.org> #12093: Wrong argument count in error message with TypeApplications -------------------------------------+------------------------------------- Reporter: kwf | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: duplicate | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #13902 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #13902 Comment: This was fixed in #13902. The error message now reads: {{{ Bug.hs:5:9: error: • Couldn't match expected type ‘Bool -> t’ with actual type ‘Bool’ • The expression ‘id @Bool’ is applied to two arguments, but its type ‘Bool -> Bool’ has only one In the expression: id @Bool True False In an equation for ‘wrong’: wrong = id @Bool True False • Relevant bindings include wrong :: t (bound at Bug.hs:5:1) | 5 | wrong = id @Bool True False | ^^^^^^^^^^^^^^^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 14:00:03 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 14:00:03 -0000 Subject: [GHC] #13853: TypeApplications and record syntax don't mix In-Reply-To: <050.02c1b6e1840fb2482585dba240a7dea1@haskell.org> References: <050.02c1b6e1840fb2482585dba240a7dea1@haskell.org> Message-ID: <065.9c67a839fdf7b319bcec0ad0461010ce@haskell.org> #13853: TypeApplications and record syntax don't mix -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: wontfix | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => wontfix Comment: I've lost interest in this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 14:05:39 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 14:05:39 -0000 Subject: [GHC] #12092: Out-of-scope variable leads to type error, not scope error In-Reply-To: <042.23e7528a6587761bdab9893e3f2305c4@haskell.org> References: <042.23e7528a6587761bdab9893e3f2305c4@haskell.org> Message-ID: <057.a4c7af487591f83385202d4e7aab8d02@haskell.org> #12092: Out-of-scope variable leads to type error, not scope error -------------------------------------+------------------------------------- Reporter: kwf | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: fixed | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #13834 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * keywords: => TypeApplications * resolution: => fixed * related: => #13834 Comment: In GHC 8.4, you do in fact get a "Variable not in scope" error: {{{ Bug.hs:5:7: error: • Variable not in scope: spam • Perhaps you meant ‘span’ (imported from Prelude) | 5 | huh = spam @Int | ^^^^ Bug.hs:5:7: error: • Cannot apply expression of type ‘t1’ to a visible type argument ‘Int’ • In the expression: spam @Int In an equation for ‘huh’: huh = spam @Int | 5 | huh = spam @Int | ^^^^^^^^^ }}} Of course, there's still the issue that the second part of the error message still appears. But that is the subject of #13834, so I'll close this ticket in favor of that one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 14:15:40 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 14:15:40 -0000 Subject: [GHC] #12451: TemplateHaskell and Data.Typeable - tcIfaceGlobal (local): not found In-Reply-To: <047.1d9361812b982e579fc60f1fc0d6ed94@haskell.org> References: <047.1d9361812b982e579fc60f1fc0d6ed94@haskell.org> Message-ID: <062.38b58b6964ba843cdc01941f47427fad@haskell.org> #12451: TemplateHaskell and Data.Typeable - tcIfaceGlobal (local): not found -------------------------------------+------------------------------------- Reporter: mkloczko | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: | TemplateHaskell, Typeable Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): In GHC 8.4 and HEAD, the error message has changed: {{{ $ /opt/ghc/head/bin/ghc -fforce-recomp Main.hs [1 of 2] Compiling TH ( TH.hs, TH.o ) [2 of 2] Compiling Main ( Main.hs, Main.o ) GHC error in desugarer lookup in Main: attempting to use module ‘main:Main’ (Main.hs) which is not loaded }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 14:17:47 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 14:17:47 -0000 Subject: [GHC] #11474: incorrect redundant-constraints warning In-Reply-To: <042.2e15408ecc3253cf7591957da36697cd@haskell.org> References: <042.2e15408ecc3253cf7591957da36697cd@haskell.org> Message-ID: <057.005ba1a14fb4daf7db2bb6d66e2e0663@haskell.org> #11474: incorrect redundant-constraints warning -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | tests/typecheck/should_compile/T11474.hs Blocked By: | Blocking: Related Tickets: #10100 | Differential Rev(s): Phab:D4739 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sighingnow): * status: new => patch * testcase: => tests/typecheck/should_compile/T11474.hs * differential: => Phab:D4739 * related: => #10100 Comment: This is indeed a duplicate of #10100, which was fixed in 10fab31211961c9200d230556ec7742e07a6c831. However 6eabb6ddb7c53784792ee26b1e0657bde7eee7fb introduced this regression. Now Phab:D4739 should fix this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 14:17:55 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 14:17:55 -0000 Subject: [GHC] #12452: TemplateHaskell - variables in top level splices and loading modules. In-Reply-To: <047.4bfcfbe0129fd7dc7c290b050460ebc2@haskell.org> References: <047.4bfcfbe0129fd7dc7c290b050460ebc2@haskell.org> Message-ID: <062.a4492b93b5ca8db85ce1223fe27f8d88@haskell.org> #12452: TemplateHaskell - variables in top level splices and loading modules. -------------------------------------+------------------------------------- Reporter: mkloczko | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: | TemplateHaskell Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: #12451 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #12451 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 14:19:11 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 14:19:11 -0000 Subject: [GHC] #12514: Can't write unboxed sum type constructors in prefix form In-Reply-To: <050.841e8669fe47472e53beeefaf89bc022@haskell.org> References: <050.841e8669fe47472e53beeefaf89bc022@haskell.org> Message-ID: <065.f01c9fca7eb39885fa0b6b96d85a019a@haskell.org> #12514: Can't write unboxed sum type constructors in prefix form -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Parser) | Resolution: wontfix | Keywords: UnboxedSums Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => wontfix Comment: I've lost interest in this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 14:21:55 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 14:21:55 -0000 Subject: [GHC] #12540: RFC: Allow not quantifying every top-level quantifiee In-Reply-To: <051.1956280adad0090e4523e93fefe0fc52@haskell.org> References: <051.1956280adad0090e4523e93fefe0fc52@haskell.org> Message-ID: <066.cfeb4d9c339c7569f6f9c2e432bc1732@haskell.org> #12540: RFC: Allow not quantifying every top-level quantifiee -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14245 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I'm not sure I'd like to give up the `forall`-or-nothing rule. But note that there //is// a workaround here: just use extra parentheses: {{{#!hs const_ :: (forall a. a -> b -> a) const_ = const }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 14:18:10 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 14:18:10 -0000 Subject: [GHC] #12451: TemplateHaskell and Data.Typeable - tcIfaceGlobal (local): not found In-Reply-To: <047.1d9361812b982e579fc60f1fc0d6ed94@haskell.org> References: <047.1d9361812b982e579fc60f1fc0d6ed94@haskell.org> Message-ID: <062.dcd8b2300fafd6df298dd58e900c4dd3@haskell.org> #12451: TemplateHaskell and Data.Typeable - tcIfaceGlobal (local): not found -------------------------------------+------------------------------------- Reporter: mkloczko | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: | TemplateHaskell, Typeable Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: #12452 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #12452 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 14:30:14 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 14:30:14 -0000 Subject: [GHC] #11766: Lazy application gives "No instance" error while strict application works In-Reply-To: <047.6457ae8316e008d1f2f63e8e30939ea4@haskell.org> References: <047.6457ae8316e008d1f2f63e8e30939ea4@haskell.org> Message-ID: <062.8da90ad68f1827578216b68c49bb725f@haskell.org> #11766: Lazy application gives "No instance" error while strict application works -------------------------------------+------------------------------------- Reporter: MichaelK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"72835ff223e103c8a187f782146e5f452d74aef6/ghc" 72835ff2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="72835ff223e103c8a187f782146e5f452d74aef6" Add regression test for #11766 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 14:38:49 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 14:38:49 -0000 Subject: [GHC] #12601: explicit foralls do not distinguish applicable types In-Reply-To: <044.1491c1ceb391983b8df70a1a35b67802@haskell.org> References: <044.1491c1ceb391983b8df70a1a35b67802@haskell.org> Message-ID: <059.2aead15b23f35ddd131bba65999063e5@haskell.org> #12601: explicit foralls do not distinguish applicable types -------------------------------------+------------------------------------- Reporter: dmwit | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13401 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * keywords: => TypeApplications * resolution: => fixed * related: => #13401 Comment: The users' guide documentation for `TypeApplications` has been improved since 8.0.1, and that section now properly mentions that if you wish to learn which types are available for visible type application, then you should use `:type +v`, not `:type`. See https://downloads.haskell.org/~ghc/8.4.2/docs/html/users_guide/glasgow_exts.html #visible-type-application (the result of #13401). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 14:45:23 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 14:45:23 -0000 Subject: [GHC] #12612: Allow kinds of associated types to depend on earlier associated types In-Reply-To: <051.03b4bda1b1ebc27d0a28baf47d735e88@haskell.org> References: <051.03b4bda1b1ebc27d0a28baf47d735e88@haskell.org> Message-ID: <066.e7ceeb1a5a618979da3084cc86843413@haskell.org> #12612: Allow kinds of associated types to depend on earlier associated types -------------------------------------+------------------------------------- Reporter: davemenendez | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11962 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #11962 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 14:48:01 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 14:48:01 -0000 Subject: [GHC] #12794: Out of scope error not reported In-Reply-To: <046.500f74be41362996be42758d4a2128d8@haskell.org> References: <046.500f74be41362996be42758d4a2128d8@haskell.org> Message-ID: <061.ebbfe7de34fc502babbec7e04a50e5bb@haskell.org> #12794: Out of scope error not reported -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13834 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => TypeApplications * related: => #13834 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 14:48:34 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 14:48:34 -0000 Subject: [GHC] #13834: Error cascade with type applications In-Reply-To: <049.1249ca55bb94d4476098b14993c34065@haskell.org> References: <049.1249ca55bb94d4476098b14993c34065@haskell.org> Message-ID: <064.44642d83f8c8ea05be1c51648422ecb1@haskell.org> #13834: Error cascade with type applications -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | TypeApplications, TypeErrorMessages Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12794 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #12794 Comment: See #12794 for the `-fdefer-type-errors` version of this issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 14:55:42 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 14:55:42 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2312854=3A_ghc-8_prints_mangled_names?= =?utf-8?b?IGluIGVycm9yIG1lc3NhZ2U6IOKAmEdIQy5CYXNlLiRkbTwk4oCZ?= In-Reply-To: <045.b2961fab558879fceba382b527980ad8@haskell.org> References: <045.b2961fab558879fceba382b527980ad8@haskell.org> Message-ID: <060.90bc9d2f6e8c1d430976c33410a0f17d@haskell.org> #12854: ghc-8 prints mangled names in error message: ‘GHC.Base.$dm<$’ -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10087, #13755 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #10087, #13755 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 15:03:40 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 15:03:40 -0000 Subject: [GHC] #12922: Kind classes compile with PolyKinds In-Reply-To: <045.cda8d73aa7f5c75c71cb112094b7aabc@haskell.org> References: <045.cda8d73aa7f5c75c71cb112094b7aabc@haskell.org> Message-ID: <060.cff1bae2626af255537d024865de727c@haskell.org> #12922: Kind classes compile with PolyKinds -------------------------------------+------------------------------------- Reporter: Tritlo | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => TypeInType -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 15:13:18 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 15:13:18 -0000 Subject: [GHC] #13118: let binding tuple of lenses error not an expression In-Reply-To: <047.bc082c9ffee71f7ca4d504d3df16965b@haskell.org> References: <047.bc082c9ffee71f7ca4d504d3df16965b@haskell.org> Message-ID: <062.d0d2fc0dbf162ca49e4289c8582b111d@haskell.org> #13118: let binding tuple of lenses error not an expression -------------------------------------+------------------------------------- Reporter: codygman | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: worksforme | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: infoneeded => closed * resolution: => worksforme Comment: Unfortunately, there's not much we can do here, since the original reporter never followed up with the code they were using. Moreover, they claim that this was fixed in GHC HEAD a while back, so I'll optimistically close this. (Do reopen if this still occurs.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 15:16:27 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 15:16:27 -0000 Subject: [GHC] #10789: Notify user when a kind mismatch holds up a type family reduction In-Reply-To: <047.282dd8bb976bc76373d556a5e980ac6e@haskell.org> References: <047.282dd8bb976bc76373d556a5e980ac6e@haskell.org> Message-ID: <062.17ea0628a586d55053c2cbfcb607e66a@haskell.org> #10789: Notify user when a kind mismatch holds up a type family reduction -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: newcomer, | TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13192 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #13192 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 15:22:14 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 15:22:14 -0000 Subject: [GHC] #13726: Declaring GADT constructor and associated data family with the same name gives weird error In-Reply-To: <046.d3912534e6b0f207167735f40f0f6a2a@haskell.org> References: <046.d3912534e6b0f207167735f40f0f6a2a@haskell.org> Message-ID: <061.8ec0f964e4df4ca38f6af064d3cbc2cb@haskell.org> #13726: Declaring GADT constructor and associated data family with the same name gives weird error -------------------------------------+------------------------------------- Reporter: mrkgnao | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Any update on this, mkrgnao? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 15:28:23 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 15:28:23 -0000 Subject: [GHC] #15187: HEAD: Validate failure when not TABLES_NEXT_TO_CODE In-Reply-To: <047.0475616412dd439857a1edcf6a1fa59f@haskell.org> References: <047.0475616412dd439857a1edcf6a1fa59f@haskell.org> Message-ID: <062.14227744297db179674e99cf0c7861f0@haskell.org> #15187: HEAD: Validate failure when not TABLES_NEXT_TO_CODE -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Yes, this is probably another configuration which we should validate periodically. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 15:40:07 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 15:40:07 -0000 Subject: [GHC] #14172: GHC hangs during type-checking In-Reply-To: <052.bf5c9e1d9ab7651e78fa2a1dd7315260@haskell.org> References: <052.bf5c9e1d9ab7651e78fa2a1dd7315260@haskell.org> Message-ID: <067.328b2ccbebd8447d2783b1e49997175a@haskell.org> #14172: GHC hangs during type-checking -------------------------------------+------------------------------------- Reporter: lightandlight | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"00f7e2850396c69938ddb017bc8d87ca1ecd882a/ghc" 00f7e285/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="00f7e2850396c69938ddb017bc8d87ca1ecd882a" Add regression test for #14172 Commit 433b80dec1cfef787fc1327a9eada1791b11c12e fixed #14172. Let's add a regression test to ensure that it stays fixed. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 15:41:50 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 15:41:50 -0000 Subject: [GHC] #14172: GHC hangs during type-checking In-Reply-To: <052.bf5c9e1d9ab7651e78fa2a1dd7315260@haskell.org> References: <052.bf5c9e1d9ab7651e78fa2a1dd7315260@haskell.org> Message-ID: <067.504ddd7faf4cb9fec7a01105b786c2b5@haskell.org> #14172: GHC hangs during type-checking -------------------------------------+------------------------------------- Reporter: lightandlight | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Compile-time | Test Case: crash or panic | polykinds/T14172 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * testcase: => polykinds/T14172 * resolution: => fixed Comment: Oops, I forgot about this! I just committed a regression test, so this can be closed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 15:56:08 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 15:56:08 -0000 Subject: [GHC] #14246: Probably AllowAmbiguousTypes + UndecidableInstances + TypeInType In-Reply-To: <046.8b3b9e984fd26376daba4155f9345b3f@haskell.org> References: <046.8b3b9e984fd26376daba4155f9345b3f@haskell.org> Message-ID: <061.dd11fc047c08d6726e398971e4195294@haskell.org> #14246: Probably AllowAmbiguousTypes + UndecidableInstances + TypeInType -------------------------------------+------------------------------------- Reporter: Toricon | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13271 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I was able to reverse engineer this. Here is a program which panics on GHC 8.0.2: {{{#!hs {-# LANGUAGE RankNTypes, GADTs, TypeOperators, PolyKinds, DataKinds, TypeFamilies, AllowAmbiguousTypes, UndecidableInstances, TypeInType #-} module MCS.Function where -- import MCS.Core --import MCS.Value import Data.Kind -- necessary for * data Nat = Z | S Nat data Vect :: Nat -> Type -> Type where Nil :: Vect Z a Cons :: a -> Vect n a -> Vect (S n) a data Label a = Label a data L type family KLN (n :: k) :: Nat where KLN (f :: v -> k) = S (KLN (forall t. f t)) KLN (f :: *) = Z type family Reveal (n :: k) (l :: Vect (KLN n) L) :: * where Reveal (f :: v -> k) (Cons (Label (t :: v)) l) = Reveal (f t) l Reveal (a :: *) Nil = a }}} {{{ $ /opt/ghc/8.0.2/bin/ghc Bug.hs [1 of 1] Compiling MCS.Function ( Bug.hs, Bug.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): isInjectiveTyCon sees a TcTyCon KLN }}} However, this does //not// panic on GHC 8.2.2 and later, so I believe that this has a symptom in common with #13271. It's different enough that it warrants its own test case, I believe, so I'll commit that shortly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 15:58:18 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 15:58:18 -0000 Subject: [GHC] #14246: Probably AllowAmbiguousTypes + UndecidableInstances + TypeInType In-Reply-To: <046.8b3b9e984fd26376daba4155f9345b3f@haskell.org> References: <046.8b3b9e984fd26376daba4155f9345b3f@haskell.org> Message-ID: <061.be4dd61393800a8d2238d3a410c01c97@haskell.org> #14246: Probably AllowAmbiguousTypes + UndecidableInstances + TypeInType -------------------------------------+------------------------------------- Reporter: Toricon | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13271 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"9ed7e8d6a31b96ea2f171f1ad064294ee618b032/ghc" 9ed7e8d6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9ed7e8d6a31b96ea2f171f1ad064294ee618b032" Add regression test for #14246 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 16:01:27 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 16:01:27 -0000 Subject: [GHC] #14442: InstanceSigs fails In-Reply-To: <051.92c083a904342cf57cdbf67ba298e591@haskell.org> References: <051.92c083a904342cf57cdbf67ba298e591@haskell.org> Message-ID: <066.5c5b54b9fdbf01cd1e640a287b7b6efa@haskell.org> #14442: InstanceSigs fails -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: invalid | Keywords: InstanceSigs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: infoneeded => closed * resolution: => invalid Comment: As mentioned in comment:1, this is not a bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 16:09:45 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 16:09:45 -0000 Subject: [GHC] #14761: Incorrect diagnostic for UNPACK/missing strictness In-Reply-To: <047.a9957a185a6b53ba929f1216d03f36d2@haskell.org> References: <047.a9957a185a6b53ba929f1216d03f36d2@haskell.org> Message-ID: <062.e53a611b115f501bb97943ca2b799f8b@haskell.org> #14761: Incorrect diagnostic for UNPACK/missing strictness -------------------------------------+------------------------------------- Reporter: dminuoso | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: error/warning at compile-time | typecheck/should_fail/T14761a, | typecheck/should_fail/T14761b Blocked By: | Blocking: Related Tickets: #7210 | Differential Rev(s): Phab:D4397 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * testcase: => typecheck/should_fail/T14761a, typecheck/should_fail/T14761b * resolution: => fixed * milestone: => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 16:13:42 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 16:13:42 -0000 Subject: [GHC] #14938: Pattern matching on GADT does not refine type family parameters In-Reply-To: <047.978f70ab5d3550499b5776f22c5bd354@haskell.org> References: <047.978f70ab5d3550499b5776f22c5bd354@haskell.org> Message-ID: <062.efe9643fce86be6b6e9e11b8e246ab17@haskell.org> #14938: Pattern matching on GADT does not refine type family parameters -------------------------------------+------------------------------------- Reporter: kcsongor | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Keywords: GADTs, Resolution: invalid | TypeFamilies, 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => invalid Comment: As stated in comment:6, this is by design, and not a bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 16:21:31 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 16:21:31 -0000 Subject: [GHC] #5957: signatures are too permissive In-Reply-To: <045.4902524694652305696f68f6e3527f57@haskell.org> References: <045.4902524694652305696f68f6e3527f57@haskell.org> Message-ID: <060.93d0c6a20564a1125fdb59245c898ab4@haskell.org> #5957: signatures are too permissive -------------------------------------+------------------------------------- Reporter: maeder | Owner: (none) Type: bug | Status: closed Priority: low | Milestone: ⊥ Component: Compiler (Type | Version: 7.4.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T5957 Blocked By: | Blocking: Related Tickets: #11540 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => fixed * related: => #11540 Comment: The remaining task here (rejecting `f :: Eq a => Eq b => a -> b` without a language extension) is the subject of #11540, so I'll close this in favor of that ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 16:27:57 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 16:27:57 -0000 Subject: [GHC] #14783: Initializing record with similarly named field from a different record results in warning rather than error In-Reply-To: <053.5b725cc1d4e4c8f45180bb4a879fba30@haskell.org> References: <053.5b725cc1d4e4c8f45180bb4a879fba30@haskell.org> Message-ID: <068.59af59513ae291cbd2ce6929d40aa3aa@haskell.org> #14783: Initializing record with similarly named field from a different record results in warning rather than error -------------------------------------+------------------------------------- Reporter: ulrikrasmussen | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: records | DuplicateRecordFields ORF Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: records DuplicateRecordFields => records DuplicateRecordFields ORF -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 16:31:06 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 16:31:06 -0000 Subject: [GHC] #10859: Generated Eq instance associates && wrongly In-Reply-To: <046.4f10604a3fa32deb15c9056d38ba731c@haskell.org> References: <046.4f10604a3fa32deb15c9056d38ba731c@haskell.org> Message-ID: <061.659bb59da3774d758bd095c8774568de@haskell.org> #10859: Generated Eq instance associates && wrongly -------------------------------------+------------------------------------- Reporter: nomeata | Owner: simonpj Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: deriving, | newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10858 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => deriving, newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 16:36:44 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 16:36:44 -0000 Subject: [GHC] #12447: Pretty-printing of equality `~` without parentheses In-Reply-To: <051.dba18f323b8c18d3270065a172f0294e@haskell.org> References: <051.dba18f323b8c18d3270065a172f0294e@haskell.org> Message-ID: <066.694cb1dbe6acdfe73c34cacd98f2198d@haskell.org> #12447: Pretty-printing of equality `~` without parentheses -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): It appears that this was fixed in GHC 8.2.2, since now the type signature has parentheses where it didn't before: {{{ $ ghci -XTypeApplications Bug.hs GHCi, version 8.4.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Ok, one module loaded. λ> :t deferEither @(_ ~ _) deferEither @(_ ~ _) :: (Typeable w1, Typeable w2) => proxy (w1 ~ w2) -> ((w1 ~ w2) => r) -> Either String r }}} I'll unmark the test case from its current `expected_broken` state. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 16:39:47 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 16:39:47 -0000 Subject: [GHC] #12447: Pretty-printing of equality `~` without parentheses In-Reply-To: <051.dba18f323b8c18d3270065a172f0294e@haskell.org> References: <051.dba18f323b8c18d3270065a172f0294e@haskell.org> Message-ID: <066.4fc41735d44bbd25735f4d494a4b0d8f@haskell.org> #12447: Pretty-printing of equality `~` without parentheses -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/scripts/T12447 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => ghci/scripts/T12447 * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 16:51:03 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 16:51:03 -0000 Subject: [GHC] #14989: CBE pass 2 invalidates proc points In-Reply-To: <044.fb8bf40a724d06cac113a1a4bb72ec8e@haskell.org> References: <044.fb8bf40a724d06cac113a1a4bb72ec8e@haskell.org> Message-ID: <059.101345b27f4ad3e9cc75cbcf0c9241d8@haskell.org> #14989: CBE pass 2 invalidates proc points -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: fixed | Keywords: llvm CodeGen Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #12915 #14226 | Differential Rev(s): Phab:D4417 Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * keywords: llvm => llvm CodeGen * related: 12915 14226 => #12915 #14226 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 14:28:42 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 14:28:42 -0000 Subject: [GHC] #11766: Lazy application gives "No instance" error while strict application works In-Reply-To: <047.6457ae8316e008d1f2f63e8e30939ea4@haskell.org> References: <047.6457ae8316e008d1f2f63e8e30939ea4@haskell.org> Message-ID: <062.c6012477b8404c9502976abb9c50ec02@haskell.org> #11766: Lazy application gives "No instance" error while strict application works -------------------------------------+------------------------------------- Reporter: MichaelK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Happily, this does work with HEAD. I'll commit a regression test. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 14:56:09 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 14:56:09 -0000 Subject: [GHC] #13755: GHC-8.0.2+ spits out $dm names in error messages In-Reply-To: <045.94799c1fd2792bf520b6bd3c5f2df5b1@haskell.org> References: <045.94799c1fd2792bf520b6bd3c5f2df5b1@haskell.org> Message-ID: <060.4dd2a4cd3a4a90f678bee6aad8d318c8@haskell.org> #13755: GHC-8.0.2+ spits out $dm names in error messages -------------------------------------+------------------------------------- Reporter: zilinc | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #10087, #12854 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #10087 => #10087, #12854 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 14:56:43 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 14:56:43 -0000 Subject: [GHC] #10087: DefaultSignatures: error message mentions internal name In-Reply-To: <051.aa4c4a0637fafc7e89e489be234173b6@haskell.org> References: <051.aa4c4a0637fafc7e89e489be234173b6@haskell.org> Message-ID: <066.7a9c12e51b8f55be0f566a0648809710@haskell.org> #10087: DefaultSignatures: error message mentions internal name -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.4 checker) | Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #12854, #13755 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #13755 => #12854, #13755 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 16:51:06 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 16:51:06 -0000 Subject: [GHC] #12540: RFC: Allow not quantifying every top-level quantifiee In-Reply-To: <051.1956280adad0090e4523e93fefe0fc52@haskell.org> References: <051.1956280adad0090e4523e93fefe0fc52@haskell.org> Message-ID: <066.c170f8c4a0d8703812bcdd91c4c50924@haskell.org> #12540: RFC: Allow not quantifying every top-level quantifiee -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14245 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): That's cute but doesn't bring `a` into scope in the function body. This is surprising behavior for parentheses! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 17:29:01 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 17:29:01 -0000 Subject: [GHC] #12540: RFC: Allow not quantifying every top-level quantifiee In-Reply-To: <051.1956280adad0090e4523e93fefe0fc52@haskell.org> References: <051.1956280adad0090e4523e93fefe0fc52@haskell.org> Message-ID: <066.fa97899000ef74dc6e63ed69c55e2cae@haskell.org> #12540: RFC: Allow not quantifying every top-level quantifiee -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14245 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): It's not surprising at all, if you look at it from a certain perspective. After all, in this function: {{{#!hs f :: (forall a. Proxy b -> a -> a) -> Int -> Int f g x = g Proxy x }}} Despite the fact that there's a `forall` in front of `Proxy b -> a -> a`, GHC doesn't complain that `b` is out of scope. That's because the `forall `-or-nothing rule only applies to `forall`s at the top level, which `forall a. Proxy b -> a -> a` is not. That's why `const_ :: (forall a. a -> b -> a)` is accepted, since the `forall` is similarly not at the top level. It's also why this variation is accepted: {{{#!hs const__ :: () => forall a. a -> b -> a const__ = const }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 18:20:40 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 18:20:40 -0000 Subject: [GHC] #15188: Catch cases where both branches of an if jump to the same block. Message-ID: <047.a29b3685be75fc9bbb2d148660ee8c8a@haskell.org> #15188: Catch cases where both branches of an if jump to the same block. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 (CodeGen) | Keywords: CodeGen | 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 one reason or the other sometimes we end up with if statements in Cmm where both branch targets are the same: Actual example from NoFib: {{{ u9oL: if (_c9oA::P64 != 5) goto u9p2; else goto u9p2; }}} Which eventually results in this code: {{{ _u9oL: cmpq $5,%rbx jne _u9p2 <- utterly pointless _u9p2: addq $16,%rbp jmp _c9iq }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 14:31:12 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 14:31:12 -0000 Subject: [GHC] #11766: Lazy application gives "No instance" error while strict application works In-Reply-To: <047.6457ae8316e008d1f2f63e8e30939ea4@haskell.org> References: <047.6457ae8316e008d1f2f63e8e30939ea4@haskell.org> Message-ID: <062.03dba0018075a726d9fb471abea525e3@haskell.org> #11766: Lazy application gives "No instance" error while strict application works -------------------------------------+------------------------------------- Reporter: MichaelK | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T11766 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => typecheck/should_compile/T11766 * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 14:33:55 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 14:33:55 -0000 Subject: [GHC] #12592: Explicit type signature for type classes fails In-Reply-To: <051.8583909b83ea46deb1c70aaa86a24891@haskell.org> References: <051.8583909b83ea46deb1c70aaa86a24891@haskell.org> Message-ID: <066.71591f2d246634fe02a8b1301e937b24@haskell.org> #12592: Explicit type signature for type classes fails -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => invalid Comment: As mentioned in comment:1, this is not a bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 14:41:07 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 14:41:07 -0000 Subject: [GHC] #12655: Bizarre parser problem: "Illegal bang-pattern" (something to do with CPP?) In-Reply-To: <044.6aa0c5a5e84a6a2a41bd4e78684bbb04@haskell.org> References: <044.6aa0c5a5e84a6a2a41bd4e78684bbb04@haskell.org> Message-ID: <059.a466b0f54b28e8af83d62cdf13c6d4ce@haskell.org> #12655: Bizarre parser problem: "Illegal bang-pattern" (something to do with CPP?) -------------------------------------+------------------------------------- Reporter: edsko | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.4.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => fixed Comment: This is a bug in an old version of GHC (and one that's been fixed at that), and a workaround has been documented. Closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 14:44:43 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 14:44:43 -0000 Subject: [GHC] #11962: Support induction recursion In-Reply-To: <047.045273ef2ac55a0385e215af795b4757@haskell.org> References: <047.045273ef2ac55a0385e215af795b4757@haskell.org> Message-ID: <062.4378c56f71e9dee1f9af68aee9658d9b@haskell.org> #11962: Support induction recursion -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 9269 | Blocking: Related Tickets: #12612, #13901 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #13901 => #12612, #13901 Comment: andrewthad, that particular featurette is being tracked separately at #12612. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 15:16:10 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 15:16:10 -0000 Subject: [GHC] #13192: Ambiguity Caused By PolyKind and Not Helpful Error Messages In-Reply-To: <050.480d2afbead2f75e48b089097fdf0e04@haskell.org> References: <050.480d2afbead2f75e48b089097fdf0e04@haskell.org> Message-ID: <065.3a442b9f25eaebb7a0e5905d39494191@haskell.org> #13192: Ambiguity Caused By PolyKind and Not Helpful Error Messages -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #10789 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => TypeFamilies * related: => #10789 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 15:17:59 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 15:17:59 -0000 Subject: [GHC] #13365: Notify user when adding a CUSK might help fix a type error (was: Kind-inference for poly-kinded GADTs) In-Reply-To: <047.53ccade2bc7f7794ee330b834d4cc090@haskell.org> References: <047.53ccade2bc7f7794ee330b834d4cc090@haskell.org> Message-ID: <062.6e4a54d92af4ba193c4b9ba26ba6c05c@haskell.org> #13365: Notify user when adding a CUSK might help fix a type error -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType, | CUSKs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14139, #14207 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 15:23:37 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 15:23:37 -0000 Subject: [GHC] #13746: Typeable changes in base-4.10 break ChasingBottoms's test suite In-Reply-To: <045.32f3840a089a8e740875e5633a95d4d2@haskell.org> References: <045.32f3840a089a8e740875e5633a95d4d2@haskell.org> Message-ID: <060.1a57897c0811b61402aac5bf06d1caa0@haskell.org> #13746: Typeable changes in base-4.10 break ChasingBottoms's test suite -------------------------------------+------------------------------------- Reporter: refold | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 8.2.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3605 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * resolution: => fixed Comment: This was merged into GHC 8.2.1 in commit 979cc34b03909939c007e7b719687362dbfdf153. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 15:59:08 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 15:59:08 -0000 Subject: [GHC] #14246: Probably AllowAmbiguousTypes + UndecidableInstances + TypeInType In-Reply-To: <046.8b3b9e984fd26376daba4155f9345b3f@haskell.org> References: <046.8b3b9e984fd26376daba4155f9345b3f@haskell.org> Message-ID: <061.c312939909032b1f857e1f48dfd1c34a@haskell.org> #14246: Probably AllowAmbiguousTypes + UndecidableInstances + TypeInType -------------------------------------+------------------------------------- Reporter: Toricon | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: Compile-time | Test Case: indexed- crash or panic | types/should_fail/T14246 Blocked By: | Blocking: Related Tickets: #13271 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: infoneeded => closed * testcase: => indexed-types/should_fail/T14246 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 16:21:43 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 16:21:43 -0000 Subject: [GHC] #11540: ghc accepts non-standard type without language extension In-Reply-To: <047.4af844a129b268095ee1a782d708bfe8@haskell.org> References: <047.4af844a129b268095ee1a782d708bfe8@haskell.org> Message-ID: <062.e2ab3097b7864c1175094a9343f29333@haskell.org> #11540: ghc accepts non-standard type without language extension -------------------------------------+------------------------------------- Reporter: augustss | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5957 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #5957 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 16:49:02 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 16:49:02 -0000 Subject: [GHC] #14343: bad pretty-printing of types with promoted data types In-Reply-To: <048.9dafa4d8103f25346932aca07d111b88@haskell.org> References: <048.9dafa4d8103f25346932aca07d111b88@haskell.org> Message-ID: <063.384f2e29478781510c6324c22040d438@haskell.org> #14343: bad pretty-printing of types with promoted data types -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => newcomer Comment: This is just a deficiency of GHC's pretty-printer. It should be relatively straightforward to change it such that GHC inserts a space between `'[` and `'True`. See the [http://git.haskell.org/ghc.git/blob/6a9b9b431dcc94849d14c13639eb2f713e5aa1f4:/compiler/iface/IfaceType.hs#l937 pprIfaceTyList] function, which is responsible for pretty-printing promoted lists. Note that similar considerations also apply for promoted tuple constructors: {{{ λ> f :: Proxy _ -> Proxy '( 'True, 'True); f x = x :5:12: error: • Found type wildcard ‘_’ standing for ‘'('True, 'True) :: (Bool, Bool)’ To use the inferred type, enable PartialTypeSignatures • In the type signature: f :: Proxy _ -> Proxy '( 'True, 'True) }}} So an analogous fix would be needed for the [http://git.haskell.org/ghc.git/blob/6a9b9b431dcc94849d14c13639eb2f713e5aa1f4:/compiler/iface/IfaceType.hs#l1131 pprTuple] function. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 16:28:14 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 16:28:14 -0000 Subject: [GHC] #14487: Can't Hide Field When DuplicateRecordFields Is Enabled In-Reply-To: <052.55fcb5f24afe31abafd77e2adcf88ad5@haskell.org> References: <052.55fcb5f24afe31abafd77e2adcf88ad5@haskell.org> Message-ID: <067.c87caa29fb10f66e7e63055c234e021e@haskell.org> #14487: Can't Hide Field When DuplicateRecordFields Is Enabled -------------------------------------+------------------------------------- Reporter: iansullivan88 | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: | DuplicateRecordFields ORF Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: DuplicateRecordFields => DuplicateRecordFields ORF -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 16:38:56 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 16:38:56 -0000 Subject: [GHC] #12447: Pretty-printing of equality `~` without parentheses In-Reply-To: <051.dba18f323b8c18d3270065a172f0294e@haskell.org> References: <051.dba18f323b8c18d3270065a172f0294e@haskell.org> Message-ID: <066.29377ba472d79196dd3823dccebd1120@haskell.org> #12447: Pretty-printing of equality `~` without parentheses -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"6a9b9b431dcc94849d14c13639eb2f713e5aa1f4/ghc" 6a9b9b43/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6a9b9b431dcc94849d14c13639eb2f713e5aa1f4" Mark #12447's test case as expected to pass This appears to have been fixed at some point between GHC 8.0 and 8.2. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 16:42:29 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 16:42:29 -0000 Subject: [GHC] #13833: Instances with GHC.TypeLits.Nat/Symbol should be possible without FlexibleInstances. In-Reply-To: <045.899fdc291fee22417bd4b56eb02e56da@haskell.org> References: <045.899fdc291fee22417bd4b56eb02e56da@haskell.org> Message-ID: <060.c66081ed5a1aeaa1baf36ffe688c7160@haskell.org> #13833: Instances with GHC.TypeLits.Nat/Symbol should be possible without FlexibleInstances. -------------------------------------+------------------------------------- Reporter: Hjulle | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => newcomer Comment: This should be straightforward to fix: it would just require some tweaking of the [http://git.haskell.org/ghc.git/blob/6a9b9b431dcc94849d14c13639eb2f713e5aa1f4:/compiler/typecheck/TcValidity.hs#l1116 tcInstHeadTyAppAllTyVars] function to allow something headed by a `LitTy`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 16:56:59 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 16:56:59 -0000 Subject: [GHC] #11767: Add @since annotations for base instances In-Reply-To: <046.80486230653199e8f5fef1dcd513180c@haskell.org> References: <046.80486230653199e8f5fef1dcd513180c@haskell.org> Message-ID: <061.7a9f37583ec82a92065fac976396152b@haskell.org> #11767: Add @since annotations for base instances -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 7.10.3 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11768 | Differential Rev(s): Phab:D2277, Wiki Page: | Phab:D4452 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * differential: Phab:D2277 => Phab:D2277, Phab:D4452 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 16:58:45 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 16:58:45 -0000 Subject: [GHC] #11498: GHC requires kind-polymorphic signatures on class head In-Reply-To: <047.c869cb625243c8891f031146b4e58720@haskell.org> References: <047.c869cb625243c8891f031146b4e58720@haskell.org> Message-ID: <062.8518f57c37cdac34f9ba47b471b13c1e@haskell.org> #11498: GHC requires kind-polymorphic signatures on class head -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2-rc2 checker) | Resolution: | Keywords: 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 18:21:31 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 18:21:31 -0000 Subject: [GHC] #15188: Catch cases where both branches of an if jump to the same block. In-Reply-To: <047.a29b3685be75fc9bbb2d148660ee8c8a@haskell.org> References: <047.a29b3685be75fc9bbb2d148660ee8c8a@haskell.org> Message-ID: <062.ec5f48e89f20096e8496bcb453c82ae5@haskell.org> #15188: Catch cases where both branches of an if jump to the same block. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 (CodeGen) | Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * cc: jmct (added) * owner: (none) => AndreasK -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 19:09:46 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 19:09:46 -0000 Subject: [GHC] #15187: HEAD: Validate failure when not TABLES_NEXT_TO_CODE In-Reply-To: <047.0475616412dd439857a1edcf6a1fa59f@haskell.org> References: <047.0475616412dd439857a1edcf6a1fa59f@haskell.org> Message-ID: <062.c87001b730b126cf3fc954fe88805763@haskell.org> #15187: HEAD: Validate failure when not TABLES_NEXT_TO_CODE -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4741 Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * status: new => patch * differential: => Phab:D4741 Comment: The patch fixes the build. Some tests fail on powerpc64, most of the failing tests are GHCi tests timing out. I'll file new tickets for those failing tests. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 20:32:54 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 20:32:54 -0000 Subject: [GHC] #15188: Catch cases where both branches of an if jump to the same block. In-Reply-To: <047.a29b3685be75fc9bbb2d148660ee8c8a@haskell.org> References: <047.a29b3685be75fc9bbb2d148660ee8c8a@haskell.org> Message-ID: <062.e766309ba8a7cadd02823d5d785abc70@haskell.org> #15188: Catch cases where both branches of an if jump to the same block. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 (CodeGen) | Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 20:33:16 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 20:33:16 -0000 Subject: [GHC] #15188: Catch cases where both branches of an if jump to the same block. In-Reply-To: <047.a29b3685be75fc9bbb2d148660ee8c8a@haskell.org> References: <047.a29b3685be75fc9bbb2d148660ee8c8a@haskell.org> Message-ID: <062.2d9579765dbd0dba676ff852974470f4@haskell.org> #15188: Catch cases where both branches of an if jump to the same block. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 (CodeGen) | Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4740 Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * differential: => Phab:D4740 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 21:21:10 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 21:21:10 -0000 Subject: [GHC] #14777: panic when using a function defined in terms of `error` In-Reply-To: <045.edfc759cf3fa890282fee96e32a2a8f2@haskell.org> References: <045.edfc759cf3fa890282fee96e32a2a8f2@haskell.org> Message-ID: <060.7abf9c16561c8a547fb444c16660b3f1@haskell.org> #14777: panic when using a function defined in terms of `error` -------------------------------------+------------------------------------- Reporter: zilinc | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: 8.4.3 => 8.6.1 Comment: Well, 8.4.3 is done (although I haven't had the time to finalize it yet) and didn't have this commit, so let's closel -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat May 26 22:13:42 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 May 2018 22:13:42 -0000 Subject: [GHC] #14662: Partial type signatures + mutual recursion = confusion In-Reply-To: <047.3b31857d5e13c83eb10eb7b983365dfd@haskell.org> References: <047.3b31857d5e13c83eb10eb7b983365dfd@haskell.org> Message-ID: <062.d8e6a2c9a0d9ee35162b7d15d70e347f@haskell.org> #14662: Partial type signatures + mutual recursion = confusion -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | PartialTypeSignatures Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mnislaih): How about polymorphic recursion with a type wildcard only in the constraint ? The minimal failing example I have is: {{{ data App a where Pure :: a -> App a App :: App (a -> b) -> App a -> App b f :: _ => App a -> Maybe a f (App a b) = f a <*> f b f (Pure x) = pure x f _ = Nothing }}} Fails in 8.2.x and 8.4.2 with: {{{ • Occurs check: cannot construct the infinite type: a ~ a1 -> a Expected type: App a Actual type: App (a1 -> a) • In the first argument of ‘f’, namely ‘a’ In the first argument of ‘(<*>)’, namely ‘f a’ In the expression: f a <*> f b • Relevant bindings include b :: App a1 (bound at /Users/pepe/scratch/debug/.stack-work/intero /intero19866fqh-TEMP.hs:13:10) a :: App (a1 -> a) (bound at /Users/pepe/scratch/debug/.stack-work/intero /intero19866fqh-TEMP.hs:13:8) f :: App a -> Maybe a (bound at /Users/pepe/scratch/debug/.stack-work/intero /intero19866fqh-TEMP.hs:13:1) (intero) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 27 02:12:34 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 May 2018 02:12:34 -0000 Subject: [GHC] #11498: GHC requires kind-polymorphic signatures on class head In-Reply-To: <047.c869cb625243c8891f031146b4e58720@haskell.org> References: <047.c869cb625243c8891f031146b4e58720@haskell.org> Message-ID: <062.1f50e0b44fa1e50d50f7a0a56d695e37@haskell.org> #11498: GHC requires kind-polymorphic signatures on class head -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2-rc2 checker) | Resolution: | Keywords: 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: | -------------------------------------+------------------------------------- Changes (by sighingnow): * cc: sighingnow (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 27 09:17:22 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 May 2018 09:17:22 -0000 Subject: [GHC] #15185: Enum instance for IntX / WordX are inefficient In-Reply-To: <045.8d849a48d67b73f64eaab8f541972e7c@haskell.org> References: <045.8d849a48d67b73f64eaab8f541972e7c@haskell.org> Message-ID: <060.bd33c80b98002b4fe027e2bf8c11b7d4@haskell.org> #15185: Enum instance for IntX / WordX are inefficient -------------------------------------+------------------------------------- Reporter: guibou | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.4.2 Resolution: | 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: | -------------------------------------+------------------------------------- Changes (by guibou): * failure: None/Unknown => Runtime performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 27 09:48:47 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 May 2018 09:48:47 -0000 Subject: [GHC] #9539: TQueue can lead to thread starvation In-Reply-To: <045.f4dc0af39dea75bc36dee0474a4ea69f@haskell.org> References: <045.f4dc0af39dea75bc36dee0474a4ea69f@haskell.org> Message-ID: <060.81e27e3634bff9307ad08b61c5824dc2@haskell.org> #9539: TQueue can lead to thread starvation -------------------------------------+------------------------------------- Reporter: jwlato | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.2 Resolution: | Keywords: stm Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by YitzGale): In the case where you have a small number of initial writes, a single read, and then many writes, doesn't this queue degrade to {{{O(n^2)}}}? Because the read effectively bounds the buffer to a small maximum size. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 27 12:59:05 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 May 2018 12:59:05 -0000 Subject: [GHC] #12928: Too easy to trigger CUSK condition using TH In-Reply-To: <048.b87023a4856ac4da5fccc9b82019d18a@haskell.org> References: <048.b87023a4856ac4da5fccc9b82019d18a@haskell.org> Message-ID: <063.193a62eba8cb5c49e2471e72cb2d84f7@haskell.org> #12928: Too easy to trigger CUSK condition using TH -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: feature request | Status: new Priority: high | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: TypeInType, Resolution: | CUSKs 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: TypeInType => TypeInType, CUSKs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 27 13:00:51 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 May 2018 13:00:51 -0000 Subject: [GHC] #15187: HEAD: Validate failure when not TABLES_NEXT_TO_CODE In-Reply-To: <047.0475616412dd439857a1edcf6a1fa59f@haskell.org> References: <047.0475616412dd439857a1edcf6a1fa59f@haskell.org> Message-ID: <062.6a896099f690f82b32d9c57083ca9217@haskell.org> #15187: HEAD: Validate failure when not TABLES_NEXT_TO_CODE -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4741 Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * cc: hvr, kgardas (added) Comment: Replying to [comment:3 trommler]: > The patch fixes the build. > > Some tests fail on powerpc64, most of the failing tests are GHCi tests timing out. > I'll file new tickets for those failing tests. On powerpc64le, whoch is little-endian, only a few tests fail and those have tickets. I will submit a patch to disable there tests on powerpc64le. I wonder whether the failures on powerpc64 (big endian) is an endianess issue. Copying @hvr and @kgardas for AIX POWER and Solaris SPARC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 27 13:14:32 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 May 2018 13:14:32 -0000 Subject: [GHC] #9793: Some as-patterns could be accepted in pattern synonyms In-Reply-To: <045.e251d4b7f57881692430bb7253319357@haskell.org> References: <045.e251d4b7f57881692430bb7253319357@haskell.org> Message-ID: <060.f0fb08dac76c1a8e5a59198a66b76d7f@haskell.org> #9793: Some as-patterns could be accepted in pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 7.8.3 checker) | Keywords: Resolution: fixed | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | patsyn/should_fail/as-pattern Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1666 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * testcase: => patsyn/should_fail/as-pattern * resolution: => fixed Comment: This was implemented in commit 411a97e2c0083529b4259d0cad8f453bae110dee. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 27 13:36:40 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 May 2018 13:36:40 -0000 Subject: [GHC] #10141: CUSK mysteries In-Reply-To: <047.0645604fc6dcb528cffc10034076546d@haskell.org> References: <047.0645604fc6dcb528cffc10034076546d@haskell.org> Message-ID: <062.9cd3fcf81224c7c7665f5e330d3edb2b@haskell.org> #10141: CUSK mysteries -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc2 Resolution: | Keywords: TypeFamilies, | TypeInType, CUSKs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_fail/T10141 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: TypeFamilies, TypeInType => TypeFamilies, TypeInType, CUSKs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 27 13:37:39 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 May 2018 13:37:39 -0000 Subject: [GHC] #9427: Do finer-grained dependency analysis to infer more general kinds on type/class declarations In-Reply-To: <047.18a7617988133530c5da58a1eb2182c3@haskell.org> References: <047.18a7617988133530c5da58a1eb2182c3@haskell.org> Message-ID: <062.3d5b144166b7c15f43c7c6f32e6cc252@haskell.org> #9427: Do finer-grained dependency analysis to infer more general kinds on type/class declarations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Resolution: | Keywords: CUSKs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://ghc.haskell.org/trac/ghc/wiki/GhcKinds/KindInference| -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => CUSKs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 27 13:38:30 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 May 2018 13:38:30 -0000 Subject: [GHC] #13109: CUSK improvements In-Reply-To: <046.19ae04c2da59427623532feabc0338e7@haskell.org> References: <046.19ae04c2da59427623532feabc0338e7@haskell.org> Message-ID: <061.e6919154cb4543c91c4582a0fdf285b3@haskell.org> #13109: CUSK improvements -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType, | CUSKs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: TypeInType => TypeInType, CUSKs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 27 13:42:24 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 May 2018 13:42:24 -0000 Subject: [GHC] #15142: GHC HEAD regression: tcTyVarDetails In-Reply-To: <050.e98a1ae073f44bf5c57814edebb43575@haskell.org> References: <050.e98a1ae073f44bf5c57814edebb43575@haskell.org> Message-ID: <065.dd5865bbeccf43ed238e84f3660158b9@haskell.org> #15142: GHC HEAD regression: tcTyVarDetails -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: TypeInType, Resolution: | TypeFamilies, CUSKs Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: TypeInType, TypeFamilies => TypeInType, TypeFamilies, CUSKs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 27 13:43:17 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 May 2018 13:43:17 -0000 Subject: [GHC] #14451: Need proper SCC analysis of type declarations, taking account of CUSKs In-Reply-To: <051.ebcb090dfb4cfa66ebe4948c4fe597e5@haskell.org> References: <051.ebcb090dfb4cfa66ebe4948c4fe597e5@haskell.org> Message-ID: <066.ef61227dfa449b9c7c6a2003e66c669e@haskell.org> #14451: Need proper SCC analysis of type declarations, taking account of CUSKs -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeInType, | CUSKs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7503 | Differential Rev(s): Wiki Page: | https://ghc.haskell.org/trac/ghc/wiki/GhcKinds/KindInference| -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: TypeInType => TypeInType, CUSKs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 27 13:44:14 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 May 2018 13:44:14 -0000 Subject: [GHC] #12088: Type/data family instances in kind checking In-Reply-To: <048.155fdb7e7ce6e09c92258c376a6950ab@haskell.org> References: <048.155fdb7e7ce6e09c92258c376a6950ab@haskell.org> Message-ID: <063.3c59ed108a3d33faf36db9db082c9e35@haskell.org> #12088: Type/data family instances in kind checking -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.1 checker) | Keywords: TypeInType, Resolution: | CUSKs Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11348, #12239, | Differential Rev(s): Phab:D2272 #12643, #13790 | Wiki Page: | https://ghc.haskell.org/trac/ghc/wiki/GhcKinds/KindInference| -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: TypeInType => TypeInType, CUSKs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 27 17:25:17 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 May 2018 17:25:17 -0000 Subject: [GHC] #9539: TQueue can lead to thread starvation In-Reply-To: <045.f4dc0af39dea75bc36dee0474a4ea69f@haskell.org> References: <045.f4dc0af39dea75bc36dee0474a4ea69f@haskell.org> Message-ID: <060.9e94ffc46d0086105ce46939452356b1@haskell.org> #9539: TQueue can lead to thread starvation -------------------------------------+------------------------------------- Reporter: jwlato | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.2 Resolution: | Keywords: stm Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by YitzGale): Here is an alternative safer proposal: We retain the well-understood behavior and performance of the classic functional queue. But we ensure that the amortized cost of the occasional reverse is shared fairly by the read and write ends of the queue. We do that by placing a singleton buffer in the middle, between the read and write buffers. Whoever first finds the middle buffer unavailable pays the price that time. Here is a simplistic initial implementation: {{{#!hs data TQueue a = TQueue !(TVar [a]) !(TMVar a) !(TVar [a]) readTQueue :: TQueue a -> STM a readTQueue (TQueue read middle write) = readTVar read >>= \case x:xs -> pure x <* writeTVar read xs _ -> takeTMVar middle `orElse` (readTVar write >>= \case [] -> retry ys -> do writeTVar write [] let z:zs = reverse ys pure z <* writeTVar read zs ) writeTQueue :: TQueue a -> a -> STM () writeTQueue (TQueue read middle write) x = (do putTMVar middle x readTVar write >>= \case [] -> pure () ys -> do -- read must be empty in this case. -- strict reverse to ensure we pay the amortization price -- here and not in a read operation. writeTVar read $! reverse ys writeTVar write [] ) `orElse` modifyTVar' write (x :) }}} The above code depends on the invariant that if the write buffer is non- empty and the middle is empty, then the read buffer is empty. We can observe that this is true because a read operation will only empty the middle if there is no data left in the read buffer, and once that happens the read buffer will remain empty until the next time that the write buffer is emptied. But the type does not enforce that invariant. Here is a safer implementation with a type which cannot represent the impossible state, but requires a few more cheap TVar operations: {{{#!hs newtype TQueue a = TQueue (TVar (TQueue' a)) data TQueue' a = TQueueR !(TVar [a]) -- middle and write are empty | TQueueW !(TVar (NonEmpty a)) -- read and middle are empty | TQueueM !(TVar [a]) !(TVar a) !(TVar [a]) -- middle is non-empty readTQueue :: TQueue a -> STM a readTQueue (TQueue tvq) = readTVar tvq >>= \case TQueueR tvr -> readTVar tvr >>= \case x:xs' -> pure x <* writeTVar tvr xs' _ -> retry TQueueW tvw -> do ys <- readTVar tvw let z :| zs = NE.reverse ys pure z <* (newTVar zs >>= writeTVar tvq . TQueueR) TQueueM tvr tvm tvw -> readTVar tvr >>= \case x:xs' -> pure x <* writeTVar tvr xs' _ -> readTVar tvm <* (readTVar tvw >>= \case y : ys -> newTVar (y :| ys) >>= writeTVar tvq . TQueueW _ -> writeTVar tvq (TQueueR tvr) -- empty ) writeTQueue :: TQueue a -> a -> STM () writeTQueue (TQueue tvq) x = readTVar tvq >>= \case TQueueR tvr -> do tvm <- newTVar x tvw <- newTVar [] writeTVar tvq (TQueueM tvr tvm tvw) TQueueW tvw -> do ys <- readTVar tvw -- strict reverse to ensure we pay the amortization price -- here and not in a read operation. tvr <- newTVar $! (reverse $ NE.toList ys) tvm <- newTVar x tvw' <- newTVar [] writeTVar tvq (TQueueM tvr tvm tvw') TQueueM _ _ tvw -> modifyTVar' tvw (x :) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 27 18:17:45 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 May 2018 18:17:45 -0000 Subject: [GHC] #9539: TQueue can lead to thread starvation In-Reply-To: <045.f4dc0af39dea75bc36dee0474a4ea69f@haskell.org> References: <045.f4dc0af39dea75bc36dee0474a4ea69f@haskell.org> Message-ID: <060.d1d161a941c3c12d6f71019ba417e1e8@haskell.org> #9539: TQueue can lead to thread starvation -------------------------------------+------------------------------------- Reporter: jwlato | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.2 Resolution: | Keywords: stm Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Yitz, see https://github.com/treeowl/stm-queues for my own attempts at a fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 27 21:02:25 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 May 2018 21:02:25 -0000 Subject: [GHC] #15189: Avoid word "transformer" in the documentation of ST Message-ID: <051.babfb617b882c0b638e02ac50b14cd85@haskell.org> #15189: Avoid word "transformer" in the documentation of ST -------------------------------------+------------------------------------- Reporter: ulysses4ever | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Documentation | Version: 8.2.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: -------------------------------------+------------------------------------- I'm unhappy about the current wording in the documentation of the ST module in base. Let me explain why. Some time ago, as a novice, I struggled to get the difference between three monad-related concepts: 1. The State monad. 2. The StateT monad transformer. 3. The ST monad. Current [http://hackage.haskell.org/package/base-4.11.1.0/docs/Control- Monad-ST.html documentation for ST] says that "ST" stands for state transformer (see everywhere except for the introduction paragraph). While this follows original 1994 paper "Lazy Functional State Threads", I find this confusing after the adoption of term "(monad) transformer" due to 1995 paper "Functional Programming with Overloading and Higher-Order Polymorphism". Note that ST paper predates MT one. At the same time, the 1994 paper itself (in the title) and some current tutorials, [https://wiki.haskell.org/Monad/ST like the one at HaskelWiki], use the word "thread" to describe what's going on, avoiding discussion of spelling of ST. As the bottom line, I think, it would be helpful, especially for a novice, to avoid the word "transformer" in the documentation of ST module. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun May 27 22:56:09 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 May 2018 22:56:09 -0000 Subject: [GHC] #9539: TQueue can lead to thread starvation In-Reply-To: <045.f4dc0af39dea75bc36dee0474a4ea69f@haskell.org> References: <045.f4dc0af39dea75bc36dee0474a4ea69f@haskell.org> Message-ID: <060.2e963bfb6092af91c5d7eab339def768@haskell.org> #9539: TQueue can lead to thread starvation -------------------------------------+------------------------------------- Reporter: jwlato | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.2 Resolution: | Keywords: stm Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Yitz, I ''suspect'' my approach will be somewhat more robust than yours. Both should prevent writers from overwhelming readers, but mine should (I believe) also prevent the queue from freezing up altogether as a result of contention over unrelated `TVar`s. The real-time versions (see especially `RTTQueue1`) make this really simple; there's never a giant blob of queue maintenance work for ''any'' thread. The amortized version helps more subtly, by ensuring that queue maintenance work is "saved" across transaction failures through the power of thunk update. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 28 01:55:35 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 May 2018 01:55:35 -0000 Subject: [GHC] #12540: RFC: Allow not quantifying every top-level quantifiee In-Reply-To: <051.1956280adad0090e4523e93fefe0fc52@haskell.org> References: <051.1956280adad0090e4523e93fefe0fc52@haskell.org> Message-ID: <066.c6224ae4d27f4daaabac9f669695f8d5@haskell.org> #12540: RFC: Allow not quantifying every top-level quantifiee -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14245 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): This behavior of parentheses is awful, in my view. Redundant parentheses should never have any impact. (Yes, yes, I know: that statement is a tautology, as it's essentially the definition for "redundant". But I choose to define "redundant" to mean parentheses that are not needed to disambiguate / alter the precedence of operators.) In my opinion, this example shows why the current setup with scoped type variables is a small misdesign. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 28 02:06:51 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 May 2018 02:06:51 -0000 Subject: [GHC] #15157: Use a better string type (ByteString?!) for HsDocString In-Reply-To: <046.8bb89a9e841d6d5ba281eb5787d40851@haskell.org> References: <046.8bb89a9e841d6d5ba281eb5787d40851@haskell.org> Message-ID: <061.e20aeb29d39d9abcb34f1a1248320e13@haskell.org> #15157: Use a better string type (ByteString?!) for HsDocString -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4743 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sjakobi): * status: new => patch * differential: => Phab:D4743 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 28 03:30:42 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 May 2018 03:30:42 -0000 Subject: [GHC] #9539: TQueue can lead to thread starvation In-Reply-To: <045.f4dc0af39dea75bc36dee0474a4ea69f@haskell.org> References: <045.f4dc0af39dea75bc36dee0474a4ea69f@haskell.org> Message-ID: <060.c71c2e7ea5f3e1fc272e28d805bc6e54@haskell.org> #9539: TQueue can lead to thread starvation -------------------------------------+------------------------------------- Reporter: jwlato | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.2 Resolution: | Keywords: stm Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by winter): Replying to [comment:12 dfeuer]: > I'm 90% confident this is not actually fixed. We now get good results from `atomically $ do {...; readTQueue q}`. Unfortunately, I believe the exact same problem will still occur as soon as we go a little further, with `atomically $ do {... ; !x <- readTQueue q; return x}`. I believe the only true solution is to base `TQueue` on a real-time queue rather than an amortized one. The original fix is straightforward, maybe we should add some documents to stop people explicit forcing the list reverse during transaction? The point is that after transaction finished, forcing thunk will only bring contention on blackhole, which will not stop consumer from making progress, thus solving the original issue perfectly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 28 03:53:54 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 May 2018 03:53:54 -0000 Subject: [GHC] #9539: TQueue can lead to thread starvation In-Reply-To: <045.f4dc0af39dea75bc36dee0474a4ea69f@haskell.org> References: <045.f4dc0af39dea75bc36dee0474a4ea69f@haskell.org> Message-ID: <060.f7befc9d372fd3fdb2d1f4d3d6b8a260@haskell.org> #9539: TQueue can lead to thread starvation -------------------------------------+------------------------------------- Reporter: jwlato | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.2 Resolution: | Keywords: stm Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:21 winter]: > Replying to [comment:12 dfeuer]: > > I'm 90% confident this is not actually fixed. We now get good results from `atomically $ do {...; readTQueue q}`. Unfortunately, I believe the exact same problem will still occur as soon as we go a little further, with `atomically $ do {... ; !x <- readTQueue q; return x}`. I believe the only true solution is to base `TQueue` on a real-time queue rather than an amortized one. > > The original fix is straightforward, maybe we should add some documents to stop people from explicit forcing the list reverse during transaction? The point is that after transaction finished, forcing thunk will only bring contention on blackhole, which will not stop consumer from making progress, thus solving the original issue perfectly. > > In fact, the basic requirement for using `TQueue` is that you should have fast enough consumers, with this requirement met, as long as we give consumers chances to do the `reverse`, the list will not accumulate and each blackholing should be short. The original "fix" only works if 1. The value pulled from the queue isn't needed to finish the transaction, and 2. The thread only needs to pull one value from the queue. So it fixes the problem ''in its original context'', but not in any larger settings. Since the whole point of STM is to be "compositional", I don't think this can honestly be called a fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 28 06:45:50 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 May 2018 06:45:50 -0000 Subject: [GHC] #9539: TQueue can lead to thread starvation In-Reply-To: <045.f4dc0af39dea75bc36dee0474a4ea69f@haskell.org> References: <045.f4dc0af39dea75bc36dee0474a4ea69f@haskell.org> Message-ID: <060.12672fc75b7d36db9927de69f751321d@haskell.org> #9539: TQueue can lead to thread starvation -------------------------------------+------------------------------------- Reporter: jwlato | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.2 Resolution: | Keywords: stm Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by winter): > So it fixes the problem in its original context, but not in any larger settings. Since the whole point of STM is to be "compositional", I don't think this can honestly be called a fix. That will be another problem to tackle IMHO, since any long transactions rise the risk of starvation, and we really should educate user to be cautious about this! As for your realtime queue proposal, let's wait for some realworld benchmark results before taking further actions. I'm not opposite to a good realtime queue, it's just need some thoroughly evaluation before merged into standard library IMHO ；） -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 28 06:47:37 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 May 2018 06:47:37 -0000 Subject: [GHC] #15190: disable haddock disables building of manuals Message-ID: <050.a65b056fae49f3a9302bf89347340570@haskell.org> #15190: disable haddock disables building of manuals -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Build System | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- As far as I can tell disabling haddock in ghc causes the manuals also not to get built. This is known/expected? I have not been able to track down why this seems to be the case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 28 07:49:26 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 May 2018 07:49:26 -0000 Subject: [GHC] #11066: Inacessible branch should be warning - otherwise breaks type soundness? In-Reply-To: <047.0785946e31f05741dc32414264d84d16@haskell.org> References: <047.0785946e31f05741dc32414264d84d16@haskell.org> Message-ID: <062.91cf569fcbf25da36a998bc9358c8061@haskell.org> #11066: Inacessible branch should be warning - otherwise breaks type soundness? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #8128, #8740 | Differential Rev(s): Phab:D1454, Wiki Page: | Phab:D4744 -------------------------------------+------------------------------------- Changes (by tdammers): * status: new => patch * differential: Phab:D1454 => Phab:D1454, Phab:D4744 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 28 09:29:16 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 May 2018 09:29:16 -0000 Subject: [GHC] #15078: base: Customary type class laws (e.g. for Eq) and non-abiding instances (e.g. Float) should be documented In-Reply-To: <046.a4c8c72c9e9d68a07b93ce24b1eed9ca@haskell.org> References: <046.a4c8c72c9e9d68a07b93ce24b1eed9ca@haskell.org> Message-ID: <061.8512f6262eec4c8beaa9577ed75453f7@haskell.org> #15078: base: Customary type class laws (e.g. for Eq) and non-abiding instances (e.g. Float) should be documented -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: Azel Type: feature request | Status: patch Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.4.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4736 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Azel): Continuing on that vein, what laws do you think should be expected for `Fractional`, `Floating`, `RealFloat` and `RealFrac`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 28 10:57:05 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 May 2018 10:57:05 -0000 Subject: [GHC] #13930: Cabal configure regresses in space/time In-Reply-To: <046.5b2c9cbc56e2d7d878c20dcde39f4651@haskell.org> References: <046.5b2c9cbc56e2d7d878c20dcde39f4651@haskell.org> Message-ID: <061.e45f9e3ce90d74a89470615e39c60c29@haskell.org> #13930: Cabal configure regresses in space/time -------------------------------------+------------------------------------- Reporter: bgamari | Owner: tdammers Type: bug | Status: infoneeded Priority: highest | Milestone: 8.4.2 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13982, #5129 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Can't seem to be able to reproduce this on GHC HEAD, so let's close this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 28 12:46:52 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 May 2018 12:46:52 -0000 Subject: [GHC] #15191: Deriving via DeriveAnyClass not behaving the same as an emply instance declaration Message-ID: <048.473a6ea8bd09b98a60a45b12da2b963f@haskell.org> #15191: Deriving via DeriveAnyClass not behaving the same as an emply instance declaration -------------------------------------+------------------------------------- Reporter: Darwin226 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: | 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've opened [https://stackoverflow.com/questions/50557019/deriving-via- deriveanyclass-not-behaving-the-same-as-an-emply-instance-declarati a question on StackOverflow] describing the issue. I'll copy it here: ---- I have the following code {{{#!hs {-# LANGUAGE PolyKinds, DefaultSignatures, FlexibleContexts, DeriveAnyClass, DeriveGeneric #-} {-# LANGUAGE FlexibleInstances, MultiParamTypeClasses, UndecidableInstances #-} module DeriveTest where import GHC.Generics class GenericClass a m where instance GenericClass f m => GenericClass (M1 i c f) m instance Condition a m => GenericClass (K1 i a) m class Condition (a :: k) (m :: * -> *) where instance (Condition a m, Condition b m) => Condition (a b) m instance {-# OVERLAPPABLE #-} Condition (a :: k) m class Class (e :: (* -> *) -> *) where classF :: e m -> () default classF :: GenericClass (Rep (e m)) m => e m -> () classF = undefined }}} It defines the class Class of types that have a higher-kinded type as a parameter. It also defines a generic way to derive an instance of that class. Now if I declare a new datatype like this, and try to derive an instance of Class {{{#!hs data T a m = T { field :: a } deriving (Generic, Class) }}} I get the following error: {{{ * Overlapping instances for Condition a m arising from the 'deriving' clause of a data type declaration Matching instances: instance [overlappable] forall k (a :: k) (m :: * -> *). Condition a m instance forall k1 k2 (a :: k1 -> k2) (m :: * -> *) (b :: k1). (Condition a m, Condition b m) => Condition (a b) m (The choice depends on the instantiation of `a, m' To pick the first instance above, use IncoherentInstances when compiling the other instance declarations) * When deriving the instance for (Class (T a)) | 22 | deriving (Generic, Class) | ^^^^^ }}} The error sort of makes sense because I guess. The instance really does depend on the instantiation of a. However, if I just write an empty instance like this: {{{#!hs data T a m = T { field :: a } deriving (Generic) instance Class (T a) -- works }}} It works. Why? And how can I make it behave the same with the deriving statement? ---- Ryan Scott suggested I open a ticket and that the issue probably isn't with the deriving mechanisms. Still, I chose to keep the title because that's what the original problem was and I've seen [https://github.com/GetShopTV/swagger2/issues/144 similar issues] before -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 28 12:48:32 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 May 2018 12:48:32 -0000 Subject: [GHC] #15191: Deriving via DeriveAnyClass not behaving the same as an emply instance declaration In-Reply-To: <048.473a6ea8bd09b98a60a45b12da2b963f@haskell.org> References: <048.473a6ea8bd09b98a60a45b12da2b963f@haskell.org> Message-ID: <063.2363d6eaa29f8d266c45b2a301cbf934@haskell.org> #15191: Deriving via DeriveAnyClass not behaving the same as an emply instance declaration -------------------------------------+------------------------------------- Reporter: Darwin226 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: 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: | -------------------------------------+------------------------------------- Description changed by Darwin226: Old description: > I've opened [https://stackoverflow.com/questions/50557019/deriving-via- > deriveanyclass-not-behaving-the-same-as-an-emply-instance-declarati a > question on StackOverflow] describing the issue. I'll copy it here: > > ---- > > I have the following code > > {{{#!hs > {-# LANGUAGE PolyKinds, DefaultSignatures, FlexibleContexts, > DeriveAnyClass, DeriveGeneric #-} > {-# LANGUAGE FlexibleInstances, MultiParamTypeClasses, > UndecidableInstances #-} > module DeriveTest where > > import GHC.Generics > > class GenericClass a m where > instance GenericClass f m => GenericClass (M1 i c f) m > instance Condition a m => GenericClass (K1 i a) m > > class Condition (a :: k) (m :: * -> *) where > instance (Condition a m, Condition b m) => Condition (a b) m > instance {-# OVERLAPPABLE #-} Condition (a :: k) m > > class Class (e :: (* -> *) -> *) where > classF :: e m -> () > default classF :: GenericClass (Rep (e m)) m => e m -> () > classF = undefined > }}} > > It defines the class Class of types that have a higher-kinded type as a > parameter. It also defines a generic way to derive an instance of that > class. Now if I declare a new datatype like this, and try to derive an > instance of Class > > {{{#!hs > data T a m = T > { field :: a } > deriving (Generic, Class) > }}} > > I get the following error: > > {{{ > * Overlapping instances for Condition a m > arising from the 'deriving' clause of a data type declaration > Matching instances: > instance [overlappable] forall k (a :: k) (m :: * -> *). > Condition a m > instance forall k1 k2 (a :: k1 -> k2) (m :: * -> *) (b :: k1). > (Condition a m, Condition b m) => > Condition (a b) m > (The choice depends on the instantiation of `a, m' > To pick the first instance above, use IncoherentInstances > when compiling the other instance declarations) > * When deriving the instance for (Class (T a)) > | > 22 | deriving (Generic, Class) > | > ^^^^^ > }}} > > The error sort of makes sense because I guess. The instance really does > depend on the instantiation of a. However, if I just write an empty > instance like this: > > {{{#!hs > data T a m = T > { field :: a } > deriving (Generic) > instance Class (T a) -- works > }}} > > It works. Why? And how can I make it behave the same with the deriving > statement? > > ---- > > Ryan Scott suggested I open a ticket and that the issue probably isn't > with the deriving mechanisms. Still, I chose to keep the title because > that's what the original problem was and I've seen > [https://github.com/GetShopTV/swagger2/issues/144 similar issues] before New description: I've opened [https://stackoverflow.com/questions/50557019/deriving-via- deriveanyclass-not-behaving-the-same-as-an-emply-instance-declarati a question on StackOverflow] describing the issue. I'll copy it here: ---- I have the following code {{{#!hs {-# LANGUAGE PolyKinds, DefaultSignatures, FlexibleContexts, DeriveAnyClass, DeriveGeneric #-} {-# LANGUAGE FlexibleInstances, MultiParamTypeClasses, UndecidableInstances #-} module DeriveTest where import GHC.Generics class GenericClass a m where instance GenericClass f m => GenericClass (M1 i c f) m instance Condition a m => GenericClass (K1 i a) m class Condition (a :: k) (m :: * -> *) where instance (Condition a m, Condition b m) => Condition (a b) m instance {-# OVERLAPPABLE #-} Condition (a :: k) m class Class (e :: (* -> *) -> *) where classF :: e m -> () default classF :: GenericClass (Rep (e m)) m => e m -> () classF = undefined }}} It defines the class Class of types that have a higher-kinded type as a parameter. It also defines a generic way to derive an instance of that class. Now if I declare a new datatype like this, and try to derive an instance of Class {{{#!hs data T a m = T { field :: a } deriving (Generic, Class) }}} I get the following error: {{{ * Overlapping instances for Condition a m arising from the 'deriving' clause of a data type declaration Matching instances: instance [overlappable] forall k (a :: k) (m :: * -> *). Condition a m instance forall k1 k2 (a :: k1 -> k2) (m :: * -> *) (b :: k1). (Condition a m, Condition b m) => Condition (a b) m (The choice depends on the instantiation of `a, m' To pick the first instance above, use IncoherentInstances when compiling the other instance declarations) * When deriving the instance for (Class (T a)) | 22 | deriving (Generic, Class) | ^^^^^ }}} The error sort of makes sense I guess. The instance really does depend on the instantiation of a. However, if I just write an empty instance like this: {{{#!hs data T a m = T { field :: a } deriving (Generic) instance Class (T a) -- works }}} It works. Why? And how can I make it behave the same with the deriving statement? ---- Ryan Scott suggested I open a ticket and that the issue probably isn't with the deriving mechanisms. Still, I chose to keep the title because that's what the original problem was and I've seen [https://github.com/GetShopTV/swagger2/issues/144 similar issues] before -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 28 12:52:56 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 May 2018 12:52:56 -0000 Subject: [GHC] #15186: ghc 8.4.2 panic in profiling build In-Reply-To: <045.764163a11088d02a8878689da6d8a04b@haskell.org> References: <045.764163a11088d02a8878689da6d8a04b@haskell.org> Message-ID: <060.9c4b16d0405b5969899b2bec0a22de62@haskell.org> #15186: ghc 8.4.2 panic in profiling build -------------------------------------+------------------------------------- Reporter: kquick | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.4.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): It turns out that `unsafeCoerce` isn't needed to reproduce the issue, fortunately. I've edited comment:1 accordingly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 28 15:09:54 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 May 2018 15:09:54 -0000 Subject: [GHC] #15191: Deriving via DeriveAnyClass not behaving the same as an emply instance declaration In-Reply-To: <048.473a6ea8bd09b98a60a45b12da2b963f@haskell.org> References: <048.473a6ea8bd09b98a60a45b12da2b963f@haskell.org> Message-ID: <063.e22210a47e5e6c012be45ef87417a963@haskell.org> #15191: Deriving via DeriveAnyClass not behaving the same as an emply instance declaration -------------------------------------+------------------------------------- Reporter: Darwin226 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Instances 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => Instances Comment: As I mentioned in the Stack Overflow post, I think this has nothing to do with `deriving`, but rather the interaction between GHC's constraint solver and overlapping instances. Take this code: {{{#!hs {-# LANGUAGE DefaultSignatures #-} {-# LANGUAGE DeriveGeneric #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE UndecidableInstances #-} module Bug where import GHC.Generics class GenericClass a m where instance GenericClass f m => GenericClass (M1 i c f) m instance Condition a m => GenericClass (K1 i a) m class Condition (a :: k) (m :: * -> *) where instance (Condition a m, Condition b m) => Condition (a b) m instance {-# OVERLAPPABLE #-} Condition (a :: k) m class Class (e :: (* -> *) -> *) where classF :: e m -> () default classF :: GenericClass (Rep (e m)) m => e m -> () classF = classFDefault classFDefault :: forall (e :: (* -> *) -> *) (m :: * -> *). GenericClass (Rep (e m)) m => e m -> () classFDefault = undefined data T a m = T { field :: a } deriving (Generic) }}} And observe that this typechecks: {{{#!hs instance Class (T a) where classF = classFDefault }}} But this doesn't: {{{#!hs classFT :: forall a (m :: * -> *). T a m -> () classFT = classFDefault }}} As it gives the same error as if you'd used a `deriving` clause: {{{ $ /opt/ghc/8.4.2/bin/ghci Bug.hs GHCi, version 8.4.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:36:11: error: • Overlapping instances for Condition a m arising from a use of ‘classFDefault’ Matching instances: instance [overlappable] forall k (a :: k) (m :: * -> *). Condition a m -- Defined at Bug.hs:19:31 instance forall k1 k2 (a :: k1 -> k2) (m :: * -> *) (b :: k1). (Condition a m, Condition b m) => Condition (a b) m -- Defined at Bug.hs:18:10 (The choice depends on the instantiation of ‘a, m’ To pick the first instance above, use IncoherentInstances when compiling the other instance declarations) • In the expression: classFDefault In an equation for ‘classFT’: classFT = classFDefault | 36 | classFT = classFDefault | ^^^^^^^^^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 28 19:05:35 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 May 2018 19:05:35 -0000 Subject: [GHC] #15107: Testsuite failures on Windows In-Reply-To: <046.8e0cbe335a7ce09f5a7e747d4e07162e@haskell.org> References: <046.8e0cbe335a7ce09f5a7e747d4e07162e@haskell.org> Message-ID: <061.598b78595801c171eb976edb9a9322ce@haskell.org> #15107: Testsuite failures on Windows -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4668 Wiki Page: | Phab:D4667 -------------------------------------+------------------------------------- Comment (by Tamar Christina ): In [changeset:"60fb2b2160aa16194b74262f4df8fad5af171b0f/ghc" 60fb2b21/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="60fb2b2160aa16194b74262f4df8fad5af171b0f" Clean up Windows testsuite failures Summary: Another round and attempt at getting these down to 0. We really should re-enable the CI and not wait for those cloud based ones. I've disabled the backpack tests on windows as they are too broad, they test as much the shell as they do the compiler. The perf tests have been too long to track down. but the numbers are horrible but I don't see them getting fixed so just have to accept them. T9293 has new windows specific output because a Dyn way only flag was added. This will of course not work on non-Dyn way builds. Test Plan: ./validate Reviewers: bgamari, hvr, simonmar Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15107 Differential Revision: https://phabricator.haskell.org/D4668 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 28 19:11:30 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 May 2018 19:11:30 -0000 Subject: [GHC] #15107: Testsuite failures on Windows In-Reply-To: <046.8e0cbe335a7ce09f5a7e747d4e07162e@haskell.org> References: <046.8e0cbe335a7ce09f5a7e747d4e07162e@haskell.org> Message-ID: <061.628a8a673010201367a528747a4e8669@haskell.org> #15107: Testsuite failures on Windows -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4668 Wiki Page: | Phab:D4667 -------------------------------------+------------------------------------- Changes (by Phyx-): * status: patch => closed * os: Unknown/Multiple => Windows * resolution: => fixed Comment: Unless some regressions have snuk in again between the time I wrote the patches and them being committed, these should now be 0. Please re-open if not. I currently have no not-dirty tree to build master. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 28 20:40:02 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 May 2018 20:40:02 -0000 Subject: [GHC] #3160: No exception safety in Control.Concurrent.QSem QSemN and SampleVar In-Reply-To: <053.70a1854543dd01f0108efd70a01e67de@haskell.org> References: <053.70a1854543dd01f0108efd70a01e67de@haskell.org> Message-ID: <068.da25242ee16091401af3fdce4a56f8bb@haskell.org> #3160: No exception safety in Control.Concurrent.QSem QSemN and SampleVar -------------------------------------+------------------------------------- Reporter: ChrisKuklewicz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 7.6.1 Component: libraries/base | Version: 7.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * owner: simonmar => (none) * status: closed => new * resolution: wontfix => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 28 20:40:22 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 May 2018 20:40:22 -0000 Subject: [GHC] #3160: No exception safety in Control.Concurrent.QSem QSemN and SampleVar In-Reply-To: <053.70a1854543dd01f0108efd70a01e67de@haskell.org> References: <053.70a1854543dd01f0108efd70a01e67de@haskell.org> Message-ID: <068.ed23d54ff7dd3bdf027050d94fc69c23@haskell.org> #3160: No exception safety in Control.Concurrent.QSem QSemN and SampleVar -------------------------------------+------------------------------------- Reporter: ChrisKuklewicz | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 7.6.1 Component: libraries/base | Version: 7.0.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 28 21:08:12 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 May 2018 21:08:12 -0000 Subject: [GHC] #14343: bad pretty-printing of types with promoted data types In-Reply-To: <048.9dafa4d8103f25346932aca07d111b88@haskell.org> References: <048.9dafa4d8103f25346932aca07d111b88@haskell.org> Message-ID: <063.6ce49dcb80195abba10cc12950584b06@haskell.org> #14343: bad pretty-printing of types with promoted data types -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: andreash Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by andreash): * owner: (none) => andreash Comment: I started working on this in https://phabricator.haskell.org/D4746. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 28 21:15:04 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 May 2018 21:15:04 -0000 Subject: [GHC] #15192: Refactor of Coercion Message-ID: <047.060aeef3805df87e61a1408a60ab4dd6@haskell.org> #15192: Refactor of Coercion -------------------------------------+------------------------------------- Reporter: ningning | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- This patch aims at defining the new coercion rule {{{#!hs | EraseEqCo Role Type Type KindCoercion -- "e" -> _ -> _ -> N -> e }}} which corresponds to the typing rule {{{ t1 : k1 t2 : k2 |t1| = |t2| g : k1 ~ k2 ------------------------------------ EraseEqCo r t1 t2 g : t1 ~r t2 }}} Namely, if two types after erasure of casts and coercions are equivalent, then they can be casted from and to each other. This new coercion rule is designed to replace the current coherence rule {{{#!hs -- Coherence applies a coercion to the left-hand type of another coercion -- See Note [Coherence] | CoherenceCo Coercion KindCoercion -- :: e -> N -> e }}} The new rule is useful in several places. For example, now it is easier to define coercion {{{t |> k ~ t}}} without resorting to reflexivity coercion, and {{{t ~ t |> k}}} without resorting to symmetric rule. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 28 21:16:08 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 May 2018 21:16:08 -0000 Subject: [GHC] #15192: Refactor of Coercion In-Reply-To: <047.060aeef3805df87e61a1408a60ab4dd6@haskell.org> References: <047.060aeef3805df87e61a1408a60ab4dd6@haskell.org> Message-ID: <062.aafce24772093cf7eea8eaa96fb21054@haskell.org> #15192: Refactor of Coercion -------------------------------------+------------------------------------- Reporter: ningning | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ningning): * version: 8.2.2 => * milestone: 8.6.1 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 28 21:20:42 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 May 2018 21:20:42 -0000 Subject: [GHC] #15193: QSem makes nonsense claim Message-ID: <045.c822f45289d183bc488d863511958b32@haskell.org> #15193: QSem makes nonsense claim -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Core | Version: 8.2.2 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It says waiting threads are serviced in FIFO order. This isn't really a meaningful statement. What does "first in" mean? Furthermore, the first step in `waitQSem` is `takeMVar`, which provides no ordering guarantees whatsoever. As far as I can tell, there's no meaningful difference between a thread waiting a long time in the queue and I've waiting a long time to get into the queue. So I think we probably want to weaken the promise here to match the `MVar` fairness guarantee: if a thread waits on a `TSem`, and that `TSem` continues to be signaled, then the thread will eventually proceed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 28 21:36:05 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 May 2018 21:36:05 -0000 Subject: [GHC] #15193: QSem makes nonsense claim In-Reply-To: <045.c822f45289d183bc488d863511958b32@haskell.org> References: <045.c822f45289d183bc488d863511958b32@haskell.org> Message-ID: <060.d63783a93ba720dbeb28f58a4293a454@haskell.org> #15193: QSem makes nonsense claim -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by dfeuer: Old description: > It says waiting threads are serviced in FIFO order. This isn't really a > meaningful statement. What does "first in" mean? Furthermore, the first > step in `waitQSem` is `takeMVar`, which provides no ordering guarantees > whatsoever. As far as I can tell, there's no meaningful difference > between a thread waiting a long time in the queue and I've waiting a long > time to get into the queue. So I think we probably want to weaken the > promise here to match the `MVar` fairness guarantee: if a thread waits on > a `TSem`, and that `TSem` continues to be signaled, then the thread will > eventually proceed. New description: It says waiting threads are serviced in FIFO order. This isn't really a meaningful statement. What does "first in" mean? Furthermore, the first step in `waitQSem` is `takeMVar`, which provides no ordering guarantees whatsoever. As far as I can tell, there's no meaningful difference between a thread waiting a long time in the queue and one waiting a long time to get into the queue. So I think we probably want to weaken the promise here to match the `MVar` fairness guarantee: if a thread waits on a `TSem`, and that `TSem` continues to be signaled, then the thread will eventually proceed. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 28 21:37:52 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 May 2018 21:37:52 -0000 Subject: [GHC] #15193: QSem makes nonsense claim In-Reply-To: <045.c822f45289d183bc488d863511958b32@haskell.org> References: <045.c822f45289d183bc488d863511958b32@haskell.org> Message-ID: <060.abc8a6385935522bfcfb5875562a7742@haskell.org> #15193: QSem makes nonsense claim -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): `takeMVar` does serve threads in FIFO order, although the semantics doesn't require it. I think we'd be unlikely to ever break this property, because I suspect there are things depending on it (like `QSem`). What is it about "first in" with respect to QSem that's problematic? What does `TSem` have to do with this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 28 21:42:21 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 May 2018 21:42:21 -0000 Subject: [GHC] #15193: QSem makes nonsense claim In-Reply-To: <045.c822f45289d183bc488d863511958b32@haskell.org> References: <045.c822f45289d183bc488d863511958b32@haskell.org> Message-ID: <060.3b4b4463fb94823b50e54cfbe38074c4@haskell.org> #15193: QSem makes nonsense claim -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by dfeuer: Old description: > It says waiting threads are serviced in FIFO order. This isn't really a > meaningful statement. What does "first in" mean? Furthermore, the first > step in `waitQSem` is `takeMVar`, which provides no ordering guarantees > whatsoever. As far as I can tell, there's no meaningful difference > between a thread waiting a long time in the queue and one waiting a long > time to get into the queue. So I think we probably want to weaken the > promise here to match the `MVar` fairness guarantee: if a thread waits on > a `TSem`, and that `TSem` continues to be signaled, then the thread will > eventually proceed. New description: It says waiting threads are serviced in FIFO order. This isn't really a meaningful statement. What does "first in" mean? Furthermore, the first step in `waitQSem` is `takeMVar`, which provides no ordering guarantees whatsoever. As far as I can tell, there's no meaningful difference between a thread waiting a long time in the queue and one waiting a long time to get into the queue. So I think we probably want to weaken the promise here to match the `MVar` fairness guarantee: if a thread waits on a `QSem`, and that `QSem` continues to be signaled, then the thread will eventually proceed. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 28 22:12:36 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 May 2018 22:12:36 -0000 Subject: [GHC] #15193: QSem makes nonsense claim In-Reply-To: <045.c822f45289d183bc488d863511958b32@haskell.org> References: <045.c822f45289d183bc488d863511958b32@haskell.org> Message-ID: <060.d04455facfc4c0e0e85d217b3bcb0842@haskell.org> #15193: QSem makes nonsense claim -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): `TSem` was not what I meant to write. The trouble with "first in" is that it's hard to say what happens "first" in a concurrent setting. If I create ten threads, each of which immediately waits on an empty `QSem`, then later signal that `QSem` several times, it's totally arbitrary which threads get serviced when. It seems the guarantee must have to do with consecutive requests by the same thread, with some guarantees about thread creation. Or something... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 28 23:40:11 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 May 2018 23:40:11 -0000 Subject: [GHC] #15192: Refactor of Coercion In-Reply-To: <047.060aeef3805df87e61a1408a60ab4dd6@haskell.org> References: <047.060aeef3805df87e61a1408a60ab4dd6@haskell.org> Message-ID: <062.4f3f38b937ea22fa5290b9918dd34bae@haskell.org> #15192: Refactor of Coercion -------------------------------------+------------------------------------- Reporter: ningning | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): This new rule corresponds to the coherence rule used in my [https://repository.brynmawr.edu/cgi/viewcontent.cgi?article=1074&context=compsci_pubs thesis] and in last ICFP's [https://repository.brynmawr.edu/cgi/viewcontent.cgi?article=1076&context=compsci_pubs paper on dependent Haskell]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon May 28 23:40:41 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 May 2018 23:40:41 -0000 Subject: [GHC] #15192: Refactor of Coercion In-Reply-To: <047.060aeef3805df87e61a1408a60ab4dd6@haskell.org> References: <047.060aeef3805df87e61a1408a60ab4dd6@haskell.org> Message-ID: <062.e509ac758eb8073a1241b5537e08608b@haskell.org> #15192: Refactor of Coercion -------------------------------------+------------------------------------- Reporter: ningning | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4747 Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * differential: => Phab:D4747 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 29 00:16:54 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 May 2018 00:16:54 -0000 Subject: [GHC] #13833: Instances with GHC.TypeLits.Nat/Symbol should be possible without FlexibleInstances. In-Reply-To: <045.899fdc291fee22417bd4b56eb02e56da@haskell.org> References: <045.899fdc291fee22417bd4b56eb02e56da@haskell.org> Message-ID: <060.606e9467505097d0383d826ef86d2820@haskell.org> #13833: Instances with GHC.TypeLits.Nat/Symbol should be possible without FlexibleInstances. -------------------------------------+------------------------------------- Reporter: Hjulle | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): Um, is there anybody using fancy type stuff like `TypeLits`, but not needing `FlexibleInstances`? I know [https://downloads.haskell.org/~ghc/8.4.2/docs/html/users_guide/glasgow_exts.html `-fglasgow-exts`] is deprecated these days, but I always switch on those extensions anyway. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 29 00:36:31 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 May 2018 00:36:31 -0000 Subject: [GHC] #15080: List Operators Sorted by Precedence in GHCi In-Reply-To: <042.0874d1a1880ecd8d77f20358849846e6@haskell.org> References: <042.0874d1a1880ecd8d77f20358849846e6@haskell.org> Message-ID: <057.ef90e50c6b48f6d7a85ae8b87f48dcb2@haskell.org> #15080: List Operators Sorted by Precedence in GHCi -------------------------------------+------------------------------------- Reporter: sjs | Owner: | artemohanjanyan Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.2 Resolution: | Keywords: operator | precedence, newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by artemohanjanyan): * owner: (none) => artemohanjanyan -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 29 00:42:46 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 May 2018 00:42:46 -0000 Subject: [GHC] #4806: Make error message more user friendly when module is not found because package is unusable In-Reply-To: <044.33251b8e69d1b6796ddff38b98a4991e@haskell.org> References: <044.33251b8e69d1b6796ddff38b98a4991e@haskell.org> Message-ID: <059.8ad81fc6a06fb4d83fca82f8edc624f9@haskell.org> #4806: Make error message more user friendly when module is not found because package is unusable -------------------------------------+------------------------------------- Reporter: mitar | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgillespie): I think the strategy should be to modify mkModuleToPkgConfAll to include all UnusablePackages in PackageState.hs. We could then add another constructor to ModuleOrigin (say, BrokenPackage) so that we could report it on lookupModuleWithSuggestions. Please correct me if this is not a reasonable approach. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 29 05:25:39 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 May 2018 05:25:39 -0000 Subject: [GHC] #15078: base: Customary type class laws (e.g. for Eq) and non-abiding instances (e.g. Float) should be documented In-Reply-To: <046.a4c8c72c9e9d68a07b93ce24b1eed9ca@haskell.org> References: <046.a4c8c72c9e9d68a07b93ce24b1eed9ca@haskell.org> Message-ID: <061.ed63a3b01c11b3055d0e303a03711c2b@haskell.org> #15078: base: Customary type class laws (e.g. for Eq) and non-abiding instances (e.g. Float) should be documented -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: Azel Type: feature request | Status: patch Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.4.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4736 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Azel): Thinking about it, I think `Fractional` instances are expected to form division rings, `Floating` instances are expected to form exponential fields and `signum` and `abs` could imply that `Num` instances are expected to be division rings as well but if so division ought to be there. `RealFloat` is for machine-level floating-point types so there shouldn't be anything to add rules-wise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 29 07:56:02 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 May 2018 07:56:02 -0000 Subject: [GHC] #7411: Exceptions are optimized away in certain situations In-Reply-To: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> References: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> Message-ID: <065.66fbd7859ff72b1f8905a4377f906ca7@haskell.org> #7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): I ran two full builds of GHC (`make clean; ./boot; ./configure; make -j2` on a dual-core i5 machine, 4 GB RAM, 7200 RPM HDD, debian stretch, stage0 = GHC 8.4.1), one with the `prof` flavour, the other with a modified `prof` flavour with `GhcLibHcOpts += -fno-state-hack`. It turns out that the `-fno-state-hack` version is slightly faster: Prof build: {{{ real 66m5.407s user 118m50.668s sys 6m7.044s }}] Prof + `-fno-state-hack` build: {{{ real 65m42.784s user 118m32.892s sys 6m5.252s }}} I haven't done any in-depth profiling yet, but it seems to me that removing the state hack would most not make things significantly worse overall. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 29 10:24:26 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 May 2018 10:24:26 -0000 Subject: [GHC] #15192: Refactor of Coercion In-Reply-To: <047.060aeef3805df87e61a1408a60ab4dd6@haskell.org> References: <047.060aeef3805df87e61a1408a60ab4dd6@haskell.org> Message-ID: <062.ff2ee1d0e16f955dc7b2c2bc06b72069@haskell.org> #15192: Refactor of Coercion -------------------------------------+------------------------------------- Reporter: ningning | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4747 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Can you elaborate? * What are the advantages of the new form? (It looks more symmetrical; but it has more arguments.) Can you say what the "several places" where is is useful are? Are there any disadvanatages? * Can we use the new form in `OptCoercion` to simplify coercions? * I see no constraints on `r` in the rule. So you could fix on `N` and use `SubCo` to downgrade to `R`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 29 10:32:13 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 May 2018 10:32:13 -0000 Subject: [GHC] #4806: Make error message more user friendly when module is not found because package is unusable In-Reply-To: <044.33251b8e69d1b6796ddff38b98a4991e@haskell.org> References: <044.33251b8e69d1b6796ddff38b98a4991e@haskell.org> Message-ID: <059.2ca33ee7eb01ce8f34cac50db55c72a4@haskell.org> #4806: Make error message more user friendly when module is not found because package is unusable -------------------------------------+------------------------------------- Reporter: mitar | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): I haven't looked in great details but that seems like a reasonable approach to me. I'd say go ahead and give it a try! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 29 14:53:27 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 May 2018 14:53:27 -0000 Subject: [GHC] #15194: Consider a QSem variant that can hold back resources Message-ID: <045.1674be26df2a93f2c924a0b1bc6a317d@haskell.org> #15194: Consider a QSem variant that can hold back resources -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Core | Version: 8.2.2 Libraries | 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: -------------------------------------+------------------------------------- `QSem` always wakes up threads when resources become available. This leads to unavoidable contention between waiting and signaling threads. If, however, a quantity semaphore is allowed to hold some resources back, then these can be decoupled. One `MVar` holds an immediately available resource quantity or a list of threads waiting to be enqueued. The other holds a reserved resource quantity or a FIFO queue of threads. The only non-exceptional time an operation needs both `MVar`s is when signaling exceeds the reserve capacity. In that case, the reserve is dumped into the available bucket, listed threads are enqueued, and threads in the queue are woken up until resources or threads are exhausted. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 29 16:06:32 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 May 2018 16:06:32 -0000 Subject: [GHC] #15192: Refactor of Coercion In-Reply-To: <047.060aeef3805df87e61a1408a60ab4dd6@haskell.org> References: <047.060aeef3805df87e61a1408a60ab4dd6@haskell.org> Message-ID: <062.f337c1722a3f5c0bb30054c48a719233@haskell.org> #15192: Refactor of Coercion -------------------------------------+------------------------------------- Reporter: ningning | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4747 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ningning): Replying to [comment:4 simonpj]: > Can you elaborate? > > * What are the advantages of the new form? (It looks more symmetrical; but it has more arguments.) Can you say what the "several places" where is is useful are? Are there any disadvanatages? - Theoretically, this new form emphasizes that type equality relation is coherent, namely coercions within types is immaterial. This is studied in Section 5.8.3 in [https://repository.brynmawr.edu/cgi/viewcontent.cgi?article=1074&context=compsci_pubs/ Richard's thesis] and the {{{An-EraseEq}}} rule in [https://repository.brynmawr.edu/cgi/viewcontent.cgi?article=1076&context=compsci_pubs/ A Specification for Dependent Types in Haskell paper] - Practically, it simplifies some sort of coercion constructions. In current implementation, coercions as {{{t |> g ~ t}}} is built as {{{ |> g}}}. Namely we build the reflexivity coercion first and insert kind coercion to the left. Using the new form it can be rewritten to {{{ (t |> g) ~ t }}}. Similarly, coercions as {{{ t ~ t |> g }}} is {{{sym ( |> g)}}}, and can be rewritten to {{{ t ~ (t |> g) }}} directly. We have several usage like that in current implementation, e.g. {{{TcCanonical}}}. Moreover, one possible optimization is to replace the {{{buildCoercion :: Type -> Type -> CoercionN}}} function in module {{{Coercion}}}, which builds a coercion between types that are the same ignoring coercions, which is exactly the intention of the new form. - There are indeed some disadvantages now. In current refactor, there are three places where given a coercion {{{g}}}, we need to call {{{coercionKind}}} to get {{{g :: t1 ~ t2}}} in order to use the new form because the new form needs this information to build {{{(t1 |> ki_co) ~ t1 ; g }}}. This is very inefficient. We are still trying to figure out further optimizations in those places. > * Can we use the new form in `OptCoercion` to simplify coercions? We have optimizations for {{{EraseEqCo}}} in {{{OptCoercion}}}. For example {{{opt_co4}}} and {{{opt_trans_rule}}} for the new form are both simpler than for the old form. Besides that, I don't know if further optimization is possible? > * I see no constraints on `r` in the rule. So you could fix on `N` and use `SubCo` to downgrade to `R`? It is doable I think. But I don't know if we could gain any benefit from this restriction? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 29 16:12:43 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 May 2018 16:12:43 -0000 Subject: [GHC] #15178: Implement DerivingVia In-Reply-To: <050.e1bb998ddf8ec1616d3dc71e43dcc2db@haskell.org> References: <050.e1bb998ddf8ec1616d3dc71e43dcc2db@haskell.org> Message-ID: <065.a58ace1a6c18f827c4a5aad0178f1617@haskell.org> #15178: Implement DerivingVia -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: feature request | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: deriving, | GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4684 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: deriving => deriving, GHCProposal -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 29 16:13:35 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 May 2018 16:13:35 -0000 Subject: [GHC] #14268: Implement Explicit Foralls Proposal In-Reply-To: <046.b2c6e5199adb1a263d1f797400e3472d@haskell.org> References: <046.b2c6e5199adb1a263d1f797400e3472d@haskell.org> Message-ID: <061.7ebf407f1fc18f64b8a0bfac7c60171e@haskell.org> #14268: Implement Explicit Foralls Proposal -------------------------------------+------------------------------------- Reporter: johnleo | Owner: johnleo Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 13809, 14198 Related Tickets: #13809 | Differential Rev(s): Phab:D4046 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => GHCProposal -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 29 16:22:23 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 May 2018 16:22:23 -0000 Subject: [GHC] #12045: Visible kind application In-Reply-To: <051.f572b464c11770181720f8a1a7ec05a5@haskell.org> References: <051.f572b464c11770181720f8a1a7ec05a5@haskell.org> Message-ID: <066.add995c2ba074cdbd7f0a9c53a5058a9@haskell.org> #12045: Visible kind application -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Iceland_jack Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | TypeApplications TypeInType | GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): ​Phab:D2216 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: TypeApplications TypeInType => TypeApplications TypeInType GHCProposal -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 29 16:22:59 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 May 2018 16:22:59 -0000 Subject: [GHC] #14709: Extend the plugin mechanism to access program representation In-Reply-To: <044.2e69c960decc5283f7ff746e6b782d96@haskell.org> References: <044.2e69c960decc5283f7ff746e6b782d96@haskell.org> Message-ID: <059.417b2a9dd95fc0960cd4848c7edb7979@haskell.org> #14709: Extend the plugin mechanism to access program representation -------------------------------------+------------------------------------- Reporter: lazac | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: GHC API | Version: 8.2.2 Resolution: | Keywords: GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://phabricator.haskell.org/D4342 https://ghc.haskell.org/trac/ghc/wiki/ExtendedPluginsProposal| -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => GHCProposal -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 29 16:39:51 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 May 2018 16:39:51 -0000 Subject: [GHC] #9793: Some as-patterns could be accepted in pattern synonyms In-Reply-To: <045.e251d4b7f57881692430bb7253319357@haskell.org> References: <045.e251d4b7f57881692430bb7253319357@haskell.org> Message-ID: <060.16d9c5d7ff417b522b9b56093c09b247@haskell.org> #9793: Some as-patterns could be accepted in pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 7.8.3 checker) | Keywords: Resolution: fixed | PatternSynonyms GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | patsyn/should_fail/as-pattern Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1666 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: PatternSynonyms => PatternSynonyms GHCProposal -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 29 16:47:49 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 May 2018 16:47:49 -0000 Subject: [GHC] #14324: Consider deprecating STM invariant mechanism In-Reply-To: <046.7d9457872c0d5f0243f1b38705442b7b@haskell.org> References: <046.7d9457872c0d5f0243f1b38705442b7b@haskell.org> Message-ID: <061.40cdc6f97b6001ddf69b528b345b8c60@haskell.org> #14324: Consider deprecating STM invariant mechanism -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4372 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => GHCProposal -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 29 16:49:46 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 May 2018 16:49:46 -0000 Subject: [GHC] #10843: Allow do blocks without dollar signs as arguments In-Reply-To: <049.979a39a09d7a881598f53a6a6ce9bbe3@haskell.org> References: <049.979a39a09d7a881598f53a6a6ce9bbe3@haskell.org> Message-ID: <064.b736a5d2a51bcb3aa9d5f072fe400f81@haskell.org> #10843: Allow do blocks without dollar signs as arguments -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: akio Type: feature request | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.10.2 (Parser) | Resolution: fixed | Keywords: GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11706 | Differential Rev(s): Phab:D1219, Wiki Page: | Phab:D4260 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => GHCProposal -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 29 16:50:26 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 May 2018 16:50:26 -0000 Subject: [GHC] #14473: Implement Underscores in Numeric Literals Proposal (NumericUnderscores extension) In-Reply-To: <047.9478e62bd80e36e2a95f7745037003bc@haskell.org> References: <047.9478e62bd80e36e2a95f7745037003bc@haskell.org> Message-ID: <062.255528608b7fe467e9e4eeeb36eead27@haskell.org> #14473: Implement Underscores in Numeric Literals Proposal (NumericUnderscores extension) -------------------------------------+------------------------------------- Reporter: takenobu | Owner: takenobu Type: task | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13126 #9224 | Differential Rev(s): Phab:D4235 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => GHCProposal -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 29 16:52:01 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 May 2018 16:52:01 -0000 Subject: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. In-Reply-To: <049.7ed7d5ba2f5e5e856922764e36628b22@haskell.org> References: <049.7ed7d5ba2f5e5e856922764e36628b22@haskell.org> Message-ID: <064.52e05ef9d068f69961c4fea4d84d61af@haskell.org> #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. -------------------------------------+------------------------------------- Reporter: jpbernardy | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.6.1 Resolution: fixed | Keywords: deriving, | newcomer, GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | deriving/should_run/T7401, | deriving/should_run/T7401_fail Blocked By: | Blocking: Related Tickets: #10577, #13117 | Differential Rev(s): Phab:D4047 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: deriving, newcomer => deriving, newcomer, GHCProposal -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 29 16:52:42 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 May 2018 16:52:42 -0000 Subject: [GHC] #15195: Merge -XPolyKinds with -XTypeInType Message-ID: <047.c44c81564ca3186b8f7d6c799db31ecf@haskell.org> #15195: Merge -XPolyKinds with -XTypeInType -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D4748 | Wiki Page: -------------------------------------+------------------------------------- As described in [https://github.com/ghc-proposals/ghc- proposals/blob/master/proposals/0020-no-type-in-type.rst this accepted proposal]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 29 16:53:38 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 May 2018 16:53:38 -0000 Subject: [GHC] #14602: Implement the pattern synonym construction function signatures proposal In-Reply-To: <045.e40f2213ac4d80872fad159c9b3fe7a8@haskell.org> References: <045.e40f2213ac4d80872fad159c9b3fe7a8@haskell.org> Message-ID: <060.792e9d681f98d0abc01ccc56aab3b0d8@haskell.org> #14602: Implement the pattern synonym construction function signatures proposal -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | PatternSynonyms, GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: PatternSynonyms => PatternSynonyms, GHCProposal -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 29 16:54:13 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 May 2018 16:54:13 -0000 Subject: [GHC] #15195: Merge -XPolyKinds with -XTypeInType In-Reply-To: <047.c44c81564ca3186b8f7d6c799db31ecf@haskell.org> References: <047.c44c81564ca3186b8f7d6c799db31ecf@haskell.org> Message-ID: <062.c5171faf79ad223172d4bf44a87b87eb@haskell.org> #15195: Merge -XPolyKinds with -XTypeInType -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4748 Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * keywords: => GHCProposal -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 29 16:55:44 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 May 2018 16:55:44 -0000 Subject: [GHC] #13126: Support for hexadecimal floats In-Reply-To: <045.78755c3363c3135e2f66061ffc2a520b@haskell.org> References: <045.78755c3363c3135e2f66061ffc2a520b@haskell.org> Message-ID: <060.363a0321e9e49d2424d73876723fefb0@haskell.org> #13126: Support for hexadecimal floats -------------------------------------+------------------------------------- Reporter: lerkok | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3066 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => GHCProposal -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 29 17:00:12 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 May 2018 17:00:12 -0000 Subject: [GHC] #13126: Support for hexadecimal floats In-Reply-To: <045.78755c3363c3135e2f66061ffc2a520b@haskell.org> References: <045.78755c3363c3135e2f66061ffc2a520b@haskell.org> Message-ID: <060.a6602dec9c1dc611118595efbf746ec7@haskell.org> #13126: Support for hexadecimal floats -------------------------------------+------------------------------------- Reporter: lerkok | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3066 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => fixed Comment: This was implemented in commit b0b80e90c0382a6cdb61c96c860feac27482d6e8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 29 17:03:01 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 May 2018 17:03:01 -0000 Subject: [GHC] #14032: Can't splice TH quote with infix declaration for name in two different namespaces In-Reply-To: <050.88678544262d43e8177c20f56750d292@haskell.org> References: <050.88678544262d43e8177c20f56750d292@haskell.org> Message-ID: <065.d2e211b8a2935c1aed94a25a63df5591@haskell.org> #14032: Can't splice TH quote with infix declaration for name in two different namespaces -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => GHCProposal -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 29 17:13:17 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 May 2018 17:13:17 -0000 Subject: [GHC] #14343: bad pretty-printing of types with promoted data types In-Reply-To: <048.9dafa4d8103f25346932aca07d111b88@haskell.org> References: <048.9dafa4d8103f25346932aca07d111b88@haskell.org> Message-ID: <063.80e76b5b90e74732d263fbb9a06329e3@haskell.org> #14343: bad pretty-printing of types with promoted data types -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: andreash Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4746 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: => Phab:D4746 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 29 17:13:28 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 May 2018 17:13:28 -0000 Subject: [GHC] #14343: bad pretty-printing of types with promoted data types In-Reply-To: <048.9dafa4d8103f25346932aca07d111b88@haskell.org> References: <048.9dafa4d8103f25346932aca07d111b88@haskell.org> Message-ID: <063.f33cd06e0e364b34980dfd321cba4c02@haskell.org> #14343: bad pretty-printing of types with promoted data types -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: andreash Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4746 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 29 19:05:55 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 May 2018 19:05:55 -0000 Subject: [GHC] #15195: Merge -XPolyKinds with -XTypeInType In-Reply-To: <047.c44c81564ca3186b8f7d6c799db31ecf@haskell.org> References: <047.c44c81564ca3186b8f7d6c799db31ecf@haskell.org> Message-ID: <062.c42bc902f1719c9286f9419d901122d7@haskell.org> #15195: Merge -XPolyKinds with -XTypeInType -------------------------------------+------------------------------------- Reporter: goldfire | Owner: int-index Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4748 Wiki Page: | -------------------------------------+------------------------------------- Changes (by int-index): * cc: int-index (added) * owner: (none) => int-index -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 29 19:35:15 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 May 2018 19:35:15 -0000 Subject: [GHC] #9438: Dynamic GHCi doesn't support static libraries In-Reply-To: <042.626d31d9ed213d4613ac83aeb53010f5@haskell.org> References: <042.626d31d9ed213d4613ac83aeb53010f5@haskell.org> Message-ID: <057.b3ae5017f4c23b733c0e2c4a663b9933@haskell.org> #9438: Dynamic GHCi doesn't support static libraries -------------------------------------+------------------------------------- Reporter: egl | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Linking) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #8164, #14708, | Differential Rev(s): Phab:D4589 #15032 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): @bgamari It certainly *can* be implemented, but it really depends on how `DYNAMIC_GHC_PROGRAMS` is implemented. I haven't looked at the exact implementation but I would imagine, that in order for this to work, the .so must export all symbols as globals. I suspect (without looking) that ghc is linking the shared lib using `--whole-archive`. C static shared archives wouldn't be must of an issue. If you have no reference to the C code in your own code it doesn't matter if the symbols are not there. As you can't directly call C code anyway. static Haskell libraries are a different issue, loading a static archive would require all it's symbols to also be exported. Two libraries with the exact same z-encoded symbol names would produce a duplicate symbol error, while this need not be the case normally. This is why I *think* it's currently not supported. An obvious work-around would be to create multiple .so and link them in the same order as the static archives. So I think it can be supported, but will require a bit of changes to `DYNAMIC_GHC_PROGRAMS`. You'd also have to track these archives. It would be a bit annoying to recompile them on every scope change when they didn't change. A totally naive implementation would be a bit of a performance hit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 29 20:05:25 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 May 2018 20:05:25 -0000 Subject: [GHC] #15192: Refactor of Coercion In-Reply-To: <047.060aeef3805df87e61a1408a60ab4dd6@haskell.org> References: <047.060aeef3805df87e61a1408a60ab4dd6@haskell.org> Message-ID: <062.8b04ad5de2c2d7cfa976e490a6bec91f@haskell.org> #15192: Refactor of Coercion -------------------------------------+------------------------------------- Reporter: ningning | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4747 Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * cc: sweirich@… (added) Comment: I agree with comment:5. Note that the new form is essentially a generalized form of `Refl`, which also has an unrestricted role parameter. One area where the new coercion form is simpler is when we need `t ~r (t |> g)`. Currently, this is `Sym (Coherence (Refl r t) g)`. The new form would be `EraseEqCo r t (CastTy t g) g`. I do suppose that, as sharing is destroyed, the new form could be worse than the original one. The truth is that Stephanie and I have been using this new form in our work for quite some time now, and this feels like just bringing GHC up to speed. But perhaps the old form is more convenient for implementation. I'd love to bring Stephanie in on the conversation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 29 20:23:42 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 May 2018 20:23:42 -0000 Subject: [GHC] Batch modify: #13002 In-Reply-To: <042.d5091e410dc3dcdbe89726dec36bf65b@haskell.org> References: <042.d5091e410dc3dcdbe89726dec36bf65b@haskell.org> Message-ID: <042.d5091e410dc3dcdbe89726dec36bf65b@haskell.org> Batch modification to #13002 by bgamari: milestone to 8.6.1 Comment: Ticket retargeted after milestone closed -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 29 20:35:00 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 May 2018 20:35:00 -0000 Subject: [GHC] #15190: disable haddock disables building of manuals In-Reply-To: <050.a65b056fae49f3a9302bf89347340570@haskell.org> References: <050.a65b056fae49f3a9302bf89347340570@haskell.org> Message-ID: <065.c7c5fe37c7998f7ad82bf11a27784e9c@haskell.org> #15190: disable haddock disables building of manuals -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Build System | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: This is one of the many issues which I think we should just punt on until Hadrian. We are very close now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 29 20:35:18 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 May 2018 20:35:18 -0000 Subject: [GHC] #15190: disable haddock disables building of manuals In-Reply-To: <050.a65b056fae49f3a9302bf89347340570@haskell.org> References: <050.a65b056fae49f3a9302bf89347340570@haskell.org> Message-ID: <065.7b3e65e0fce945bf6fda13da9e5b904c@haskell.org> #15190: disable haddock disables building of manuals -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Build System | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: closed => new * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 29 20:44:08 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 May 2018 20:44:08 -0000 Subject: [GHC] #15147: Type checker plugin receives Wanteds that are not completely unflattened In-Reply-To: <046.7de470c11f4eabed34171ca75a3b8063@haskell.org> References: <046.7de470c11f4eabed34171ca75a3b8063@haskell.org> Message-ID: <061.8080e2cca99436040610321ee7a6244a@haskell.org> #15147: Type checker plugin receives Wanteds that are not completely unflattened -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.1 checker) | Keywords: Resolution: | TypeCheckerPlugins Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I've looked at why the plugin is seeing flattened givens. It has been this way for some time. Currently, when we go "under" an implication constraint we flatten the Givens; and we only unflatten them when we've finished with that implication. When calling a plugin, we have Givens from a whole stack of enclosing implications, and none of them will be unflattened. See the `inert_fsks` field of `InertSet`; and `TcSMonad.unflattenGivens` which uses that field to guide unflattening. You can see that `unflattenGivens` is called by `nestImplicTcS` which goes under an implication. It's quite awkward to unflatten them, in fact... even accessing the unflattening info for the stack of implications would require extra plumbing. Humph. How bad would it be just to document the status quo? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 29 21:09:12 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 May 2018 21:09:12 -0000 Subject: [GHC] #14059: COMPLETE sets don't work at all with data family instances In-Reply-To: <050.1b97217d892621b52fdef83d9bc47bf0@haskell.org> References: <050.1b97217d892621b52fdef83d9bc47bf0@haskell.org> Message-ID: <065.d1ece931aabfe83123a99b6274c1736f@haskell.org> #14059: COMPLETE sets don't work at all with data family instances -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | PatternSynonyms, | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Evidently, this changed a bit from GHC 8.2 to 8.4. In 8.4, you actually //do// get a warning about `wobble`: {{{ $ /opt/ghc/8.4.2/bin/ghci Bug.hs GHCi, version 8.4.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:23:1: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In an equation for ‘wibble’: Patterns not matched: SFalse | 23 | wibble STrue = True | ^^^^^^^^^^^^^^^^^^^ Bug.hs:26:1: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In an equation for ‘wobble’: Patterns not matched: _ | 26 | wobble STooGoodToBeTrue = True | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} Still, this doesn't seem quite right, as the warning says `Patterns not matched: _` instead of `Patterns not matched: SFalse`, like its counterpart `wibble`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 29 21:20:25 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 May 2018 21:20:25 -0000 Subject: [GHC] #15189: Avoid word "transformer" in the documentation of ST In-Reply-To: <051.babfb617b882c0b638e02ac50b14cd85@haskell.org> References: <051.babfb617b882c0b638e02ac50b14cd85@haskell.org> Message-ID: <066.6e21e3d79c4b2d1aa00093bf12627ffd@haskell.org> #15189: Avoid word "transformer" in the documentation of ST -------------------------------------+------------------------------------- Reporter: ulysses4ever | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Documentation | Version: 8.2.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => newcomer Comment: I agree that the current wording isn't as helpful as it could be. Do you think you could submit a patch fixing this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 29 21:23:22 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 May 2018 21:23:22 -0000 Subject: [GHC] #15189: Avoid word "transformer" in the documentation of ST In-Reply-To: <051.babfb617b882c0b638e02ac50b14cd85@haskell.org> References: <051.babfb617b882c0b638e02ac50b14cd85@haskell.org> Message-ID: <066.10308702adb189765d5f6b3c3e7d422a@haskell.org> #15189: Avoid word "transformer" in the documentation of ST -------------------------------------+------------------------------------- Reporter: ulysses4ever | Owner: ulysses4ever Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Documentation | Version: 8.2.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ulysses4ever): * owner: (none) => ulysses4ever Comment: Absolutely. I haven't yet only because I wanted some feedback first. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue May 29 21:41:41 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 May 2018 21:41:41 -0000 Subject: [GHC] #14059: COMPLETE sets don't work at all with data family instances In-Reply-To: <050.1b97217d892621b52fdef83d9bc47bf0@haskell.org> References: <050.1b97217d892621b52fdef83d9bc47bf0@haskell.org> Message-ID: <065.acbcaf0e31661281f32e36ff19da8a5d@haskell.org> #14059: COMPLETE sets don't work at all with data family instances -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | PatternSynonyms, | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Unfortunately, this means that the non-data-family instance version has also //regressed//. That is to say, this program: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE PatternSynonyms #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} {-# OPTIONS_GHC -Wincomplete-patterns #-} module Foo where data SBool (z :: Bool) where SFalse :: SBool False STrue :: SBool True pattern STooGoodToBeTrue :: forall (z :: Bool). () => z ~ True => SBool z pattern STooGoodToBeTrue = STrue {-# COMPLETE SFalse, STooGoodToBeTrue #-} wibble :: SBool z -> Bool wibble STrue = True wobble :: SBool z -> Bool wobble STooGoodToBeTrue = True }}} Used to give the right warning in GHC 8.2 (as shown in the original description), but on GHC 8.4, it now demonstrates the same problem as in the version with data families: {{{ $ /opt/ghc/8.4.2/bin/ghci Foo.hs GHCi, version 8.4.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Foo ( Foo.hs, interpreted ) Foo.hs:20:1: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In an equation for ‘wibble’: Patterns not matched: SFalse | 20 | wibble STrue = True | ^^^^^^^^^^^^^^^^^^^ Foo.hs:23:1: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In an equation for ‘wobble’: Patterns not matched: _ | 23 | wobble STooGoodToBeTrue = True | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} I suppose the uniformity is comforting, at least... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 30 01:46:03 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 May 2018 01:46:03 -0000 Subject: [GHC] #14444: Linker limit on OS X Sierra breaks builds for big projects In-Reply-To: <049.ef1cbd3eecd105a31deac573ded19c35@haskell.org> References: <049.ef1cbd3eecd105a31deac573ded19c35@haskell.org> Message-ID: <064.d823e93db6a8a9eb250449bf89be2e18@haskell.org> #14444: Linker limit on OS X Sierra breaks builds for big projects -------------------------------------+------------------------------------- Reporter: dredozubov | Owner: angerman Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Linking) | Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4717 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D4717 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 30 07:28:46 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 May 2018 07:28:46 -0000 Subject: [GHC] #15147: Type checker plugin receives Wanteds that are not completely unflattened In-Reply-To: <046.7de470c11f4eabed34171ca75a3b8063@haskell.org> References: <046.7de470c11f4eabed34171ca75a3b8063@haskell.org> Message-ID: <061.4036d2b72247dbc21d9081977aa0d699@haskell.org> #15147: Type checker plugin receives Wanteds that are not completely unflattened -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.1 checker) | Keywords: Resolution: | TypeCheckerPlugins Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by adamgundry): Originally plugins would see flattened givens but unflattened wanteds (https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker#Callingpluginsfromthetypechecker). The issue here is that the wanteds are now sometimes not fully unflattened, isn't it? If we were to provide only flattened wanteds, that might well be more consistent, but we're back to plugins needing to implement unflattening themselves... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 30 07:37:13 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 May 2018 07:37:13 -0000 Subject: [GHC] #15149: Identical distinct type family fields miscompiled In-Reply-To: <051.0ce70e3fb52ab219faaf194260ba75f3@haskell.org> References: <051.0ce70e3fb52ab219faaf194260ba75f3@haskell.org> Message-ID: <066.cd5d6347c4cc08cc94cf8cf5ed707a0a@haskell.org> #15149: Identical distinct type family fields miscompiled -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: ORF 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: | -------------------------------------+------------------------------------- Comment (by adamgundry): Yes, I can try to take a look at this. > My baseline thought is that `C { x = e1, y = e2 }` should have `x` and `y` as `OccNames` right up to the type checker. And that would be so in TH syntax to. I agree that this would be simpler (in the presence of `DisambiguateRecordFields`, `DuplicateRecordFields`, etc.). I'm concerned that it might impact TH users though, as they will have only an `OccName` where previously they had a `Name` (and they might not easily be able to reliably look up the `OccName` because of precisely this ticket). Should this go through ghc-proposals, or is there another process for discussing TH changes? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 30 10:56:36 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 May 2018 10:56:36 -0000 Subject: [GHC] #14059: COMPLETE sets don't work at all with data family instances In-Reply-To: <050.1b97217d892621b52fdef83d9bc47bf0@haskell.org> References: <050.1b97217d892621b52fdef83d9bc47bf0@haskell.org> Message-ID: <065.cc0953f3067e1a782bb4a4fe3beec040@haskell.org> #14059: COMPLETE sets don't work at all with data family instances -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | PatternSynonyms, | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): OK, I at least know why the error messages are different in GHC 8.4. It's due to the fix for #14135, which filters out candidate conlikes from `COMPLETE` sets with [http://git.haskell.org/ghc.git/blob/857005a762a12e021c3cc65b729bd6263b7145fb:/compiler/deSugar/Check.hs#l1323 this criterion]: {{{#!hs isValidCompleteMatch :: Type -> [ConLike] -> Bool isValidCompleteMatch ty = isJust . mapM (flip tcMatchTy ty . resTy . conLikeFullSig) where resTy (_, _, _, _, _, _, res_ty) = res_ty }}} I believe this criterion is too conservative, since it requires the type of every conlike in a `COMPLETE` set to match the type of the scrutinee. But that assumption doesn't hold true when one of the conlikes is for a GADT constructor, as in the second example from the description: {{{#!hs data SBool (z :: Bool) where SFalse :: SBool False STrue :: SBool True pattern STooGoodToBeTrue :: forall (z :: Bool). () => z ~ True => SBool z pattern STooGoodToBeTrue = STrue {-# COMPLETE SFalse, STooGoodToBeTrue #-} wobble :: SBool z -> Bool wobble STooGoodToBeTrue = True }}} Here, the type of the scrutinee in `wobble` is `SBool z`, but the type of the first conlike in the `COMPLETE` set is `SBool False`, so `tcMatchTy (SBool False) (SBool z)` will return `Nothing`, which means we filter out that `COMPLETE` set entirely. This is terrible, since `SFalse` //can// be pattern-matched on in `wobble`! This leads me to believe that we should only be performing this `tcMatchTy` check on pattern synonym constructors, not data constructors. I applied this change to `isValidCompleteMatch` locally and sure enough, the error message in this ticket went back to what is was in 8.2. I'll prepare a patch with this payload before investigating the underlying issue in this ticket further. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 30 10:58:40 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 May 2018 10:58:40 -0000 Subject: [GHC] #15196: Invert floating point comparisons such that no extra parity check is required. Message-ID: <047.7b7b81a2e120787e43a042c6cb25c543@haskell.org> #15196: Invert floating point comparisons such that no extra parity check is required. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (NCG) | Keywords: CodeGen | 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 comment pretty much explains it already: {{{ -- We have to worry about unordered operands (eg. comparisons -- against NaN). If the operands are unordered, the comparison -- sets the parity flag, carry flag and zero flag. -- All comparisons are supposed to return false for unordered -- operands except for !=, which returns true. -- -- Optimisation: we don't have to test the parity flag if we -- know the test has already excluded the unordered case: eg > -- and >= test for a zero carry flag, which can only occur for -- ordered operands. -- -- ToDo: by reversing comparisons we could avoid testing the -- parity flag in more cases. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 30 11:01:23 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 May 2018 11:01:23 -0000 Subject: [GHC] #15196: Invert floating point comparisons such that no extra parity check is required. In-Reply-To: <047.7b7b81a2e120787e43a042c6cb25c543@haskell.org> References: <047.7b7b81a2e120787e43a042c6cb25c543@haskell.org> Message-ID: <062.506bd8016c499f9fceab879d8876ab9e@haskell.org> #15196: Invert floating point comparisons such that no extra parity check is required. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (NCG) | Version: 8.4.3 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by AndreasK: Old description: > This comment pretty much explains it already: > > {{{ > -- We have to worry about unordered operands (eg. comparisons > -- against NaN). If the operands are unordered, the comparison > -- sets the parity flag, carry flag and zero flag. > -- All comparisons are supposed to return false for unordered > -- operands except for !=, which returns true. > -- > -- Optimisation: we don't have to test the parity flag if we > -- know the test has already excluded the unordered case: eg > > -- and >= test for a zero carry flag, which can only occur for > -- ordered operands. > -- > -- ToDo: by reversing comparisons we could avoid testing the > -- parity flag in more cases. > }}} New description: This comment pretty much explains it already: {{{ -- We have to worry about unordered operands (eg. comparisons -- against NaN). If the operands are unordered, the comparison -- sets the parity flag, carry flag and zero flag. -- All comparisons are supposed to return false for unordered -- operands except for !=, which returns true. -- -- Optimisation: we don't have to test the parity flag if we -- know the test has already excluded the unordered case: eg > -- and >= test for a zero carry flag, which can only occur for -- ordered operands. -- -- ToDo: by reversing comparisons we could avoid testing the -- parity flag in more cases. }}} This would turn a sequence of {{{ jp foo jb bar jmp foo }}} into: {{{ jge foo jmp bar }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 30 11:10:18 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 May 2018 11:10:18 -0000 Subject: [GHC] #15192: Refactor of Coercion In-Reply-To: <047.060aeef3805df87e61a1408a60ab4dd6@haskell.org> References: <047.060aeef3805df87e61a1408a60ab4dd6@haskell.org> Message-ID: <062.5100eaae1274aba0320dd39859f0c06a@haskell.org> #15192: Refactor of Coercion -------------------------------------+------------------------------------- Reporter: ningning | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4747 Wiki Page: | -------------------------------------+------------------------------------- Comment (by sweirich): This new form may be more efficient if there are multiple uses of Coherence needed --- one EraseEqCo can stand in for many casts (on either side). However, If coherence has better sharing in some situations, then perhaps we don't want to lose that information. There is no reason why we can't have both in the implementation. At least until we can see if EraseEqCo is useful in connection with other extensions. Richard and I both found it useful in generating coercions in our proofs. Perhaps that will show up in some of the coercions that GHC needs to construct. Eventually, we may want to get rid of both of these coercions. In other words --- we can allow Core to work "up-to-erasure-equivalence", as in the system in the appendix of Richard's thesis. In that case, we wouldn't need to use Coherence or EraseEqCo very much (If at all). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 30 11:46:48 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 May 2018 11:46:48 -0000 Subject: [GHC] #14059: COMPLETE sets don't work at all with data family instances In-Reply-To: <050.1b97217d892621b52fdef83d9bc47bf0@haskell.org> References: <050.1b97217d892621b52fdef83d9bc47bf0@haskell.org> Message-ID: <065.c69aa682b7f746eb9502ee6c2278b911@haskell.org> #14059: COMPLETE sets don't work at all with data family instances -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | PatternSynonyms, | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4752 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: => Phab:D4752 Comment: Phab:D4752 fixes the issue discovered starting at comment:5. As mentioned earlier, it does not fix the entirety of #14059, but this patch at least restores the error message back to what it was in 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 30 12:09:41 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 May 2018 12:09:41 -0000 Subject: [GHC] #15192: Refactor of Coercion In-Reply-To: <047.060aeef3805df87e61a1408a60ab4dd6@haskell.org> References: <047.060aeef3805df87e61a1408a60ab4dd6@haskell.org> Message-ID: <062.f8f48d8900009d86df55ab99d50ef3e4@haskell.org> #15192: Refactor of Coercion -------------------------------------+------------------------------------- Reporter: ningning | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4747 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I agree with Stephanie's first few paragraphs, but not her last one. GHC ''already'' works up to erasure-equivalence. That is, `eqType` returns `True` whenever two types are erasure-equivalent (and have the same kinds). But we still need the coherence coercions, because they sometimes change kinds. I guess that will change once we move to homogeneous equality, though... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 30 14:02:22 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 May 2018 14:02:22 -0000 Subject: [GHC] #15187: HEAD: Validate failure when not TABLES_NEXT_TO_CODE In-Reply-To: <047.0475616412dd439857a1edcf6a1fa59f@haskell.org> References: <047.0475616412dd439857a1edcf6a1fa59f@haskell.org> Message-ID: <062.96bcb18e06133144e0a3da2f20d9ca0f@haskell.org> #15187: HEAD: Validate failure when not TABLES_NEXT_TO_CODE -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4741 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"bdfc85b8cbcb49cc879aebad4cc1b50123f8c02c/ghc" bdfc85b8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bdfc85b8cbcb49cc879aebad4cc1b50123f8c02c" Fix validate for GHCi without TABLES_NEXT_TO_CODE Suppress warning about unused match. Fixes #15187 Reviewers: bgamari, simonmar, erikd, hvr Reviewed By: bgamari, simonmar Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4741 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 30 14:02:22 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 May 2018 14:02:22 -0000 Subject: [GHC] #15146: Documentation: ScopedTypeVariables feature not mentioned/misleadingly described In-Reply-To: <043.d95bdea9ee71d4ecb11e1c8b5424eb30@haskell.org> References: <043.d95bdea9ee71d4ecb11e1c8b5424eb30@haskell.org> Message-ID: <058.8fd3e200716fb90c190fe96621d73b8c@haskell.org> #15146: Documentation: ScopedTypeVariables feature not mentioned/misleadingly described -------------------------------------+------------------------------------- Reporter: AntC | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Documentation | Version: 8.2.2 Resolution: | Keywords: newcomer, | ScopedTypeVariables Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"2ea93a7db7dcd9381b6d9e017ff015addd2adf5c/ghc" 2ea93a7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2ea93a7db7dcd9381b6d9e017ff015addd2adf5c" Improve the documentation of lexically scoped type variables Section 10.16 in the Users Guide. Also reviewed mentions/links from other sections: none need revision. Fixes #15146. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 30 14:52:39 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 May 2018 14:52:39 -0000 Subject: [GHC] #15197: Apparent missing dependency in ghc-heap Message-ID: <046.f9380793ce8ad25be083749857e75f4a@haskell.org> #15197: Apparent missing dependency in ghc-heap -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | 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: -------------------------------------+------------------------------------- The `ghc-heap` library appears to be missing a dependency from `GHC.Exts.Heap.Closures` to `GHC.Exts.Heap.InfoTableProf`. This causes the vanilla build to fail (in particular when building the profiled way): {{{ “inplace/bin/ghc-stage1” -hisuf p_hi -osuf p_o -hcsuf p_hc -static -prof -eventlog -H32m -O -Wall -this-unit-id ghc-heap-8.5 -hide-all- packages -i -ilibraries/ghc-heap/. -ilibraries/ghc-heap/dist-install/build -Ilibraries/ghc-heap/dist-install/build -ilibraries/ghc-heap/dist- install/build/./autogen -Ilibraries/ghc-heap/dist-install/build/./autogen -Ilibraries/ghc-heap/. -optP-include -optPlibraries/ghc-heap/dist- install/build/./autogen/cabal_macros.h -package-id base-4.12.0.0 -package- id ghc-prim-0.5.3 -package-id rts -Wall -XHaskell2010 -O2 -no-user- package-db -rtsopts -Wno-deprecated-flags -Wnoncanonical-monad- instances -odir libraries/ghc-heap/dist-install/build -hidir libraries /ghc-heap/dist-install/build -stubdir libraries/ghc-heap/dist- install/build -c libraries/ghc-heap/./GHC/Exts/Heap/Closures.hs -o libraries/ghc-heap/dist-install/build/GHC/Exts/Heap/Closures.p_o -dyno libraries/ghc-heap/dist- install/build/GHC/Exts/Heap/Closures.dyn_olibraries/ghc- heap/GHC/Exts/Heap/Closures.hs:23:1: error: Could not find module ‘GHC.Exts.Heap.InfoTableProf’ It is a member of the hidden package ‘ghc-heap-8.5’. You can run ‘:set -package ghc-heap’ to expose it. (Note: this unloads all the modules in the current scope.) Use -v to see a list of the files searched for. | 23 | import GHC.Exts.Heap.InfoTableProf | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} Building the `libraries/ghc-heap/dist- install/GHC/Exts/Heap/InfoTableProf.p_o` manually allows the build to proceed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 30 15:22:21 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 May 2018 15:22:21 -0000 Subject: [GHC] #15197: Apparent missing dependency in ghc-heap In-Reply-To: <046.f9380793ce8ad25be083749857e75f4a@haskell.org> References: <046.f9380793ce8ad25be083749857e75f4a@haskell.org> Message-ID: <061.2c7e9a5a0a9e2b39b4c8094bc1cd6e93@haskell.org> #15197: Apparent missing dependency in ghc-heap -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): The problem is apparently that the import of `InfoTableProf` is guarded behind a `#if defined(PROFILING)`: {{{#!hs #if defined(PROFILING) import GHC.Exts.Heap.InfoTableProf #else import GHC.Exts.Heap.InfoTable #endif }}} Looking at the GHC-generated dependency file I see the following, {{{#!make libraries/ghc-heap/dist-install/build/GHC/Exts/Heap/Closures.p_o : libraries/ghc-heap/dist-install/build/GHC/Exts/Heap/InfoTable.p_hi }}} It looks to me like `ghc -M` isn't correctly accounting for ways when generating its dependency graph. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 30 15:23:13 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 May 2018 15:23:13 -0000 Subject: [GHC] #15197: Apparent missing dependency in ghc-heap In-Reply-To: <046.f9380793ce8ad25be083749857e75f4a@haskell.org> References: <046.f9380793ce8ad25be083749857e75f4a@haskell.org> Message-ID: <061.5cfdc98c8a7b2a70c7c8829dae2e5af6@haskell.org> #15197: Apparent missing dependency in ghc-heap -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4753 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D4753 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 30 15:40:03 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 May 2018 15:40:03 -0000 Subject: [GHC] #15187: HEAD: Validate failure when not TABLES_NEXT_TO_CODE In-Reply-To: <047.0475616412dd439857a1edcf6a1fa59f@haskell.org> References: <047.0475616412dd439857a1edcf6a1fa59f@haskell.org> Message-ID: <062.5cef929080577dcbf6438f3f1f34edb6@haskell.org> #15187: HEAD: Validate failure when not TABLES_NEXT_TO_CODE -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4741 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 30 15:40:27 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 May 2018 15:40:27 -0000 Subject: [GHC] #15146: Documentation: ScopedTypeVariables feature not mentioned/misleadingly described In-Reply-To: <043.d95bdea9ee71d4ecb11e1c8b5424eb30@haskell.org> References: <043.d95bdea9ee71d4ecb11e1c8b5424eb30@haskell.org> Message-ID: <058.1ae9cc61653d0ea2c8107bb0d765caad@haskell.org> #15146: Documentation: ScopedTypeVariables feature not mentioned/misleadingly described -------------------------------------+------------------------------------- Reporter: AntC | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Documentation | Version: 8.2.2 Resolution: fixed | Keywords: newcomer, | ScopedTypeVariables Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 30 15:58:08 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 May 2018 15:58:08 -0000 Subject: [GHC] #15062: num009 is incredibly platform-sensitive In-Reply-To: <046.fd26963ba1ba8046e379799dd9722c15@haskell.org> References: <046.fd26963ba1ba8046e379799dd9722c15@haskell.org> Message-ID: <061.53fca5b9d479c693e6dc16bdebb8ac6e@haskell.org> #15062: num009 is incredibly platform-sensitive -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Test Suite | Version: 8.2.2 Resolution: | Keywords: ci-breakage Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Nothing is broken; all of the variations I've seen are at numerical precision. This is just expected variation from platform-to-platform. The transcendental operations tested by `num009` are typically implemented in terms of the platform's supported floating point operations by `libc`. `libc`s vary in their implementation strategies for these operations. Moreover, the extra precision of x87 (which we still use by default on x86) has an impact. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 30 15:58:45 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 May 2018 15:58:45 -0000 Subject: [GHC] #15062: num009 is incredibly platform-sensitive In-Reply-To: <046.fd26963ba1ba8046e379799dd9722c15@haskell.org> References: <046.fd26963ba1ba8046e379799dd9722c15@haskell.org> Message-ID: <061.9f3cf5636efc23d3e8e033fd7a5f516b@haskell.org> #15062: num009 is incredibly platform-sensitive -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Test Suite | Version: 8.2.2 Resolution: | Keywords: ci-breakage Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Here is the i386 output for posterity, {{{ Actual stdout output differs from expected: --- ../../libraries/base/tests/Numeric/num009.run/num009.stdout.normalised 2018-04-19 18:22:43.131191836 +0000 +++ ../../libraries/base/tests/Numeric/num009.run/num009.run.stdout.normalised 2018-04-19 18:22:43.131191836 +0000 @@ -1 +1,81 @@ +uh oh! sind 3.141592653589793 +1.2246467991473532e-16 +1.2246063538223773e-16 +(4967757600021511,-105) +(4967593534291968,-105) +uh oh! sind 1.0e10 +-0.4875060250875107 +-0.48750602507627 +(-8782127811699939,-54) +(-8782127811497445,-54) +uh oh! sind 1.0e20 +-0.6452512852657808 +-0.7469218912594929 +(-5811906895766608,-53) +(-6727674302302237,-53) +uh oh! sinf 1.0e20 +0.6565767 +-0.7710884 +(11015529,-24) +(-12936717,-24) +uh oh! cosd 1.5707963267948966 +6.123233995736766e-17 +6.123031769111886e-17 +(4967757600021511,-106) +(4967593534291968,-106) +uh oh! cosd 1.0e10 +0.873119622676856 +0.8731196226831323 +(7864362414674714,-53) +(7864362414731245,-53) +uh oh! cosd 1.0e20 +0.7639704044417283 +-0.6649117899070088 +(6881233657531709,-53) +(-5988992978518909,-53) +uh oh! cosf 1.0e20 +0.7542593 +0.63672805 +(12654371,-24) +(10682524,-24) +uh oh! tand 3.141592653589793 +-1.2246467991473532e-16 +-1.2246063538223773e-16 +(-4967757600021511,-105) +(-4967593534291968,-105) +uh oh! tand 1.5707963267948966 +1.633123935319537e16 +1.6331778728383844e16 +(8165619676597685,1) +(8165889364191922,1) +uh oh! tand 1.0e10 +-0.5583496378112418 +-0.5583496377943541 +(-5029166441578320,-53) +(-5029166441426209,-53) +uh oh! tand 1.0e20 +-0.8446024630198843 +1.123339821307656 +(-7607502675465108,-53) +(5059072800651599,-52) +uh oh! tanf 1.5707964 +-2.2877334e7 +-2.2877332e7 +(-11438667,1) +(-11438666,1) +uh oh! tanf 1.0471976 +1.732051 +1.7320509 +(14529497,-23) +(14529496,-23) +uh oh! tanf 1.0e10 +-0.55834967 +-0.5583496 +(-9367553,-24) +(-9367552,-24) +uh oh! tanf 1.0e20 +0.870492 +-1.2110169 +(14604432,-24) +(-10158746,-23) Done *** unexpected failure for num009(normal) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 30 16:06:22 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 May 2018 16:06:22 -0000 Subject: [GHC] #15061: print022 testcase fails on i386 In-Reply-To: <046.070201c29a49dce5435517538bdcfad1@haskell.org> References: <046.070201c29a49dce5435517538bdcfad1@haskell.org> Message-ID: <061.6a466fb66df4aad59701d46177789f6c@haskell.org> #15061: print022 testcase fails on i386 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: GHCi | Version: 8.2.2 Resolution: | Keywords: ci-breakage Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I suspect the `!!` error is in fact caused by memory unsafety. I do wonder where the failing call site is, however. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 30 16:08:51 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 May 2018 16:08:51 -0000 Subject: [GHC] #14890: Make Linux slow validate green In-Reply-To: <046.a107a76cbb0183d36ada5ee5738b1b26@haskell.org> References: <046.a107a76cbb0183d36ada5ee5738b1b26@haskell.org> Message-ID: <061.b28cbecf173a59f47b479068d5d414e2@haskell.org> #14890: Make Linux slow validate green -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alpmestan Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D4546, D4636, Wiki Page: | D4712 -------------------------------------+------------------------------------- Comment (by bgamari): > We want to run it on a nightly basis right? Or per-commit? Right, I think nightly is all we have the capacity for at the moment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 30 16:21:14 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 May 2018 16:21:14 -0000 Subject: [GHC] #15163: non coercion variable in coVarKindsTypesRole In-Reply-To: <048.b3dbe8c60de34c10b2c3141afc368cad@haskell.org> References: <048.b3dbe8c60de34c10b2c3141afc368cad@haskell.org> Message-ID: <063.1485f4eb87ae8207ad95954e0407f837@haskell.org> #15163: non coercion variable in coVarKindsTypesRole -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.4.4 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T14732 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4725 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.4.4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 30 16:23:46 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 May 2018 16:23:46 -0000 Subject: [GHC] #14492: Tiered memory allocation restricts available memory In-Reply-To: <044.e21e37476590d999c81ca942af908658@haskell.org> References: <044.e21e37476590d999c81ca942af908658@haskell.org> Message-ID: <059.0e1dd2415432c697afb78b6d5ce92375@haskell.org> #14492: Tiered memory allocation restricts available memory -------------------------------------+------------------------------------- Reporter: unode | Owner: bgamari Type: bug | Status: patch Priority: high | Milestone: 8.6.1 Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: memory ulimit Operating System: Linux | Architecture: x86_64 Type of failure: Poor/confusing | (amd64) error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4215 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => high Comment: Right, I have a patch pending that I'll try to dust off. Thanks for the ping! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 30 18:00:32 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 May 2018 18:00:32 -0000 Subject: [GHC] #14789: GHCi fails to garbage collect declaration `l = length [1..10^8]` entered at prompt In-Reply-To: <045.8cebee0eb74d2ceeb0d4f66066496471@haskell.org> References: <045.8cebee0eb74d2ceeb0d4f66066496471@haskell.org> Message-ID: <060.57d0bc57c5e9b7b91e4f2270b9b73704@haskell.org> #14789: GHCi fails to garbage collect declaration `l = length [1..10^8]` entered at prompt -------------------------------------+------------------------------------- Reporter: kabuhr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.2 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by bgamari): Just noticed this; quite an interesting issue. I was indeed able to reproduce this in GHC 8.4.1 and confirmed that `performMajorGC` does not cause reclaim. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 30 18:13:08 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 May 2018 18:13:08 -0000 Subject: [GHC] #14789: GHCi fails to garbage collect declaration `l = length [1..10^8]` entered at prompt In-Reply-To: <045.8cebee0eb74d2ceeb0d4f66066496471@haskell.org> References: <045.8cebee0eb74d2ceeb0d4f66066496471@haskell.org> Message-ID: <060.62562aa95f074aec76fb4cc79a55d0c4@haskell.org> #14789: GHCi fails to garbage collect declaration `l = length [1..10^8]` entered at prompt -------------------------------------+------------------------------------- Reporter: kabuhr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.2 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by bgamari): Here is the code produced (from `-ddump-rn -ddump-simpl -ddump-bcos`) by the `let l` form, {{{ λ> let l = length [1..10^8] ==================== Renamer ==================== let l_a2bl = length [1 .. 10 ^ 8] ==================== Simplified expression ==================== GHC.Base.returnIO @ [()] (GHC.Types.: @ () ((Data.Foldable.length @ [] Data.Foldable.$fFoldable[] @ GHC.Integer.Type.Integer (GHC.Enum.enumFromTo @ GHC.Integer.Type.Integer GHC.Enum.$fEnumInteger 1 (GHC.Real.^ @ GHC.Integer.Type.Integer @ GHC.Integer.Type.Integer GHC.Num.$fNumInteger GHC.Real.$fIntegralInteger 10 8))) `cast` (UnsafeCo representational GHC.Types.Int () :: (GHC.Types.Int :: *) ~R# (() :: *))) (GHC.Types.[] @ ())) ==================== Proto-BCOs ==================== ProtoBCO ExprTopLevel_E0#0 []: let sat_s3Wi = ... in ... bitmap: 0 [] ALLOC_AP 0 PUSH_BCO ProtoBCO sat_s3Wi#0 []: let sat_s3Wh = ... in ... bitmap: 0 [] ALLOC_AP 0 PUSH_BCO ProtoBCO sat_s3Wh#0 []: let sat_s3Wg = ... in ... bitmap: 0 [] ALLOC_AP 0 PUSH_BCO ProtoBCO sat_s3Wg#0 []: let sat_s3Wf = ... in ... bitmap: 0 [] PUSH_UBX (1) 8# PACK GHC.Integer.Type.S# 1 PUSH_UBX (1) 10# PACK GHC.Integer.Type.S# 1 PUSH_LL 1 0 PUSH_G GHC.Real.$fIntegralInteger PUSH_G GHC.Num.$fNumInteger PUSH_APPLY_PPPP PUSH_G GHC.Real.^ SLIDE 6 2 ENTER MKAP 0 words, 1 stkoff PUSH_UBX (1) 1# PACK GHC.Integer.Type.S# 1 PUSH_LL 1 0 PUSH_G GHC.Enum.$fEnumInteger PUSH_APPLY_PPP PUSH_G GHC.Enum.enumFromTo SLIDE 5 2 ENTER MKAP 0 words, 1 stkoff PUSH_L 0 PUSH_G Data.Foldable.$fFoldable[] PUSH_APPLY_PP PUSH_G Data.Foldable.length SLIDE 4 1 ENTER MKAP 0 words, 1 stkoff PUSH_G GHC.Types.[] PUSH_L 1 PACK : 2 PUSH_L 0 PUSH_APPLY_P PUSH_G GHC.Base.returnIO SLIDE 3 2 ENTER }}} Here is the same output for the `let`-less form, {{{ λ> l = length [1..10^8] ==================== Renamer ==================== interactive:Ghci2.l = length [1 .. 10 ^ 8] ==================== Tidy Core ==================== Result size of Tidy Core = {terms: 25, types: 11, coercions: 0, joins: 0/0} -- RHS size: {terms: 10, types: 5, coercions: 0, joins: 0/0} l :: Int [GblId] l = length @ [] Data.Foldable.$fFoldable[] @ Integer (enumFromTo @ Integer GHC.Enum.$fEnumInteger 1 (^ @ Integer @ Integer GHC.Num.$fNumInteger GHC.Real.$fIntegralInteger 10 8)) -- RHS size: {terms: 1, types: 0, coercions: 0, joins: 0/0} $trModule1_r3XB :: GHC.Prim.Addr# [GblId, Caf=NoCafRefs] $trModule1_r3XB = "interactive"# -- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0} $trModule2_r3XM :: GHC.Types.TrName [GblId, Caf=NoCafRefs] $trModule2_r3XM = GHC.Types.TrNameS $trModule1_r3XB -- RHS size: {terms: 1, types: 0, coercions: 0, joins: 0/0} $trModule3_r3XN :: GHC.Prim.Addr# [GblId, Caf=NoCafRefs] $trModule3_r3XN = "Ghci2"# -- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0} $trModule4_r3XO :: GHC.Types.TrName [GblId, Caf=NoCafRefs] $trModule4_r3XO = GHC.Types.TrNameS $trModule3_r3XN -- RHS size: {terms: 3, types: 0, coercions: 0, joins: 0/0} interactive:Ghci2.$trModule :: GHC.Types.Module [GblId, Caf=NoCafRefs] interactive:Ghci2.$trModule = GHC.Types.Module $trModule2_r3XM $trModule4_r3XO ==================== Proto-BCOs ==================== ProtoBCO sat_s3XU#0 []: let sat_s3XT = ... in ... bitmap: 0 [] ALLOC_AP 0 PUSH_BCO ProtoBCO sat_s3XT#0 []: let sat_s3XS = ... in ... bitmap: 0 [] PUSH_UBX (1) 8# PACK GHC.Integer.Type.S# 1 PUSH_UBX (1) 10# PACK GHC.Integer.Type.S# 1 PUSH_LL 1 0 PUSH_G GHC.Real.$fIntegralInteger PUSH_G GHC.Num.$fNumInteger PUSH_APPLY_PPPP PUSH_G GHC.Real.^ SLIDE 6 2 ENTER MKAP 0 words, 1 stkoff PUSH_UBX (1) 1# PACK GHC.Integer.Type.S# 1 PUSH_LL 1 0 PUSH_G GHC.Enum.$fEnumInteger PUSH_APPLY_PPP PUSH_G GHC.Enum.enumFromTo SLIDE 5 2 ENTER ProtoBCO Ghci2.l#0 []: Data.Foldable.length @ [] Data.Foldable.$fFoldable[] @ GHC.Integer.Type.Integer sat_s3XU bitmap: 0 [] PUSH_G sat_s3XU PUSH_G Data.Foldable.$fFoldable[] PUSH_APPLY_PP PUSH_G Data.Foldable.length ENTER ProtoBCO $trModule2_r3XM#0 []: GHC.Types.TrNameS $trModule1_r3XB bitmap: 0 [] PUSH_UBX (1) 26770624## PACK GHC.Types.TrNameS 1 ENTER ProtoBCO $trModule4_r3XO#0 []: GHC.Types.TrNameS $trModule3_r3XN bitmap: 0 [] PUSH_UBX (1) 26770592## PACK GHC.Types.TrNameS 1 ENTER ProtoBCO Ghci2.$trModule#0 []: GHC.Types.Module $trModule2_r3XM $trModule4_r3XO bitmap: 0 [] PUSH_G $trModule4_r3XO PUSH_G $trModule2_r3XM PACK GHC.Types.Module 2 ENTER }}} It looks to me like the BCO pass is somehow floating out the `enumFromTo` application, which then gets retained. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 30 18:27:24 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 May 2018 18:27:24 -0000 Subject: [GHC] #15162: armv7l-unknown-linux-gnueabihf is missing from llvm-targets In-Reply-To: <046.38959772a24aab5f60714cbb324b4d29@haskell.org> References: <046.38959772a24aab5f60714cbb324b4d29@haskell.org> Message-ID: <061.e7412371664574d65164302a31a178a1@haskell.org> #15162: armv7l-unknown-linux-gnueabihf is missing from llvm-targets ---------------------------------+------------------------------ Reporter: ggardet | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+------------------------------ Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: Merged with e4003b6dc6a84d870116de9f47057c15b1576f36. Thanks ggardet! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 30 20:30:56 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 May 2018 20:30:56 -0000 Subject: [GHC] #14975: Refactor (Maybe Coercion) In-Reply-To: <047.51816057ba89e62ff311692e8071c67c@haskell.org> References: <047.51816057ba89e62ff311692e8071c67c@haskell.org> Message-ID: <062.588764a43ed89064f70378e38a9e00ef@haskell.org> #14975: Refactor (Maybe Coercion) -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11735 | Differential Rev(s): Phab:D4699 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"9aac442f70b0b58decd56fb52dd4ec2289b03759/ghc" 9aac442/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9aac442f70b0b58decd56fb52dd4ec2289b03759" Define MCoercion type An attempt on #14975: During compilation, reflexive casts is discarded for computation. Currently in some places we use Maybe coercion as inputs. So if a cast is reflexive it is denoted as Nothing, otherwise Just coercion. This patch defines the type data MCoercion = MRefl | MCo Coercion which is isomorphic to Maybe Coercion but useful in a number of places, and super-helpful documentation. Test Plan: validate Reviewers: bgamari, goldfire, simonpj Reviewed By: goldfire Subscribers: mpickering, rwbarton, thomie, carter GHC Trac Issues: #14975 Differential Revision: https://phabricator.haskell.org/D4699 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 30 20:30:56 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 May 2018 20:30:56 -0000 Subject: [GHC] #15163: non coercion variable in coVarKindsTypesRole In-Reply-To: <048.b3dbe8c60de34c10b2c3141afc368cad@haskell.org> References: <048.b3dbe8c60de34c10b2c3141afc368cad@haskell.org> Message-ID: <063.de06d73d3cf53e806fee6268a9700c7b@haskell.org> #15163: non coercion variable in coVarKindsTypesRole -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.4.4 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T14732 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4725 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"c65159dcf401d36e8920f43fec300264533642b9/ghc" c65159dc/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c65159dcf401d36e8920f43fec300264533642b9" T14732 now passes with the profasm way Simon PJ recently fixed the problem behind this failure so we can now expect this test to pass in all ways again. The fixes got introduced in the following commits: 86bba7d519fb6050f78b7e3bac2b3f54273fd70e d191db48c43469ee1818887715bcbc5c0eb1d91f Test Plan: T14732 (profasm way) Reviewers: bgamari, RyanGlScott, simonpj Reviewed By: RyanGlScott, simonpj Subscribers: simonpj, RyanGlScott, rwbarton, thomie, carter GHC Trac Issues: #15163 Differential Revision: https://phabricator.haskell.org/D4725 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 30 20:30:56 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 May 2018 20:30:56 -0000 Subject: [GHC] #15060: outofmem testcase sometimes crashes on i386 In-Reply-To: <046.7122be6c9e363e21e924ee402fc4eb2a@haskell.org> References: <046.7122be6c9e363e21e924ee402fc4eb2a@haskell.org> Message-ID: <061.9e15855656076f268259acd59593c3af@haskell.org> #15060: outofmem testcase sometimes crashes on i386 -------------------------------------+----------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.3 Component: Runtime System | Version: 8.2.2 Resolution: | Keywords: ci-breakage Operating System: Unknown/Multiple | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4704 Wiki Page: | -------------------------------------+----------------------------------- Comment (by Ben Gamari ): In [changeset:"34464fed463c7be07d4664e2f4b96eaf1acfc37b/ghc" 34464fed/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="34464fed463c7be07d4664e2f4b96eaf1acfc37b" rts: Don't madvise if mmap failed On 32-bit Linux `outofmem` did not fail with the expected out-of-memory error message, instead failing with, outofmem: internal error: getMBlock: mmap: Invalid argument This happened because, `my_mmap` would attempt to `madvise` even if the `mmap` call failed. So while `mmap` returns `ENOMEM` we nevertheless try to `madvise`, which clobbers `errno`, giving us the unexpected `EINVAL` error. Consequently we don't detect this to be an out-of-memory error. This should fix #15060. Test Plan: `make test TEST=outofmem` on i386 Reviewers: simonmar, erikd Reviewed By: simonmar Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15060 Differential Revision: https://phabricator.haskell.org/D4704 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 30 20:30:56 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 May 2018 20:30:56 -0000 Subject: [GHC] #13838: -Wdeferred-type-errors on a program with main not of type IO () yields "main thread exited (uncaught exception)" In-Reply-To: <044.5150fbc131040d8653d1692d9b8b36a2@haskell.org> References: <044.5150fbc131040d8653d1692d9b8b36a2@haskell.org> Message-ID: <059.e7acf14b45f362edb84359f4969d8633@haskell.org> #13838: -Wdeferred-type-errors on a program with main not of type IO () yields "main thread exited (uncaught exception)" -------------------------------------+------------------------------------- Reporter: harry | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13292 | Differential Rev(s): Phab:D4708 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"49e423e9940a9122a4a417cfc7580b9984fb49eb/ghc" 49e423e9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="49e423e9940a9122a4a417cfc7580b9984fb49eb" Put the `ev_binds` of main function inside `runMainIO` This ensures that the deferred type error can be emitted correctly. For `main` function in `Main` module, we have :Main.main = GHC.TopHandler.runMainIO main When the type of `main` is not `IO t` and the `-fdefer-type-errors` is enabled, the `ev_binds` of `main` function will contain deferred type errors. Previously, the `ev_binds` are bound to `runMainIO main`, rather than `main`, the type error exception at runtime cannot be handled properly. See Trac #13838. This patch fix that. Test Plan: make test TEST="T13838" Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #13838 Differential Revision: https://phabricator.haskell.org/D4708 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 30 20:30:56 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 May 2018 20:30:56 -0000 Subject: [GHC] #11295: Figure out what LLVM passes are fruitful In-Reply-To: <046.97e900ad29a1522a4b7374676cc6de7a@haskell.org> References: <046.97e900ad29a1522a4b7374676cc6de7a@haskell.org> Message-ID: <061.f4dfc64164fd52be63cb3ddc33d8b98d@haskell.org> #11295: Figure out what LLVM passes are fruitful -------------------------------------+------------------------------------- Reporter: bgamari | Owner: kavon Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (LLVM) | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 14528 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"a4ae199cf810a63444a4ef24a44b33329023cd93/ghc" a4ae199/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a4ae199cf810a63444a4ef24a44b33329023cd93" Extract hard-coded LLVM opt flags into a file To resolve ticket #11295, I think it makes sense to stop hard-coding the pass sequences used by GHC when compiling with LLVM into the compiler itself. This patchset introduces a companion to the existing `llvm-targets` file called `llvm-passes`. The passes file is a simple association list that holds the default LLVM `opt` pass sequence used by GHC. This allows end users to easily save their favorite optimization flags when compiling with LLVM. The main benefit for ticket #11295 is that when adding a custom pass sequence, it tends to be an extremely long string that would be unsightly in the code. This is essentially part 1 of 2 for ticket #11295. Test Plan: ./validate Reviewers: bgamari, angerman Reviewed By: angerman Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4695 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 30 20:30:56 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 May 2018 20:30:56 -0000 Subject: [GHC] #10946: Typed hole inside typed Template Haskell bracket causes panic In-Reply-To: <048.bb931422119631f05ab09abe14bd4c46@haskell.org> References: <048.bb931422119631f05ab09abe14bd4c46@haskell.org> Message-ID: <063.16b72dddfe8f277b71cce694e3676d63@haskell.org> #10946: Typed hole inside typed Template Haskell bracket causes panic -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: th/T10946 Blocked By: | Blocking: Related Tickets: #14969 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"e0b44e2eccd4053852b6c4c3de75a714301ec080/ghc" e0b44e2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e0b44e2eccd4053852b6c4c3de75a714301ec080" Improved Valid Hole Fits I've changed the name from `Valid substitutions` to `Valid hole fits`, since "substitution" already has a well defined meaning within the theory. As part of this change, the flags and output is reanamed, with substitution turning into hole-fit in most cases. "hole fit" was already used internally in the code, it's clear and shouldn't cause any confusion. In this update, I've also reworked how we manage side-effects in the hole we are considering. This allows us to consider local bindings such as where clauses and arguments to functions, suggesting e.g. `a` for `head (x:xs) where head :: [a] -> a`. It also allows us to find suggestions such as `maximum` for holes of type `Ord a => a -> [a]`, and `max` when looking for a match for the hole in `g = foldl1 _`, where `g :: Ord a => [a] -> a`. We also show much improved output for refinement hole fits, and fixes #14990. We now show the correct type of the function, but we also now show what the arguments to the function should be e.g. `foldl1 (_ :: Integer -> Integer -> Integer)` when looking for `[Integer] -> Integer`. I've moved the bulk of the code from `TcErrors.hs` to a new file, `TcHoleErrors.hs`, since it was getting too big to not live on it's own. This addresses the considerations raised in #14969, and takes proper care to set the `tcLevel` of the variables to the right level before passing it to the simplifier. We now also zonk the suggestions properly, which improves the output of the refinement hole fits considerably. This also filters out suggestions from the `GHC.Err` module, since even though `error` and `undefined` are indeed valid hole fits, they are "trivial", and almost never useful to the user. We now find the hole fits using the proper manner, namely by solving nested implications. This entails that the givens are passed along using the implications the hole was nested in, which in turn should mean that there will be fewer weird bugs in the typed holes. I've also added a new sorting method (as suggested by SPJ) and sort by the size of the types needed to turn the hole fits into the type of the hole. This gives a reasonable approximation to relevance, and is much faster than the subsumption check. I've also added a flag to toggle whether to use this new sorting algorithm (as is done by default) or the subsumption algorithm. This fixes #14969 I've also added documentation for these new flags and update the documentation according to the new output. Reviewers: bgamari, goldfire Reviewed By: bgamari Subscribers: simonpj, rwbarton, thomie, carter GHC Trac Issues: #14969, #14990, #10946 Differential Revision: https://phabricator.haskell.org/D4444 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 30 20:30:56 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 May 2018 20:30:56 -0000 Subject: [GHC] #15073: Unable to newtype derive `Prim` via DerivingStrategies In-Reply-To: <047.b85af09eb39d6271dfdb97c1ad8ee86f@haskell.org> References: <047.b85af09eb39d6271dfdb97c1ad8ee86f@haskell.org> Message-ID: <062.84a89ed4e99fba2abc605cc36ead5a05@haskell.org> #15073: Unable to newtype derive `Prim` via DerivingStrategies -------------------------------------+------------------------------------- Reporter: fosskers | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4620, Wiki Page: | Phab:D4701 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"b876c1bb5c8ccd73a203c0f94bac3cbb9c7e2d65/ghc" b876c1bb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b876c1bb5c8ccd73a203c0f94bac3cbb9c7e2d65" users-guide: Point out GNTD may require additional extensions As noted in #15073, GeneralizedNewtypeDeriving may produce code that uses extensions that do not directly appear in the code written by the user. Make this clear in the users guide. [skip ci] Test Plan: Read it Reviewers: RyanGlScott Reviewed By: RyanGlScott Subscribers: fosskers, rwbarton, thomie, carter GHC Trac Issues: #15073 Differential Revision: https://phabricator.haskell.org/D4701 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 30 20:30:56 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 May 2018 20:30:56 -0000 Subject: [GHC] #14969: Underconstrained typed holes are non-performant In-Reply-To: <046.e2ddb687ff62b149f21f1d7eab94d28c@haskell.org> References: <046.e2ddb687ff62b149f21f1d7eab94d28c@haskell.org> Message-ID: <061.18746bf3dc0e473c82095f3f39da6530@haskell.org> #14969: Underconstrained typed holes are non-performant -------------------------------------+------------------------------------- Reporter: johnleo | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | ghci/scripts/T14969 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4444 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"e0b44e2eccd4053852b6c4c3de75a714301ec080/ghc" e0b44e2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e0b44e2eccd4053852b6c4c3de75a714301ec080" Improved Valid Hole Fits I've changed the name from `Valid substitutions` to `Valid hole fits`, since "substitution" already has a well defined meaning within the theory. As part of this change, the flags and output is reanamed, with substitution turning into hole-fit in most cases. "hole fit" was already used internally in the code, it's clear and shouldn't cause any confusion. In this update, I've also reworked how we manage side-effects in the hole we are considering. This allows us to consider local bindings such as where clauses and arguments to functions, suggesting e.g. `a` for `head (x:xs) where head :: [a] -> a`. It also allows us to find suggestions such as `maximum` for holes of type `Ord a => a -> [a]`, and `max` when looking for a match for the hole in `g = foldl1 _`, where `g :: Ord a => [a] -> a`. We also show much improved output for refinement hole fits, and fixes #14990. We now show the correct type of the function, but we also now show what the arguments to the function should be e.g. `foldl1 (_ :: Integer -> Integer -> Integer)` when looking for `[Integer] -> Integer`. I've moved the bulk of the code from `TcErrors.hs` to a new file, `TcHoleErrors.hs`, since it was getting too big to not live on it's own. This addresses the considerations raised in #14969, and takes proper care to set the `tcLevel` of the variables to the right level before passing it to the simplifier. We now also zonk the suggestions properly, which improves the output of the refinement hole fits considerably. This also filters out suggestions from the `GHC.Err` module, since even though `error` and `undefined` are indeed valid hole fits, they are "trivial", and almost never useful to the user. We now find the hole fits using the proper manner, namely by solving nested implications. This entails that the givens are passed along using the implications the hole was nested in, which in turn should mean that there will be fewer weird bugs in the typed holes. I've also added a new sorting method (as suggested by SPJ) and sort by the size of the types needed to turn the hole fits into the type of the hole. This gives a reasonable approximation to relevance, and is much faster than the subsumption check. I've also added a flag to toggle whether to use this new sorting algorithm (as is done by default) or the subsumption algorithm. This fixes #14969 I've also added documentation for these new flags and update the documentation according to the new output. Reviewers: bgamari, goldfire Reviewed By: bgamari Subscribers: simonpj, rwbarton, thomie, carter GHC Trac Issues: #14969, #14990, #10946 Differential Revision: https://phabricator.haskell.org/D4444 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 30 20:30:56 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 May 2018 20:30:56 -0000 Subject: [GHC] #14990: "Valid refinement suggestions" have the wrong types In-Reply-To: <047.1377e2f34a2eeac1354152d47898fe0b@haskell.org> References: <047.1377e2f34a2eeac1354152d47898fe0b@haskell.org> Message-ID: <062.12a2d81beba6bbeabec221cc72387c1d@haskell.org> #14990: "Valid refinement suggestions" have the wrong types -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Tritlo Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4444 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"e0b44e2eccd4053852b6c4c3de75a714301ec080/ghc" e0b44e2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e0b44e2eccd4053852b6c4c3de75a714301ec080" Improved Valid Hole Fits I've changed the name from `Valid substitutions` to `Valid hole fits`, since "substitution" already has a well defined meaning within the theory. As part of this change, the flags and output is reanamed, with substitution turning into hole-fit in most cases. "hole fit" was already used internally in the code, it's clear and shouldn't cause any confusion. In this update, I've also reworked how we manage side-effects in the hole we are considering. This allows us to consider local bindings such as where clauses and arguments to functions, suggesting e.g. `a` for `head (x:xs) where head :: [a] -> a`. It also allows us to find suggestions such as `maximum` for holes of type `Ord a => a -> [a]`, and `max` when looking for a match for the hole in `g = foldl1 _`, where `g :: Ord a => [a] -> a`. We also show much improved output for refinement hole fits, and fixes #14990. We now show the correct type of the function, but we also now show what the arguments to the function should be e.g. `foldl1 (_ :: Integer -> Integer -> Integer)` when looking for `[Integer] -> Integer`. I've moved the bulk of the code from `TcErrors.hs` to a new file, `TcHoleErrors.hs`, since it was getting too big to not live on it's own. This addresses the considerations raised in #14969, and takes proper care to set the `tcLevel` of the variables to the right level before passing it to the simplifier. We now also zonk the suggestions properly, which improves the output of the refinement hole fits considerably. This also filters out suggestions from the `GHC.Err` module, since even though `error` and `undefined` are indeed valid hole fits, they are "trivial", and almost never useful to the user. We now find the hole fits using the proper manner, namely by solving nested implications. This entails that the givens are passed along using the implications the hole was nested in, which in turn should mean that there will be fewer weird bugs in the typed holes. I've also added a new sorting method (as suggested by SPJ) and sort by the size of the types needed to turn the hole fits into the type of the hole. This gives a reasonable approximation to relevance, and is much faster than the subsumption check. I've also added a flag to toggle whether to use this new sorting algorithm (as is done by default) or the subsumption algorithm. This fixes #14969 I've also added documentation for these new flags and update the documentation according to the new output. Reviewers: bgamari, goldfire Reviewed By: bgamari Subscribers: simonpj, rwbarton, thomie, carter GHC Trac Issues: #14969, #14990, #10946 Differential Revision: https://phabricator.haskell.org/D4444 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 30 20:33:26 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 May 2018 20:33:26 -0000 Subject: [GHC] #15060: outofmem testcase sometimes crashes on i386 In-Reply-To: <046.7122be6c9e363e21e924ee402fc4eb2a@haskell.org> References: <046.7122be6c9e363e21e924ee402fc4eb2a@haskell.org> Message-ID: <061.7f1a2a60417c6c5d5c0258a2dbd5526c@haskell.org> #15060: outofmem testcase sometimes crashes on i386 -------------------------------------+----------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.2.2 Resolution: fixed | Keywords: ci-breakage Operating System: Unknown/Multiple | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4704 Wiki Page: | -------------------------------------+----------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: 8.4.3 => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 30 20:33:55 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 May 2018 20:33:55 -0000 Subject: [GHC] #14975: Refactor (Maybe Coercion) In-Reply-To: <047.51816057ba89e62ff311692e8071c67c@haskell.org> References: <047.51816057ba89e62ff311692e8071c67c@haskell.org> Message-ID: <062.6a80dac0334dae932e9edd2b4cad6b0a@haskell.org> #14975: Refactor (Maybe Coercion) -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11735 | Differential Rev(s): Phab:D4699 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 30 20:35:15 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 May 2018 20:35:15 -0000 Subject: [GHC] #15073: Unable to newtype derive `Prim` via DerivingStrategies In-Reply-To: <047.b85af09eb39d6271dfdb97c1ad8ee86f@haskell.org> References: <047.b85af09eb39d6271dfdb97c1ad8ee86f@haskell.org> Message-ID: <062.1f66880706ee60138a14c41fd996f6ea@haskell.org> #15073: Unable to newtype derive `Prim` via DerivingStrategies -------------------------------------+------------------------------------- Reporter: fosskers | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: deriving Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4620, Wiki Page: | Phab:D4701 -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 30 20:35:57 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 May 2018 20:35:57 -0000 Subject: [GHC] #14969: Underconstrained typed holes are non-performant In-Reply-To: <046.e2ddb687ff62b149f21f1d7eab94d28c@haskell.org> References: <046.e2ddb687ff62b149f21f1d7eab94d28c@haskell.org> Message-ID: <061.6198a1d58938bdf35e74fa5890b32599@haskell.org> #14969: Underconstrained typed holes are non-performant -------------------------------------+------------------------------------- Reporter: johnleo | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: fixed | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | ghci/scripts/T14969 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4444 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 30 20:37:40 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 May 2018 20:37:40 -0000 Subject: [GHC] #14990: "Valid refinement suggestions" have the wrong types In-Reply-To: <047.1377e2f34a2eeac1354152d47898fe0b@haskell.org> References: <047.1377e2f34a2eeac1354152d47898fe0b@haskell.org> Message-ID: <062.835690194d803e1c979ab846952a5b05@haskell.org> #14990: "Valid refinement suggestions" have the wrong types -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Tritlo Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4444 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.6.1 Comment: I believe this should now be fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 30 20:39:48 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 May 2018 20:39:48 -0000 Subject: [GHC] #10946: Typed hole inside typed Template Haskell bracket causes panic In-Reply-To: <048.bb931422119631f05ab09abe14bd4c46@haskell.org> References: <048.bb931422119631f05ab09abe14bd4c46@haskell.org> Message-ID: <063.9ee059764580dc1a6dbafe7460518a53@haskell.org> #10946: Typed hole inside typed Template Haskell bracket causes panic -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: th/T10946 Blocked By: | Blocking: Related Tickets: #14969 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.4.1 => 8.6.1 Comment: Tritlo, is this now fixed? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 30 20:48:06 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 May 2018 20:48:06 -0000 Subject: [GHC] #10946: Typed hole inside typed Template Haskell bracket causes panic In-Reply-To: <048.bb931422119631f05ab09abe14bd4c46@haskell.org> References: <048.bb931422119631f05ab09abe14bd4c46@haskell.org> Message-ID: <063.a453d98fd09b5147771460ca0b565e8a@haskell.org> #10946: Typed hole inside typed Template Haskell bracket causes panic -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: th/T10946 Blocked By: | Blocking: Related Tickets: #14969 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Tritlo): No, the initial error still occurs, but the hang introduced by the valid hole fits should no longer be a problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 30 21:14:29 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 May 2018 21:14:29 -0000 Subject: [GHC] #13838: -Wdeferred-type-errors on a program with main not of type IO () yields "main thread exited (uncaught exception)" In-Reply-To: <044.5150fbc131040d8653d1692d9b8b36a2@haskell.org> References: <044.5150fbc131040d8653d1692d9b8b36a2@haskell.org> Message-ID: <059.5fb60d79f85cceb355e9ece9a686415f@haskell.org> #13838: -Wdeferred-type-errors on a program with main not of type IO () yields "main thread exited (uncaught exception)" -------------------------------------+------------------------------------- Reporter: harry | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: T13838 Blocked By: | Blocking: Related Tickets: #13292 | Differential Rev(s): Phab:D4708 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * testcase: => T13838 * status: patch => closed * resolution: => fixed * milestone: => 8.6.1 Comment: I believe this should now be fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 30 21:26:59 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 May 2018 21:26:59 -0000 Subject: [GHC] #15198: `Language.Haskell.TH.Syntax.reify` returns * rather than Constraint Message-ID: <045.33db5deaa1796fcc21563427883ef147@haskell.org> #15198: `Language.Haskell.TH.Syntax.reify` returns * rather than Constraint -------------------------------------+------------------------------------- Reporter: benzrf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.4 Component: Template | Version: 8.4.2 Haskell | Keywords: reify | Operating System: Linux constraint constraintkinds | Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This module is sufficient to demonstrate the mistake: {{{#!hs {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TemplateHaskell #-} module Bug where import Data.Kind import Data.Proxy import Language.Haskell.TH foo :: forall (k :: Constraint). Proxy k foo = Proxy return [] -- delimit declaration groups main :: IO () main = putStrLn $(do VarI _ ty _ <- reify 'foo let p = pprint ty [| p |]) }}} Running this in GHC 8.0.2 correctly prints out `forall (k_0 :: Constraint) . Data.Proxy.Proxy k_0`, but GHC 8.2.2 and 8.4.2 both print `forall (k_0 :: *) . Data.Proxy.Proxy k_0`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 30 21:27:08 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 May 2018 21:27:08 -0000 Subject: [GHC] #15186: ghc 8.4.2 panic in profiling build In-Reply-To: <045.764163a11088d02a8878689da6d8a04b@haskell.org> References: <045.764163a11088d02a8878689da6d8a04b@haskell.org> Message-ID: <060.7031a9417e1971e6399d02a1188927c1@haskell.org> #15186: ghc 8.4.2 panic in profiling build -------------------------------------+------------------------------------- Reporter: kquick | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.4.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): The problem appears to be caused by the matcher for `PointerExpr`, which is levity polymorphic: {{{#!hs Bar.$mPointerExpr :: forall (r :: TYPE rep) (tp :: CrucibleType). Expr tp -> (GHC.Prim.Void# -> r) -> (GHC.Prim.Void# -> r) -> r }}} This particular form of levity polymorphism should be perfectly fine. However, it seems that the worker-wrapper pass somehow stumbles on to this: {{{ ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.4.1 for x86_64-unknown-linux): isUnliftedType r_a32N :: TYPE rep_a32M Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1951:10 in ghc:Type CallStack (from -prof): WorkWrap.splitFun (compiler/stranal/WorkWrap.hs:(470,1)-(566,42)) WorkWrap.tryWW (compiler/stranal/WorkWrap.hs:(397,1)-(424,65)) WorkWrap.wwBind (compiler/stranal/WorkWrap.hs:(86,1)-(97,76)) WorkWrap.wwTopBinds (compiler/stranal/WorkWrap.hs:(63,1)-(66,30)) SimplCore.WorkWrap (compiler/simplCore/SimplCore.hs:491:40-59) HscMain.Core2Core (compiler/main/HscMain.hs:1212:7-55) HscMain.hscSimplify' (compiler/main/HscMain.hs:(1206,1)-(1212,55)) HscMain.finish (compiler/main/HscMain.hs:(728,1)-(768,70)) HscMain.hscIncrementalCompile (compiler/main/HscMain.hs:(671,1)-(717,52)) GhcMake.upsweep_mod.compile_it (compiler/main/GhcMake.hs:(1457,13)-(1459,66)) GhcMake.upsweep_mod (compiler/main/GhcMake.hs:(1403,1)-(1559,49)) GhcMake.upsweep.upsweep' (compiler/main/GhcMake.hs:(1272,3)-(1371,91)) GhcMake.upsweep (compiler/main/GhcMake.hs:(1254,1)-(1371,91)) GhcMake.load'.upsweep_fn (compiler/main/GhcMake.hs:(393,9)-(394,41)) GhcMake.load'.checkHowMuch (compiler/main/GhcMake.hs:(270,9)-(272,27)) GhcMake.load' (compiler/main/GhcMake.hs:(246,1)-(494,38)) GhcMake.load (compiler/main/GhcMake.hs:(238,1)-(240,44)) GHC.withCleanupSession (compiler/main/GHC.hs:(466,1)-(475,37)) GHC.runGhc (compiler/main/GHC.hs:(441,1)-(446,26)) GHC.defaultErrorHandler (compiler/main/GHC.hs:(381,1)-(413,7)) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 30 22:00:20 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 May 2018 22:00:20 -0000 Subject: [GHC] #15186: ghc 8.4.2 panic in profiling build In-Reply-To: <045.764163a11088d02a8878689da6d8a04b@haskell.org> References: <045.764163a11088d02a8878689da6d8a04b@haskell.org> Message-ID: <060.3fefb5a5e2e4abb84536c63ac5bc541d@haskell.org> #15186: ghc 8.4.2 panic in profiling build -------------------------------------+------------------------------------- Reporter: kquick | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.4.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: T15186 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * testcase: => T15186 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 30 22:01:00 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 May 2018 22:01:00 -0000 Subject: [GHC] #15186: ghc 8.4.2 panic in profiling build In-Reply-To: <045.764163a11088d02a8878689da6d8a04b@haskell.org> References: <045.764163a11088d02a8878689da6d8a04b@haskell.org> Message-ID: <060.1e662031b44cbdf74f31961fef7926d3@haskell.org> #15186: ghc 8.4.2 panic in profiling build -------------------------------------+------------------------------------- Reporter: kquick | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Profiling | Version: 8.4.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: T15186 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4756, Wiki Page: | Phab:D4757 -------------------------------------+------------------------------------- Changes (by bgamari): * owner: (none) => bgamari * differential: => Phab:D4756, Phab:D4757 * milestone: => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 30 22:02:51 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 May 2018 22:02:51 -0000 Subject: [GHC] #15186: ghc 8.4.2 panic in profiling build In-Reply-To: <045.764163a11088d02a8878689da6d8a04b@haskell.org> References: <045.764163a11088d02a8878689da6d8a04b@haskell.org> Message-ID: <060.e3dc0f9646964b4d9575cde87ba53aa5@haskell.org> #15186: ghc 8.4.2 panic in profiling build -------------------------------------+------------------------------------- Reporter: kquick | Owner: bgamari Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Profiling | Version: 8.4.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: T15186 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4756, Wiki Page: | Phab:D4757 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 30 22:07:08 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 May 2018 22:07:08 -0000 Subject: [GHC] #7414: plugins always trigger recompilation In-Reply-To: <045.791037be90cd943b6dd26df93dd060d8@haskell.org> References: <045.791037be90cd943b6dd26df93dd060d8@haskell.org> Message-ID: <060.6cfadaf02b2e3c067cf74d00d9ea341b@haskell.org> #7414: plugins always trigger recompilation -------------------------------------+------------------------------------- Reporter: jwlato | Owner: (none) Type: feature request | Status: patch Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: plugin, | RecompilationCheck Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12567 | Differential Rev(s): Phab:D4366 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"1d1e2b77fdc2babdf4fff72b9120c6831e7b422f/ghc" 1d1e2b7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1d1e2b77fdc2babdf4fff72b9120c6831e7b422f" Implement "An API for deciding whether plugins should cause recompilation" This patch implements the API proposed as pull request #108 for plugin authors to influence the recompilation checker. It adds a new field to a plugin which computes a `FingerPrint`. This is recorded in interface files and if it changes then we recompile the module. There are also helper functions such as `purePlugin` and `impurePlugin` for constructing plugins which have simple recompilation semantics but in general, an author can compute a hash as they wish. Fixes #12567 and #7414 https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/002 2-plugin-recompilation.rst Reviewers: bgamari, ggreif Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #7414, #12567 Differential Revision: https://phabricator.haskell.org/D4366 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 30 22:07:08 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 May 2018 22:07:08 -0000 Subject: [GHC] #108: Header files from f.i. not propagated to non-local inlining In-Reply-To: <042.6daf469a5652c0b02239766fa797a496@haskell.org> References: <042.6daf469a5652c0b02239766fa797a496@haskell.org> Message-ID: <057.0163242b2f27f74830029b42ff1f455f@haskell.org> #108: Header files from f.i. not propagated to non-local inlining --------------------------------+-------------------- Reporter: nhn | Owner: nobody Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 5.04.2 Resolution: Fixed | Keywords: Type of failure: None/Unknown | --------------------------------+-------------------- Changes (by Ben Gamari ): * failure: => None/Unknown Comment: In [changeset:"1d1e2b77fdc2babdf4fff72b9120c6831e7b422f/ghc" 1d1e2b7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1d1e2b77fdc2babdf4fff72b9120c6831e7b422f" Implement "An API for deciding whether plugins should cause recompilation" This patch implements the API proposed as pull request #108 for plugin authors to influence the recompilation checker. It adds a new field to a plugin which computes a `FingerPrint`. This is recorded in interface files and if it changes then we recompile the module. There are also helper functions such as `purePlugin` and `impurePlugin` for constructing plugins which have simple recompilation semantics but in general, an author can compute a hash as they wish. Fixes #12567 and #7414 https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/002 2-plugin-recompilation.rst Reviewers: bgamari, ggreif Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #7414, #12567 Differential Revision: https://phabricator.haskell.org/D4366 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 30 22:07:08 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 May 2018 22:07:08 -0000 Subject: [GHC] #12567: `ghc --make` recompiles unchanged files when using `-fplugin` OPTIONS In-Reply-To: <048.43f14cd5930ab5b814c814d30cfc4c67@haskell.org> References: <048.43f14cd5930ab5b814c814d30cfc4c67@haskell.org> Message-ID: <063.514145a17cc35e305c913e43ed5a5efe@haskell.org> #12567: `ghc --make` recompiles unchanged files when using `-fplugin` OPTIONS -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: plugin, | RecompilationCheck Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #7414 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"1d1e2b77fdc2babdf4fff72b9120c6831e7b422f/ghc" 1d1e2b7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1d1e2b77fdc2babdf4fff72b9120c6831e7b422f" Implement "An API for deciding whether plugins should cause recompilation" This patch implements the API proposed as pull request #108 for plugin authors to influence the recompilation checker. It adds a new field to a plugin which computes a `FingerPrint`. This is recorded in interface files and if it changes then we recompile the module. There are also helper functions such as `purePlugin` and `impurePlugin` for constructing plugins which have simple recompilation semantics but in general, an author can compute a hash as they wish. Fixes #12567 and #7414 https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/002 2-plugin-recompilation.rst Reviewers: bgamari, ggreif Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #7414, #12567 Differential Revision: https://phabricator.haskell.org/D4366 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 30 22:07:08 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 May 2018 22:07:08 -0000 Subject: [GHC] #15197: Apparent missing dependency in ghc-heap In-Reply-To: <046.f9380793ce8ad25be083749857e75f4a@haskell.org> References: <046.f9380793ce8ad25be083749857e75f4a@haskell.org> Message-ID: <061.146bdb7be4f6fae28530de92863eaa28@haskell.org> #15197: Apparent missing dependency in ghc-heap -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4753 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"64fd0fac838426fb87322712da34dabd211c3d89/ghc" 64fd0fac/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="64fd0fac838426fb87322712da34dabd211c3d89" ghc-heap: Add dependency from GHC.Exts.Heap.Closures to InfoTableProf `ghc -M` currently doesn't properly account for ways when generating dependencies (#15197). This import ensures correct build-ordering between this module and GHC.Exts.Heap.InfoTableProf. Otherwise the profiled build may fail as described in #15197. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 30 22:28:31 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 May 2018 22:28:31 -0000 Subject: [GHC] #15199: Build fails on Debian armhf (armv7l-unknown-linux-gnueabihf) Message-ID: <044.81af1940b7343631708d21b21be1c899@haskell.org> #15199: Build fails on Debian armhf (armv7l-unknown-linux-gnueabihf) -------------------------------------+------------------------------------- Reporter: clint | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.4 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- {{{ "inplace/bin/ghc-stage1" -static -H32m -O -lffi -optl-pthread -optl-B/usr/bin/ld.gold -D__ARM_PCS_VFP -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist- ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical-monad-instances -c rts/StgStartup.cmm -o rts/dist/build/StgStartup.o ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.4.2 for arm-unknown-linux): Failed to lookup the datalayout for armv7l-unknown-linux- gnueabihf; available targets: ["i386-unknown-windows","i686-unknown- windows","x86_64-unknown-windows","arm-unknown-linux-gnueabihf","armv6 -unknown-linux-gnueabihf","armv7-unknown-linux-gnueabihf","aarch64 -unknown-linux-gnu","aarch64-unknown-linux","armv7a-unknown-linux- gnueabi","i386-unknown-linux-gnu","i386-unknown-linux","x86_64-unknown- linux-gnu","x86_64-unknown-linux","armv7-unknown-linux- androideabi","aarch64-unknown-linux-android","arm-unknown-nto-qnx- eabi","i386-apple-darwin","x86_64-apple-darwin","armv7-apple-ios","aarch64 -apple-ios","i386-apple-ios","x86_64-apple-ios"] CallStack (from HasCallStack): error, called at compiler/llvmGen/LlvmCodeGen.hs:96:24 in ghc:LlvmCodeGen Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug rts/ghc.mk:295: recipe for target 'rts/dist/build/StgStartup.o' failed }}} https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=armhf&ver=8.4.2-1&stamp=1525310160&raw=0 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 30 22:29:24 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 May 2018 22:29:24 -0000 Subject: [GHC] #15199: Build fails on Debian armhf (armv7l-unknown-linux-gnueabihf) In-Reply-To: <044.81af1940b7343631708d21b21be1c899@haskell.org> References: <044.81af1940b7343631708d21b21be1c899@haskell.org> Message-ID: <059.b3bb376bd3a294291d9c4bf674b3fed4@haskell.org> #15199: Build fails on Debian armhf (armv7l-unknown-linux-gnueabihf) -------------------------------------+------------------------------------- Reporter: clint | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.4 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by clint): fixed in e4003b6dc6a84d870116de9f47057c15b1576f36 ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 30 22:41:37 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 May 2018 22:41:37 -0000 Subject: [GHC] #15200: RFC: export WordPtr from Data.Word and IntPtr from Data.Int rather than only from Foreign.Ptr Message-ID: <045.4b1c2629d5a6a22d28611cace837aebd@haskell.org> #15200: RFC: export WordPtr from Data.Word and IntPtr from Data.Int rather than only from Foreign.Ptr -------------------------------------+------------------------------------- Reporter: carter | 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: -------------------------------------+------------------------------------- Currently we have two types (WordPtr and IntPtr) that should live / be exposed from Data.Word and Data.Int respectively that currently are not reasons for the inclusion 1) It seems odd to have Word and Int types in base that public types but aren't exposed by the name sake modules 2) more broadly: while GHC and much extent haskell code makes the strong assumption systematically that Pointers/memory addresses are the same size as Word/Int, this is not guaranteed by haskell 2010 OR the FFI addendum https://www.haskell.org/onlinereport/haskell2010/haskellch8.html thusly, adding WordPtr and IntPtr to the standard on the haskell side is part of a small list of goals i have for inclusion in haskell 2020. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 30 22:43:29 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 May 2018 22:43:29 -0000 Subject: [GHC] #15200: RFC: export WordPtr from Data.Word and IntPtr from Data.Int rather than only from Foreign.Ptr In-Reply-To: <045.4b1c2629d5a6a22d28611cace837aebd@haskell.org> References: <045.4b1c2629d5a6a22d28611cace837aebd@haskell.org> Message-ID: <060.65da59dfe489dd9f9a692d879a3cefa0@haskell.org> #15200: RFC: export WordPtr from Data.Word and IntPtr from Data.Int rather than only from Foreign.Ptr -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by carter: Old description: > Currently we have two types (WordPtr and IntPtr) that should live / be > exposed from Data.Word and Data.Int respectively that currently are not > > reasons for the inclusion > > 1) It seems odd to have Word and Int types in base that public types but > aren't exposed by the name sake modules > > 2) more broadly: while GHC and much extent haskell code makes the strong > assumption systematically that Pointers/memory addresses are the same > size as Word/Int, this is not guaranteed by haskell 2010 OR the FFI > addendum https://www.haskell.org/onlinereport/haskell2010/haskellch8.html > > thusly, adding WordPtr and IntPtr to the standard on the haskell side is > part of a small list of goals i have for inclusion in haskell 2020. New description: Currently we have two types (WordPtr and IntPtr) that should live / be exposed from Data.Word and Data.Int respectively that currently are not reasons for the inclusion 1) It seems odd to have Word and Int types in base that area public types but aren't exposed by the name sake modules 2) more broadly: while GHC and much extent haskell code makes the strong assumption systematically that Pointers/memory addresses are the same size as Word/Int, this is not guaranteed by haskell 2010 OR the FFI addendum https://www.haskell.org/onlinereport/haskell2010/haskellch8.html thusly, adding WordPtr and IntPtr to the standard on the haskell side is part of a small list of goals i have for inclusion in haskell 2020. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 30 22:49:57 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 May 2018 22:49:57 -0000 Subject: [GHC] #7414: plugins always trigger recompilation In-Reply-To: <045.791037be90cd943b6dd26df93dd060d8@haskell.org> References: <045.791037be90cd943b6dd26df93dd060d8@haskell.org> Message-ID: <060.af981c038f6ebf841a9f339131da88ab@haskell.org> #7414: plugins always trigger recompilation -------------------------------------+------------------------------------- Reporter: jwlato | Owner: (none) Type: feature request | Status: closed Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.6.1 Resolution: fixed | Keywords: plugin, | RecompilationCheck Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12567 | Differential Rev(s): Phab:D4366 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed May 30 22:50:46 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 May 2018 22:50:46 -0000 Subject: [GHC] #12567: `ghc --make` recompiles unchanged files when using `-fplugin` OPTIONS In-Reply-To: <048.43f14cd5930ab5b814c814d30cfc4c67@haskell.org> References: <048.43f14cd5930ab5b814c814d30cfc4c67@haskell.org> Message-ID: <063.9dcac1881e985ecf7839545d436a8699@haskell.org> #12567: `ghc --make` recompiles unchanged files when using `-fplugin` OPTIONS -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: plugin, | RecompilationCheck Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #7414 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.6.1 Comment: Yay, this is fixed! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 00:27:00 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 00:27:00 -0000 Subject: [GHC] #15201: GHC 8.4 fails to build on Debian s390x Message-ID: <044.625246c98fa687e3f833d1f81c733f4b@haskell.org> #15201: GHC 8.4 fails to build on Debian s390x --------------------------------+------------------------------------- Reporter: clint | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: Other | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+------------------------------------- {{{ "/usr/bin/ghc" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -lffi -optl-pthread -Wall -Iincludes -Iincludes/dist -Iincludes/dist- derivedconstants/header -Iincludes/dist-ghcconstants/header -package-db libraries/bootstrapping.conf -this-unit-id ghc-8.4.3 -hide-all-packages -i -icompiler/backpack -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage1/build -Icompiler/stage1/build -icompiler/stage1/build/./autogen -Icompiler/stage1/build/./autogen -Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/stage1 -Icompiler/stage1/build/. -Icompiler/stage1/build/parser -Icompiler/stage1/build/utils -Icompiler/stage1/build/stage1 -optP- include -optPcompiler/stage1/build/./autogen/cabal_macros.h -package-id base-4.10.1.0 -package-id deepseq-1.4.3.0 -package-id directory-1.3.0.2 -package-id process-1.6.1.0 -package-id bytestring-0.10.8.2 -package-id binary-0.8.5.1 -package-id time-1.8.0.2 -package-id containers-0.5.10.2 -package-id array-0.5.2.0 -package-id filepath-1.4.1.2 -package-id template-haskell-2.13.0.0 -package-id hpc-0.6.0.3 -package-id transformers-0.5.5.0 -package-id ghc-boot-8.4.3 -package-id ghc-boot- th-8.4.3 -package-id ghci-8.4.3 -package-id unix-2.7.2.2 -package-id terminfo-0.4.1.1 -Wall -Wno-name-shadowing -Wnoncanonical-monad-instances -Wnoncanonical-monadfail-instances -Wnoncanonical-monoid-instances -this- unit-id ghc -XHaskell2010 -XNoImplicitPrelude -DNO_REGS -DNOSMP -optc- DNOSMP -DSTAGE=1 -Rghc-timing -Wcpp-undef -no-user-package-db -rtsopts -odir compiler/stage1/build -hidir compiler/stage1/build -stubdir compiler/stage1/build -c compiler/utils/GhcPrelude.hs -o compiler/stage1/build/GhcPrelude.o /tmp/ghcf6ae_0/ghc_3.hc:7:1: error: warning: data definition has no type or storage class EI_(ghczmprim_GHCziTypes_TrNameS_con_info); ^~~ | 7 | EI_(ghczmprim_GHCziTypes_TrNameS_con_info); | ^ /tmp/ghcf6ae_0/ghc_3.hc:7:1: error: warning: type defaults to 'int' in declaration of 'EI_' [-Wimplicit- int] | 7 | EI_(ghczmprim_GHCziTypes_TrNameS_con_info); | ^ /tmp/ghcf6ae_0/ghc_3.hc:7:1: error: warning: parameter names (without types) in function declaration | 7 | EI_(ghczmprim_GHCziTypes_TrNameS_con_info); | ^ In file included from /tmp/ghcf6ae_0/ghc_3.hc:3:0: error: /tmp/ghcf6ae_0/ghc_3.hc:8:5: error: error: conflicting types for 'ghc_GhcPrelude_zdtrModule4_bytes' EB_(ghc_GhcPrelude_zdtrModule4_bytes); ^ | 8 | EB_(ghc_GhcPrelude_zdtrModule4_bytes); | ^ includes/Stg.h:236:37: error: note: in definition of macro 'EB_' #define EB_(X) extern const char X[] ^ | 236 | #define EB_(X) extern const char X[] | ^ /tmp/ghcf6ae_0/ghc_3.hc:6:6: error: note: previous definition of 'ghc_GhcPrelude_zdtrModule4_bytes' was here char ghc_GhcPrelude_zdtrModule4_bytes[] = "ghc"; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 6 | char ghc_GhcPrelude_zdtrModule4_bytes[] = "ghc"; | ^ /tmp/ghcf6ae_0/ghc_3.hc:10:6: error: error: 'ghczmprim_GHCziTypes_TrNameS_con_info' undeclared here (not in a function) (W_)&ghczmprim_GHCziTypes_TrNameS_con_info, (W_)&ghc_GhcPrelude_zdtrModule4_bytes ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 10 | (W_)&ghczmprim_GHCziTypes_TrNameS_con_info, (W_)&ghc_GhcPrelude_zdtrModule4_bytes | ^ /tmp/ghcf6ae_0/ghc_3.hc:13:1: error: warning: data definition has no type or storage class EI_(ghczmprim_GHCziTypes_TrNameS_con_info); ^~~ | 13 | EI_(ghczmprim_GHCziTypes_TrNameS_con_info); | ^ /tmp/ghcf6ae_0/ghc_3.hc:13:1: error: warning: type defaults to 'int' in declaration of 'EI_' [-Wimplicit- int] | 13 | EI_(ghczmprim_GHCziTypes_TrNameS_con_info); | ^ /tmp/ghcf6ae_0/ghc_3.hc:13:1: error: warning: parameter names (without types) in function declaration | 13 | EI_(ghczmprim_GHCziTypes_TrNameS_con_info); | ^ In file included from /tmp/ghcf6ae_0/ghc_3.hc:3:0: error: /tmp/ghcf6ae_0/ghc_3.hc:14:5: error: error: conflicting types for 'ghc_GhcPrelude_zdtrModule2_bytes' EB_(ghc_GhcPrelude_zdtrModule2_bytes); ^ | 14 | EB_(ghc_GhcPrelude_zdtrModule2_bytes); | ^ includes/Stg.h:236:37: error: note: in definition of macro 'EB_' #define EB_(X) extern const char X[] ^ | 236 | #define EB_(X) extern const char X[] | ^ /tmp/ghcf6ae_0/ghc_3.hc:12:6: error: note: previous definition of 'ghc_GhcPrelude_zdtrModule2_bytes' was here char ghc_GhcPrelude_zdtrModule2_bytes[] = "GhcPrelude"; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 12 | char ghc_GhcPrelude_zdtrModule2_bytes[] = "GhcPrelude"; | ^ /tmp/ghcf6ae_0/ghc_3.hc:16:1: error: error: initializer element is not constant (W_)&ghczmprim_GHCziTypes_TrNameS_con_info, (W_)&ghc_GhcPrelude_zdtrModule2_bytes ^ | 16 | (W_)&ghczmprim_GHCziTypes_TrNameS_con_info, (W_)&ghc_GhcPrelude_zdtrModule2_bytes | ^ /tmp/ghcf6ae_0/ghc_3.hc:16:1: error: note: (near initialization for 'ghc_GhcPrelude_zdtrModule1_closure[0]') | 16 | (W_)&ghczmprim_GHCziTypes_TrNameS_con_info, (W_)&ghc_GhcPrelude_zdtrModule2_bytes | ^ /tmp/ghcf6ae_0/ghc_3.hc:18:1: error: warning: data definition has no type or storage class EI_(ghczmprim_GHCziTypes_Module_con_info); ^~~ | 18 | EI_(ghczmprim_GHCziTypes_Module_con_info); | ^ /tmp/ghcf6ae_0/ghc_3.hc:18:1: error: warning: type defaults to 'int' in declaration of 'EI_' [-Wimplicit- int] | 18 | EI_(ghczmprim_GHCziTypes_Module_con_info); | ^ /tmp/ghcf6ae_0/ghc_3.hc:18:1: error: warning: parameter names (without types) in function declaration | 18 | EI_(ghczmprim_GHCziTypes_Module_con_info); | ^ /tmp/ghcf6ae_0/ghc_3.hc:19:1: error: warning: data definition has no type or storage class EI_(ghc_GhcPrelude_zdtrModule1_closure); ^~~ | 19 | EI_(ghc_GhcPrelude_zdtrModule1_closure); | ^ /tmp/ghcf6ae_0/ghc_3.hc:19:1: error: warning: type defaults to 'int' in declaration of 'EI_' [-Wimplicit- int] | 19 | EI_(ghc_GhcPrelude_zdtrModule1_closure); | ^ /tmp/ghcf6ae_0/ghc_3.hc:19:1: error: warning: parameter names (without types) in function declaration | 19 | EI_(ghc_GhcPrelude_zdtrModule1_closure); | ^ /tmp/ghcf6ae_0/ghc_3.hc:20:1: error: warning: data definition has no type or storage class EI_(ghc_GhcPrelude_zdtrModule3_closure); ^~~ | 20 | EI_(ghc_GhcPrelude_zdtrModule3_closure); | ^ /tmp/ghcf6ae_0/ghc_3.hc:20:1: error: warning: type defaults to 'int' in declaration of 'EI_' [-Wimplicit- int] | 20 | EI_(ghc_GhcPrelude_zdtrModule3_closure); | ^ /tmp/ghcf6ae_0/ghc_3.hc:20:1: error: warning: parameter names (without types) in function declaration | 20 | EI_(ghc_GhcPrelude_zdtrModule3_closure); | ^ /tmp/ghcf6ae_0/ghc_3.hc:22:6: error: error: 'ghczmprim_GHCziTypes_Module_con_info' undeclared here (not in a function); did you mean 'ghczmprim_GHCziTypes_TrNameS_con_info'? (W_)&ghczmprim_GHCziTypes_Module_con_info, ((W_)&ghc_GhcPrelude_zdtrModule3_closure+1), ((W_)&ghc_GhcPrelude_zdtrModule1_closure+1), 0x3UL ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ghczmprim_GHCziTypes_TrNameS_con_info | 22 | (W_)&ghczmprim_GHCziTypes_Module_con_info, ((W_)&ghc_GhcPrelude_zdtrModule3_closure+1), ((W_)&ghc_GhcPrelude_zdtrModule1_closure+1), 0x3UL | ^ /tmp/ghcf6ae_0/ghc_3.hc:22:1: error: error: initializer element is not constant (W_)&ghczmprim_GHCziTypes_Module_con_info, ((W_)&ghc_GhcPrelude_zdtrModule3_closure+1), ((W_)&ghc_GhcPrelude_zdtrModule1_closure+1), 0x3UL ^ | 22 | (W_)&ghczmprim_GHCziTypes_Module_con_info, ((W_)&ghc_GhcPrelude_zdtrModule3_closure+1), ((W_)&ghc_GhcPrelude_zdtrModule1_closure+1), 0x3UL | ^ /tmp/ghcf6ae_0/ghc_3.hc:22:1: error: note: (near initialization for 'ghc_GhcPrelude_zdtrModule_closure[0]') | 22 | (W_)&ghczmprim_GHCziTypes_Module_con_info, ((W_)&ghc_GhcPrelude_zdtrModule3_closure+1), ((W_)&ghc_GhcPrelude_zdtrModule1_closure+1), 0x3UL | ^ `gcc' failed in phase `C Compiler'. (Exit code: 1) }}} https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=s390x&ver=8.4.3-1&stamp=1527725682&raw=0 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 00:35:46 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 00:35:46 -0000 Subject: [GHC] #15088: Test T3234 is fragile In-Reply-To: <049.b4734c814119c3f6b3a53330ff37ca44@haskell.org> References: <049.b4734c814119c3f6b3a53330ff37ca44@haskell.org> Message-ID: <064.f14de5f133b2eb45ae1426ac6f2d10a9@haskell.org> #15088: Test T3234 is fragile -------------------------------------+------------------------------------- Reporter: mpickering | Owner: RolandSenn Type: task | Status: closed Priority: lowest | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T3234 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Merged. Thanks roland! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 01:32:07 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 01:32:07 -0000 Subject: [GHC] #15199: Build fails on Debian armhf (armv7l-unknown-linux-gnueabihf) In-Reply-To: <044.81af1940b7343631708d21b21be1c899@haskell.org> References: <044.81af1940b7343631708d21b21be1c899@haskell.org> Message-ID: <059.117a5823c599615872436f6df365cbf2@haskell.org> #15199: Build fails on Debian armhf (armv7l-unknown-linux-gnueabihf) -------------------------------------+------------------------------------- Reporter: clint | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.4.4 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => infoneeded Comment: I'm pretty sure this is fixed in `master` although it would be great to have confirmation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 01:38:10 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 01:38:10 -0000 Subject: [GHC] #15198: `Language.Haskell.TH.Syntax.reify` returns * rather than Constraint In-Reply-To: <045.33db5deaa1796fcc21563427883ef147@haskell.org> References: <045.33db5deaa1796fcc21563427883ef147@haskell.org> Message-ID: <060.b22b168deb5b4184b8b0d0cc738ae52f@haskell.org> #15198: `Language.Haskell.TH.Syntax.reify` returns * rather than Constraint -------------------------------------+------------------------------------- Reporter: benzrf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.4 Component: Template Haskell | Version: 8.4.2 Resolution: | Keywords: reify | constraint constraintkinds Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: 11715 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * blockedby: => 11715 Comment: This is very likely a manifestation of #11715. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 01:39:10 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 01:39:10 -0000 Subject: [GHC] #15198: `Language.Haskell.TH.Syntax.reify` returns * rather than Constraint In-Reply-To: <045.33db5deaa1796fcc21563427883ef147@haskell.org> References: <045.33db5deaa1796fcc21563427883ef147@haskell.org> Message-ID: <060.b0c334f00138733680752b3b63bae293@haskell.org> #15198: `Language.Haskell.TH.Syntax.reify` returns * rather than Constraint -------------------------------------+------------------------------------- Reporter: benzrf | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.4 Component: Template Haskell | Version: 8.4.2 Resolution: duplicate | Keywords: reify | constraint constraintkinds Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #14869 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * blockedby: 11715 => * related: => #14869 Comment: Thankfully, this was fixed in GHC HEAD in commit 49ac3f0f2a13f66fea31a258fa98b0de39bfbf10 (Fix #14869 by being more mindful of Type vs. Constraint). See also the `tests/th/T14869` test case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 01:42:17 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 01:42:17 -0000 Subject: [GHC] #15201: GHC 8.4 fails to build on Debian s390x In-Reply-To: <044.625246c98fa687e3f833d1f81c733f4b@haskell.org> References: <044.625246c98fa687e3f833d1f81c733f4b@haskell.org> Message-ID: <059.1ca286a9aa6b0c8ecff1edbda6fbb4ae@haskell.org> #15201: GHC 8.4 fails to build on Debian s390x -------------------------------------+------------------------------ Reporter: clint | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Other Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------ Changes (by bgamari): * status: new => patch Comment: Hmm, I take it this is a regression? If so, when was the last time this was known to work? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 01:48:26 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 01:48:26 -0000 Subject: [GHC] #15201: GHC 8.4 fails to build on Debian s390x In-Reply-To: <044.625246c98fa687e3f833d1f81c733f4b@haskell.org> References: <044.625246c98fa687e3f833d1f81c733f4b@haskell.org> Message-ID: <059.a86d71cb17e2a53bcf2f6f1d7c50beb6@haskell.org> #15201: GHC 8.4 fails to build on Debian s390x -------------------------------------+------------------------------ Reporter: clint | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Other Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------ Comment (by clint): 8.2.2 built fine, but no release of 8.4 has. Successful 8.2 build: https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=s390x&ver=8.2.2-3&stamp=1523235519&raw=0 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 02:05:54 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 02:05:54 -0000 Subject: [GHC] #14492: Tiered memory allocation restricts available memory In-Reply-To: <044.e21e37476590d999c81ca942af908658@haskell.org> References: <044.e21e37476590d999c81ca942af908658@haskell.org> Message-ID: <059.a05c7340f1db55fc1cdab3b8a5009dbd@haskell.org> #14492: Tiered memory allocation restricts available memory -------------------------------------+------------------------------------- Reporter: unode | Owner: bgamari Type: bug | Status: patch Priority: high | Milestone: 8.6.1 Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: memory ulimit Operating System: Linux | Architecture: x86_64 Type of failure: Poor/confusing | (amd64) error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4215 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"730781b42a003604cfa047a02280757a07b09581/ghc" 730781b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="730781b42a003604cfa047a02280757a07b09581" rts/posix: Use less aggressive backoff schedule for heap reservation sizing When we allocate the heap on POSIX platforms we generally just ask for a 1TB chunk of address space and call it a day. However, if the user has set a ulimit then this request will fail. In this case we would previously try successively smaller allocation requests, reducing the request size by a factor of two each time. However, this means that GHC will significantly allocate a significantly smaller heap than the available physical memory size in some circumstances. Imagine, for instance, a machine with 512 GB of physical memory but a ulimit of 511 GB: we would be limited to a 256 GB heap. We now use a less aggressive back-off policy, reducing by one-eighth the last allocation size each try. Thanks to luispedro for the suggested approach. Test Plan: Validate Reviewers: simonmar, erikd Subscribers: rwbarton, thomie GHC Trac Issues: #14492 Differential Revision: https://phabricator.haskell.org/D4215 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 02:05:54 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 02:05:54 -0000 Subject: [GHC] #15088: Test T3234 is fragile In-Reply-To: <049.b4734c814119c3f6b3a53330ff37ca44@haskell.org> References: <049.b4734c814119c3f6b3a53330ff37ca44@haskell.org> Message-ID: <064.042634fa582ed0d27c09107ca92ea1d0@haskell.org> #15088: Test T3234 is fragile -------------------------------------+------------------------------------- Reporter: mpickering | Owner: RolandSenn Type: task | Status: closed Priority: lowest | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T3234 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"91a82de011d3bc1783f849168d90268bc24ceeee/ghc" 91a82de0/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="91a82de011d3bc1783f849168d90268bc24ceeee" testsuite: Make T3234 more robust Just look for the rule firing that we want to see instead of matching on the entire dump. Fixes #15088. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 02:05:54 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 02:05:54 -0000 Subject: [GHC] #15158: T8089 failing with ghci, threaded1, threaded2, profthreaded In-Reply-To: <048.e0a32f56c09af74c66cfdba0027fd931@haskell.org> References: <048.e0a32f56c09af74c66cfdba0027fd931@haskell.org> Message-ID: <063.90dc2f9f0e9ea24ce9b3313e8decb6f9@haskell.org> #15158: T8089 failing with ghci, threaded1, threaded2, profthreaded -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: libraries/base | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: T8089 Blocked By: | Blocking: Related Tickets: #8089, #7325, | Differential Rev(s): Phab:D4700 #15064 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"21a9fb5ff3714addf28dbe270af5d10640d89ad9/ghc" 21a9fb5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="21a9fb5ff3714addf28dbe270af5d10640d89ad9" base/TimerManager: Clamp timer expiration time to maxBound Previously we would allow the expiration time to overflow, which in practice meant that `threadDelay maxBound` we return far earlier than circa 2500 CE. For now we fix this by simply clamping to maxBound. Fixes #15158. Test Plan: Validate, run T8089 Reviewers: simonmar, hvr Reviewed By: simonmar Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15158 Differential Revision: https://phabricator.haskell.org/D4719 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 02:05:54 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 02:05:54 -0000 Subject: [GHC] #15157: Use a better string type (ByteString?!) for HsDocString In-Reply-To: <046.8bb89a9e841d6d5ba281eb5787d40851@haskell.org> References: <046.8bb89a9e841d6d5ba281eb5787d40851@haskell.org> Message-ID: <061.234c4a905399634007cb784112f33627@haskell.org> #15157: Use a better string type (ByteString?!) for HsDocString -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4743 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"d1beebb881722109d6935941e541eb175a9d6c62/ghc" d1beebb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d1beebb881722109d6935941e541eb175a9d6c62" Make HsDocString a newtype of ByteString Docstrings don't profit from FastString's interning, so we switch to a different type that doesn't incur this overhead. Updates the haddock submodule. Reviewers: alexbiehl, bgamari Reviewed By: alexbiehl, bgamari Subscribers: rwbarton, thomie, mpickering, carter GHC Trac Issues: #15157 Differential Revision: https://phabricator.haskell.org/D4743 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 02:05:54 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 02:05:54 -0000 Subject: [GHC] #14444: Linker limit on OS X Sierra breaks builds for big projects In-Reply-To: <049.ef1cbd3eecd105a31deac573ded19c35@haskell.org> References: <049.ef1cbd3eecd105a31deac573ded19c35@haskell.org> Message-ID: <064.25534deb928891f42a8449fcbd013259@haskell.org> #14444: Linker limit on OS X Sierra breaks builds for big projects -------------------------------------+------------------------------------- Reporter: dredozubov | Owner: angerman Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Linking) | Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4717 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"b592bd98ff25730bbe3c13d6f62a427df8c78e28/ghc" b592bd98/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b592bd98ff25730bbe3c13d6f62a427df8c78e28" dead strip dylibs on macOS When linking dynamic libraries or executables, we compute the full transitive closure over the dependencies, and instruct the linker to link all dependencies. With deep dependency trees the number of transitive dependencies can grow quickly. macOS since the Sierra release has an upper limit on the load command sizes the linker parses when loading dynamic lirbaries. As such it is mandatory to keep the number of load commands (and their size) small on recent macOS releases. An approach that would just link direct dependencies as specified by the -package-id flag is insufficient, because GHC can inline across packages and the library or executable being linked could refer to symbols deep in the dependency tree. If we just recursively linked librarys and re-exported their symbols, this increases the number of symbols in libraries with many dependencies and ultimately puts excessive strain on the linker to the point where linking takes a lot longer than even the compilation of the modules. We can however build a list of symbols from the obejcts we want to link, and try to compute the libraries we need to link that contain those symbols from the transitive dependency closure. Luckily, we don't need to write this ourselves, but can use the ld64 `-dead_strip_dylibs` linker flag on macOS to achive the same result. This will link only the libraries that are actually referenced, which is usually a small subset of the full transitive dependency closure. As such we should stay within the load command size limit for almost all but pathological cases. Reviewers: bgamari Reviewed By: bgamari Subscribers: lelf, rwbarton, thomie, carter GHC Trac Issues: #14444 Differential Revision: https://phabricator.haskell.org/D4714 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 02:05:54 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 02:05:54 -0000 Subject: [GHC] #15104: Update JMP_TBL targets during shortcutting for x86 codegen. In-Reply-To: <047.941563573fab164b1cacdf128ce64fa8@haskell.org> References: <047.941563573fab164b1cacdf128ce64fa8@haskell.org> Message-ID: <062.8f8b87440a2aedcb7d321efb762f9abd@haskell.org> #15104: Update JMP_TBL targets during shortcutting for x86 codegen. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler (NCG) | Version: 8.5 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4595 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"5748c79e5a7a6bd1b0bfffc514d8f4f4da92e815/ghc" 5748c79e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5748c79e5a7a6bd1b0bfffc514d8f4f4da92e815" Change jump targets in JMP_TBL from blocks to X86.JumpDest. Jump tables always point to blocks when we first generate them. However there are rare situations where we can shortcut one of these blocks to a static address during the asm shortcutting pass. While we already updated the data section accordingly this patch also extends this to the references stored in JMP_TBL. Test Plan: ci Reviewers: bgamari Reviewed By: bgamari Subscribers: thomie, carter GHC Trac Issues: #15104 Differential Revision: https://phabricator.haskell.org/D4595 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 02:16:25 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 02:16:25 -0000 Subject: [GHC] #15197: Apparent missing dependency in ghc-heap In-Reply-To: <046.f9380793ce8ad25be083749857e75f4a@haskell.org> References: <046.f9380793ce8ad25be083749857e75f4a@haskell.org> Message-ID: <061.c42bdf6d439368b2946fdfdeacf2fcf7@haskell.org> #15197: Apparent missing dependency in ghc-heap -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4753 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 02:27:04 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 02:27:04 -0000 Subject: [GHC] #15157: Use a better string type (ByteString?!) for HsDocString In-Reply-To: <046.8bb89a9e841d6d5ba281eb5787d40851@haskell.org> References: <046.8bb89a9e841d6d5ba281eb5787d40851@haskell.org> Message-ID: <061.6a815494e4feb7569e7f6906a7946e9a@haskell.org> #15157: Use a better string type (ByteString?!) for HsDocString -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4743 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sjakobi): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 02:42:37 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 02:42:37 -0000 Subject: [GHC] #9479: Report required constraints when reporting the type of a hole In-Reply-To: <056.d301c5f3e1df29c162c4f7ce444029a2@haskell.org> References: <056.d301c5f3e1df29c162c4f7ce444029a2@haskell.org> Message-ID: <071.b7597f09ff301b2669e183c2bc59b6b1@haskell.org> #9479: Report required constraints when reporting the type of a hole -------------------------------------+------------------------------------- Reporter: | Owner: (none) dominiquedevriese | Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.8.3 checker) | Resolution: fixed | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9091 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * related: => #9091 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 03:13:04 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 03:13:04 -0000 Subject: [GHC] #15202: Internal error showing typed hole in GHCi Message-ID: <045.7429a5cde007875512b47f53bc5766b7@haskell.org> #15202: Internal error showing typed hole in GHCi -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 (Type checker) | Keywords: TypedHoles | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Run `ghc --interactive`, and at the prompt type {{{#!hs default () fish :: Eq a => a; fish = undefined foo :: String; foo = show _ }}} The following error appears: {{{ :1:1: error: GHC internal error: ‘Ghci1.$trModule’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [r2CZ :-> Identifier[foo::String, TopLevelLet]] }}} I have not yet been able to reproduce this loading a module; it seems to need to be on the command line. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 03:18:37 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 03:18:37 -0000 Subject: [GHC] #15202: Internal error showing typed hole in GHCi In-Reply-To: <045.7429a5cde007875512b47f53bc5766b7@haskell.org> References: <045.7429a5cde007875512b47f53bc5766b7@haskell.org> Message-ID: <060.5e2fdffd13fd68f22cd4852cd1340ee5@haskell.org> #15202: Internal error showing typed hole in GHCi -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): This did not occur in 8.4.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 03:30:21 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 03:30:21 -0000 Subject: [GHC] #15203: Wrong location reported for kind error Message-ID: <047.8501454750f2e11a207588647ae72525@haskell.org> #15203: Wrong location reported for kind error -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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: -------------------------------------+------------------------------------- When I try to compile {{{#!hs {-# LANGUAGE PolyKinds, ConstraintKinds, TypeFamilies, FlexibleContexts #-} module Bug where import Data.Proxy type T (a :: k1) (b :: k2) = (a ~ b, Show (Proxy (a :: k1)), Show (Proxy (b :: k2))) }}} I get {{{ Bug.hs:7:80: error: • Couldn't match ‘k1’ with ‘k2’ • In the type declaration for ‘T’ | 7 | type T (a :: k1) (b :: k2) = (a ~ b, Show (Proxy (a :: k1)), Show (Proxy (b :: k2))) | ^^ }}} The problem is that the `k2` that's highlighted has nothing at all to do with the error. Indeed, some experimentation shows that GHC will highlight the first occurrence of `k2` to the right of the `=`. The error is actually from unification caused by `a ~ b`. I noticed this because I've been tightening up the way GHC does left-to- right ordering during implicit quantification (while working on something more substantial). In so doing, I made sure to prefer kind variable occurrences to the ''left'' of the = over those to the right. But then I got a testsuite failure due to a changed location of an error. This is caused by the call to `report_sig_tv_err` in `tcTyClTyVars`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 07:38:09 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 07:38:09 -0000 Subject: [GHC] #15186: ghc 8.4.2 panic in profiling build In-Reply-To: <045.764163a11088d02a8878689da6d8a04b@haskell.org> References: <045.764163a11088d02a8878689da6d8a04b@haskell.org> Message-ID: <060.26283a0f8259e23f90f9a09de2698c84@haskell.org> #15186: ghc 8.4.2 panic in profiling build -------------------------------------+------------------------------------- Reporter: kquick | Owner: bgamari Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Profiling | Version: 8.4.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: T15186 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4756, Wiki Page: | Phab:D4757 -------------------------------------+------------------------------------- Comment (by simonpj): Just to fill in a bit more detail, the problem is not with `$mPointerExpr` itself, but with a local binding within it, namely {{{ let { cont_s1eD [Dmd=] :: (ctx_a1cW ~ 'T15186a.EmptyCtx) => r_a1af [LclId, Arity=1, Str= ...] cont_s1eD = \ _ [Occ=Dead, Dmd=, OS=OneShot] -> case v1_a1d0 of { BVRepr -> case ds_s1eL of { App ds_d1bR [Dmd=] -> cont_a1ai GHC.Prim.void#; ExprDummy -> fail_a1aj GHC.Prim.void# }; TypeReprDummy -> fail_a1aj GHC.Prim.void# } } in }}} Here `r_a1af :: TypeRep r_a1ae` is levity-polymorphic, so we must not remove the argument during w/w even though it is dead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 08:18:15 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 08:18:15 -0000 Subject: [GHC] #7411: Exceptions are optimized away in certain situations In-Reply-To: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> References: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> Message-ID: <065.26401b0869f4c25fa92d313bf893b298@haskell.org> #7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Pinging simonpj: do you think we need more data than this before deciding to remove the state hack, or at least make `-fno-state-hack` the default? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 10:26:15 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 10:26:15 -0000 Subject: [GHC] #15202: Internal error showing typed hole in GHCi In-Reply-To: <045.7429a5cde007875512b47f53bc5766b7@haskell.org> References: <045.7429a5cde007875512b47f53bc5766b7@haskell.org> Message-ID: <060.c40458a9cdd7c97f0efd232040771ea7@haskell.org> #15202: Internal error showing typed hole in GHCi -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: duplicate | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15007 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #15007 Comment: I believe this is a duplicate of #15007, so I'll close this in favor of that ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 10:27:34 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 10:27:34 -0000 Subject: [GHC] #15007: Don't keep shadowed variables in ghci, both renamer and type checker In-Reply-To: <049.2656489ff85910f6a80bbfa971643315@haskell.org> References: <049.2656489ff85910f6a80bbfa971643315@haskell.org> Message-ID: <064.3637d3f60f63b35dbda5477fad31f12c@haskell.org> #15007: Don't keep shadowed variables in ghci, both renamer and type checker -------------------------------------+------------------------------------- Reporter: sighingnow | Owner: sighingnow Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.5 Resolution: | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11547 #14052 | Differential Rev(s): #15202 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #11547 #14052 => #11547 #14052 #15202 Comment: Another example from #15202: > Run `ghc --interactive`, and at the prompt type > > {{{#!hs > default () > fish :: Eq a => a; fish = undefined > foo :: String; foo = show _ > }}} > > The following error appears: > > {{{ > :1:1: error: > GHC internal error: ‘Ghci1.$trModule’ is not in scope during type checking, but it passed the renamer > tcl_env of environment: [r2CZ :-> Identifier[foo::String, TopLevelLet]] > }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 10:30:54 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 10:30:54 -0000 Subject: [GHC] #15186: ghc 8.4.2 panic in profiling build In-Reply-To: <045.764163a11088d02a8878689da6d8a04b@haskell.org> References: <045.764163a11088d02a8878689da6d8a04b@haskell.org> Message-ID: <060.2beb17fa4ff10a1357c1b324f50f960c@haskell.org> #15186: ghc 8.4.2 panic in profiling build -------------------------------------+------------------------------------- Reporter: kquick | Owner: bgamari Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Profiling | Version: 8.4.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: T15186 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4755, Wiki Page: | Phab:D4757 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: Phab:D4756, Phab:D4757 => Phab:D4755, Phab:D4757 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 10:45:10 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 10:45:10 -0000 Subject: [GHC] #14492: Tiered memory allocation restricts available memory In-Reply-To: <044.e21e37476590d999c81ca942af908658@haskell.org> References: <044.e21e37476590d999c81ca942af908658@haskell.org> Message-ID: <059.f4f5fb53cc96636725b88b86225fc51a@haskell.org> #14492: Tiered memory allocation restricts available memory -------------------------------------+------------------------------------- Reporter: unode | Owner: bgamari Type: bug | Status: patch Priority: high | Milestone: 8.6.1 Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: memory ulimit Operating System: Linux | Architecture: x86_64 Type of failure: Poor/confusing | (amd64) error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4215 Wiki Page: | -------------------------------------+------------------------------------- Comment (by unode): bgamari thanks for the fix. There's also the 1TB maximum reservation that luispedro mentioned on comment:4 which seems to be set on https://git.haskell.org/ghc.git/blob/730781b42a003604cfa047a02280757a07b09581:/rts/sm/MBlock.c#l663 Implementing the probing solution you proposed on comment:8 would also address the 1TB limit.\\ Did you manage to get anywhere with that approach? Thanks again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 10:58:00 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 10:58:00 -0000 Subject: [GHC] #14492: Tiered memory allocation restricts available memory In-Reply-To: <044.e21e37476590d999c81ca942af908658@haskell.org> References: <044.e21e37476590d999c81ca942af908658@haskell.org> Message-ID: <059.c048d4f16970a7e7397b1503a1a4899c@haskell.org> #14492: Tiered memory allocation restricts available memory -------------------------------------+------------------------------------- Reporter: unode | Owner: bgamari Type: bug | Status: patch Priority: high | Milestone: 8.6.1 Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: memory ulimit Operating System: Linux | Architecture: x86_64 Type of failure: Poor/confusing | (amd64) error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4215 Wiki Page: | -------------------------------------+------------------------------------- Comment (by unode): PS: On your patch above if I use: {{{ #!diff - printf("%s: cur: %d\n", name, lim.rlim_cur); - printf("%s: max: %d\n", name, lim.rlim_max); + printf("%s: cur: %lu\n", name, lim.rlim_cur); + printf("%s: max: %lu\n", name, lim.rlim_max); }}} I get correct values from the test program, both for AS and RSS. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 11:19:09 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 11:19:09 -0000 Subject: [GHC] #15155: How untagged pointers sneak into banged fields In-Reply-To: <048.7d229d504bd9df060a5294d6d9eccfdc@haskell.org> References: <048.7d229d504bd9df060a5294d6d9eccfdc@haskell.org> Message-ID: <063.95eae19f09be492cb348a235040c6e07@haskell.org> #15155: How untagged pointers sneak into banged fields -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: heisenbug Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 14677 Related Tickets: 13027 7308 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by heisenbug): * related: 13027 => 13027 7308 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 11:21:51 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 11:21:51 -0000 Subject: [GHC] #15155: How untagged pointers sneak into banged fields In-Reply-To: <048.7d229d504bd9df060a5294d6d9eccfdc@haskell.org> References: <048.7d229d504bd9df060a5294d6d9eccfdc@haskell.org> Message-ID: <063.c3a86496be535c78fe41bdfe0b938011@haskell.org> #15155: How untagged pointers sneak into banged fields -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: heisenbug Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 14677 Related Tickets: #13027 #7308 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by heisenbug): * related: 13027 7308 => #13027 #7308 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 11:30:34 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 11:30:34 -0000 Subject: [GHC] #15158: T8089 failing with ghci, threaded1, threaded2, profthreaded In-Reply-To: <048.e0a32f56c09af74c66cfdba0027fd931@haskell.org> References: <048.e0a32f56c09af74c66cfdba0027fd931@haskell.org> Message-ID: <063.866c848d4ea5a81ecc03135112d13a4d@haskell.org> #15158: T8089 failing with ghci, threaded1, threaded2, profthreaded -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: libraries/base | Version: 8.5 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: T8089 Blocked By: | Blocking: Related Tickets: #8089, #7325, | Differential Rev(s): Phab:D4700 #15064 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 11:32:21 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 11:32:21 -0000 Subject: [GHC] #15104: Update JMP_TBL targets during shortcutting for x86 codegen. In-Reply-To: <047.941563573fab164b1cacdf128ce64fa8@haskell.org> References: <047.941563573fab164b1cacdf128ce64fa8@haskell.org> Message-ID: <062.1f2d7196eaaf18d65228eefc441aec10@haskell.org> #15104: Update JMP_TBL targets during shortcutting for x86 codegen. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler (NCG) | Version: 8.5 Resolution: fixed | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4595 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 11:33:05 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 11:33:05 -0000 Subject: [GHC] #14444: Linker limit on OS X Sierra breaks builds for big projects In-Reply-To: <049.ef1cbd3eecd105a31deac573ded19c35@haskell.org> References: <049.ef1cbd3eecd105a31deac573ded19c35@haskell.org> Message-ID: <064.7bddf7c2603004f55f6f982ab830edfc@haskell.org> #14444: Linker limit on OS X Sierra breaks builds for big projects -------------------------------------+------------------------------------- Reporter: dredozubov | Owner: angerman Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 (Linking) | Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4717 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.6.1 Comment: The above should fix 99% of these issues. Thanks to angerman for his persistence in searching for a fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 11:33:16 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 11:33:16 -0000 Subject: [GHC] #15155: How untagged pointers sneak into banged fields In-Reply-To: <048.7d229d504bd9df060a5294d6d9eccfdc@haskell.org> References: <048.7d229d504bd9df060a5294d6d9eccfdc@haskell.org> Message-ID: <063.e4fc31c4c54f9e9ca6258fb7ab232afe@haskell.org> #15155: How untagged pointers sneak into banged fields -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: heisenbug Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 14677 Related Tickets: #13027 #7308 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by heisenbug): While building ghc stage2 I've seen well over a thousand of these indirections being generated. I am working on a scheme which would allow putting all representationally equivalent (e.g. those wrapped by `cast`) bindings into an equivalence class and refer to the whole thing (by the non-casted representant) from the untyped stages (i.e. STG) on. With looming code-reuse techniques like ''GND'' (and I am looking at you `DerivingVia`) there will be much more coercing and casting going on, so I think this will become even more urgent in the future. Besides it would eliminate name table entries from `.so` files etc., speeding up (dynamic) linking a bit and saving even more space. Optionally the name canonicalisation could happen at the point where the assembly file is emitted. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 11:47:56 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 11:47:56 -0000 Subject: [GHC] #15204: GHC 8.4 fails to build on Debian mips Message-ID: <044.1e90470ed0277ec2b851547a09b463cc@haskell.org> #15204: GHC 8.4 fails to build on Debian mips --------------------------------+------------------------------------- Reporter: clint | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: mips | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+------------------------------------- 8.2.2 worked, 8.4 fails: {{{ "/usr/bin/ghc" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -lffi -optl-pthread -optc--param -optcggc-min-expand=10 -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist- ghcconstants/header -package-db libraries/bootstrapping.conf -this-unit- id ghc-8.4.3 -hide-all-packages -i -icompiler/backpack -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage1/build -Icompiler/stage1/build -icompiler/stage1/build/./autogen -Icompiler/stage1/build/./autogen -Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/stage1 -Icompiler/stage1/build/. -Icompiler/stage1/build/parser -Icompiler/stage1/build/utils -Icompiler/stage1/build/stage1 -optP-include -optPcompiler/stage1/build/./autogen/cabal_macros.h -package-id base-4.10.1.0 -package-id deepseq-1.4.3.0 -package-id directory-1.3.0.2 -package-id process-1.6.1.0 -package-id bytestring-0.10.8.2 -package-id binary-0.8.5.1 -package-id time-1.8.0.2 -package-id containers-0.5.10.2 -package-id array-0.5.2.0 -package-id filepath-1.4.1.2 -package-id template-haskell-2.13.0.0 -package-id hpc-0.6.0.3 -package-id transformers-0.5.5.0 -package-id ghc-boot-8.4.3 -package-id ghc-boot- th-8.4.3 -package-id ghci-8.4.3 -package-id unix-2.7.2.2 -package-id terminfo-0.4.1.1 -Wall -Wno-name-shadowing -Wnoncanonical-monad-instances -Wnoncanonical-monadfail-instances -Wnoncanonical-monoid-instances -this- unit-id ghc -XHaskell2010 -XNoImplicitPrelude -DNO_REGS -DNOSMP -optc- DNOSMP -DSTAGE=1 -Rghc-timing -Wcpp-undef -no-user-package-db -rtsopts -odir compiler/stage1/build -hidir compiler/stage1/build -stubdir compiler/stage1/build -c compiler/utils/GhcPrelude.hs -o compiler/stage1/build/GhcPrelude.o /tmp/ghca022_0/ghc_3.hc:7:1: error: warning: data definition has no type or storage class EI_(ghczmprim_GHCziTypes_TrNameS_con_info); ^~~ | 7 | EI_(ghczmprim_GHCziTypes_TrNameS_con_info); | ^ /tmp/ghca022_0/ghc_3.hc:7:1: error: warning: type defaults to 'int' in declaration of 'EI_' [-Wimplicit- int] | 7 | EI_(ghczmprim_GHCziTypes_TrNameS_con_info); | ^ /tmp/ghca022_0/ghc_3.hc:7:1: error: warning: parameter names (without types) in function declaration | 7 | EI_(ghczmprim_GHCziTypes_TrNameS_con_info); | ^ In file included from /tmp/ghca022_0/ghc_3.hc:3:0: error: /tmp/ghca022_0/ghc_3.hc:8:5: error: error: conflicting types for 'ghc_GhcPrelude_zdtrModule4_bytes' EB_(ghc_GhcPrelude_zdtrModule4_bytes); ^ | 8 | EB_(ghc_GhcPrelude_zdtrModule4_bytes); | ^ includes/Stg.h:236:37: error: note: in definition of macro 'EB_' #define EB_(X) extern const char X[] ^ | 236 | #define EB_(X) extern const char X[] | ^ /tmp/ghca022_0/ghc_3.hc:6:6: error: note: previous definition of 'ghc_GhcPrelude_zdtrModule4_bytes' was here char ghc_GhcPrelude_zdtrModule4_bytes[] = "ghc"; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 6 | char ghc_GhcPrelude_zdtrModule4_bytes[] = "ghc"; | ^ /tmp/ghca022_0/ghc_3.hc:10:6: error: error: 'ghczmprim_GHCziTypes_TrNameS_con_info' undeclared here (not in a function) (W_)&ghczmprim_GHCziTypes_TrNameS_con_info, (W_)&ghc_GhcPrelude_zdtrModule4_bytes ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 10 | (W_)&ghczmprim_GHCziTypes_TrNameS_con_info, (W_)&ghc_GhcPrelude_zdtrModule4_bytes | ^ /tmp/ghca022_0/ghc_3.hc:13:1: error: warning: data definition has no type or storage class EI_(ghczmprim_GHCziTypes_TrNameS_con_info); ^~~ | 13 | EI_(ghczmprim_GHCziTypes_TrNameS_con_info); | ^ /tmp/ghca022_0/ghc_3.hc:13:1: error: warning: type defaults to 'int' in declaration of 'EI_' [-Wimplicit- int] | 13 | EI_(ghczmprim_GHCziTypes_TrNameS_con_info); | ^ /tmp/ghca022_0/ghc_3.hc:13:1: error: warning: parameter names (without types) in function declaration | 13 | EI_(ghczmprim_GHCziTypes_TrNameS_con_info); | ^ In file included from /tmp/ghca022_0/ghc_3.hc:3:0: error: /tmp/ghca022_0/ghc_3.hc:14:5: error: error: conflicting types for 'ghc_GhcPrelude_zdtrModule2_bytes' EB_(ghc_GhcPrelude_zdtrModule2_bytes); ^ | 14 | EB_(ghc_GhcPrelude_zdtrModule2_bytes); | ^ includes/Stg.h:236:37: error: note: in definition of macro 'EB_' #define EB_(X) extern const char X[] ^ | 236 | #define EB_(X) extern const char X[] | ^ /tmp/ghca022_0/ghc_3.hc:12:6: error: note: previous definition of 'ghc_GhcPrelude_zdtrModule2_bytes' was here char ghc_GhcPrelude_zdtrModule2_bytes[] = "GhcPrelude"; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 12 | char ghc_GhcPrelude_zdtrModule2_bytes[] = "GhcPrelude"; | ^ /tmp/ghca022_0/ghc_3.hc:16:1: error: error: initializer element is not constant (W_)&ghczmprim_GHCziTypes_TrNameS_con_info, (W_)&ghc_GhcPrelude_zdtrModule2_bytes ^ | 16 | (W_)&ghczmprim_GHCziTypes_TrNameS_con_info, (W_)&ghc_GhcPrelude_zdtrModule2_bytes | ^ /tmp/ghca022_0/ghc_3.hc:16:1: error: note: (near initialization for 'ghc_GhcPrelude_zdtrModule1_closure[0]') | 16 | (W_)&ghczmprim_GHCziTypes_TrNameS_con_info, (W_)&ghc_GhcPrelude_zdtrModule2_bytes | ^ /tmp/ghca022_0/ghc_3.hc:18:1: error: warning: data definition has no type or storage class EI_(ghczmprim_GHCziTypes_Module_con_info); ^~~ | 18 | EI_(ghczmprim_GHCziTypes_Module_con_info); | ^ /tmp/ghca022_0/ghc_3.hc:18:1: error: warning: type defaults to 'int' in declaration of 'EI_' [-Wimplicit- int] | 18 | EI_(ghczmprim_GHCziTypes_Module_con_info); | ^ /tmp/ghca022_0/ghc_3.hc:18:1: error: warning: parameter names (without types) in function declaration | 18 | EI_(ghczmprim_GHCziTypes_Module_con_info); | ^ /tmp/ghca022_0/ghc_3.hc:19:1: error: warning: data definition has no type or storage class EI_(ghc_GhcPrelude_zdtrModule1_closure); ^~~ | 19 | EI_(ghc_GhcPrelude_zdtrModule1_closure); | ^ /tmp/ghca022_0/ghc_3.hc:19:1: error: warning: type defaults to 'int' in declaration of 'EI_' [-Wimplicit- int] | 19 | EI_(ghc_GhcPrelude_zdtrModule1_closure); | ^ /tmp/ghca022_0/ghc_3.hc:19:1: error: warning: parameter names (without types) in function declaration | 19 | EI_(ghc_GhcPrelude_zdtrModule1_closure); | ^ /tmp/ghca022_0/ghc_3.hc:20:1: error: warning: data definition has no type or storage class EI_(ghc_GhcPrelude_zdtrModule3_closure); ^~~ | 20 | EI_(ghc_GhcPrelude_zdtrModule3_closure); | ^ /tmp/ghca022_0/ghc_3.hc:20:1: error: warning: type defaults to 'int' in declaration of 'EI_' [-Wimplicit- int] | 20 | EI_(ghc_GhcPrelude_zdtrModule3_closure); | ^ /tmp/ghca022_0/ghc_3.hc:20:1: error: warning: parameter names (without types) in function declaration | 20 | EI_(ghc_GhcPrelude_zdtrModule3_closure); | ^ /tmp/ghca022_0/ghc_3.hc:22:6: error: error: 'ghczmprim_GHCziTypes_Module_con_info' undeclared here (not in a function); did you mean 'ghczmprim_GHCziTypes_TrNameS_con_info'? (W_)&ghczmprim_GHCziTypes_Module_con_info, ((W_)&ghc_GhcPrelude_zdtrModule3_closure+1), ((W_)&ghc_GhcPrelude_zdtrModule1_closure+1), 0x3U ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ghczmprim_GHCziTypes_TrNameS_con_info | 22 | (W_)&ghczmprim_GHCziTypes_Module_con_info, ((W_)&ghc_GhcPrelude_zdtrModule3_closure+1), ((W_)&ghc_GhcPrelude_zdtrModule1_closure+1), 0x3U | ^ /tmp/ghca022_0/ghc_3.hc:22:1: error: error: initializer element is not constant (W_)&ghczmprim_GHCziTypes_Module_con_info, ((W_)&ghc_GhcPrelude_zdtrModule3_closure+1), ((W_)&ghc_GhcPrelude_zdtrModule1_closure+1), 0x3U ^ | 22 | (W_)&ghczmprim_GHCziTypes_Module_con_info, ((W_)&ghc_GhcPrelude_zdtrModule3_closure+1), ((W_)&ghc_GhcPrelude_zdtrModule1_closure+1), 0x3U | ^ /tmp/ghca022_0/ghc_3.hc:22:1: error: note: (near initialization for 'ghc_GhcPrelude_zdtrModule_closure[0]') | 22 | (W_)&ghczmprim_GHCziTypes_Module_con_info, ((W_)&ghc_GhcPrelude_zdtrModule3_closure+1), ((W_)&ghc_GhcPrelude_zdtrModule1_closure+1), 0x3U | ^ `gcc' failed in phase `C Compiler'. (Exit code: 1) }}} https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=mips&ver=8.4.3-1&stamp=1527757736&raw=0 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 11:49:17 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 11:49:17 -0000 Subject: [GHC] #15205: Unnecessary equality superclass Message-ID: <046.518e1da1aecaf92b89e450640d4328c5@haskell.org> #15205: Unnecessary equality superclass -------------------------------------+------------------------------------- Reporter: simonpj | 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: -------------------------------------+------------------------------------- Consider {{{ {-# LANGUAGE MultiParamTypeClasses, GADTs, TypeOperators #-} module Foo where class (a ~ b) => C a b where op :: a -> a -> b f :: C a b => a -> b f x = op x x }}} If you compile this you'll end up with {{{ f = \ (@ a_a1dk) (@ b_a1dl) ($dC_a1dn :: C a_a1dk b_a1dl) (eta_B1 :: a_a1dk) -> case GHC.Types.heq_sel @ * @ * @ a_a1dk @ b_a1dl ((Foo.$p1C @ a_a1dk @ b_a1dl $dC_a1dn) `cast` (Data.Type.Equality.N:~[0] <*>_N _N _N :: (a_a1dk ~ b_a1dl) ~R# (a_a1dk ~~ b_a1dl))) of co_a1dw { __DEFAULT -> op @ a_a1dk @ b_a1dl $dC_a1dn eta_B1 eta_B1 } }}} What is that unused `heq_sel` doing? It happens during solving * We have `[G] a ~ b` * And, by superclasses we have `[G] a ~# b` * We use this to rewrite `a` to `b` in both givens and wanteds which is all fine, but we end up with {{{ f = \ (@ a_a1dk) (@ b_a1dl) ($dC_a1dn :: C a_a1dk b_a1dl) -> case GHC.Types.heq_sel @ * @ * @ a_a1dk @ b_a1dl (Data.Type.Equality.$p1~ @ * @ a_a1dk @ b_a1dl (Foo.$p1C @ a_a1dk @ b_a1dl $dC_a1dn)) of co_a1dw { __DEFAULT -> \ (x_axX :: a_a1dk) -> op @ a_a1dk @ b_a1dl (($dC_a1dn `cast` ((C co_a1dw _N)_R :: C a_a1dk b_a1dl ~R# C b_a1dl b_a1dl)) `cast` ((C (Sym co_a1dw) _N)_R :: C b_a1dl b_a1dl ~R# C a_a1dk b_a1dl)) x_axX x_axX } }}} Notice that `co_a1dw` is used. But we are just casting and casting back, so it ends up as Refl and `co_a1dw` is unused. Nothing is wrong here, but it seems inelegant * Can we discard that `heq_sel`? Perhaps we can declare that dictionary- valued terms are always treated strictly (#2439), so that `(heq_sel ...)` is guaranteed non-bottom, and we can discard the case. * Or maybe we can expand the given superclasses less aggressively, so that the equality isn't exposed until necessary. But see `Note [Eagerly expand given superclasses]` in `TcCanonical`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 13:38:16 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 13:38:16 -0000 Subject: [GHC] #15204: GHC 8.4 fails to build on Debian mips In-Reply-To: <044.1e90470ed0277ec2b851547a09b463cc@haskell.org> References: <044.1e90470ed0277ec2b851547a09b463cc@haskell.org> Message-ID: <059.88d5fb96487150bf7b097a5e5061ad38@haskell.org> #15204: GHC 8.4 fails to build on Debian mips -------------------------------------+------------------------------ Reporter: clint | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: mips Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15201 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------ Changes (by bgamari): * status: new => closed * resolution: => duplicate * related: => #15201 Comment: Thanks for reporting these! Looks like the same issue as #15201. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 15:10:11 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 15:10:11 -0000 Subject: [GHC] #15076: Typed hole with higher-rank kind causes GHC to panic (No skolem info) In-Reply-To: <050.9e6ebeaf2e39bca10b356bf245888851@haskell.org> References: <050.9e6ebeaf2e39bca10b356bf245888851@haskell.org> Message-ID: <065.2e10898368198006b719224d47b6da3a@haskell.org> #15076: Typed hole with higher-rank kind causes GHC to panic (No skolem info) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.2.2 checker) | Keywords: TypedHoles, Resolution: | TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14040, #14880 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Another example of this bug, discovered in https://github.com/goldfirere/ghc/issues/57 : {{{#!hs {-# LANGUAGE PolyKinds, MultiParamTypeClasses, GADTs, ScopedTypeVariables, TypeOperators #-} {-# OPTIONS_GHC -fno-warn-redundant-constraints #-} module Super where import Data.Proxy import GHC.Prim class (a ~ b) => C a b data SameKind :: k -> k -> * where SK :: SameKind a b bar :: forall (a :: *) (b :: *). C a b => Proxy a -> Proxy b -> () bar _ _ = const () (undefined :: forall (x :: a) (y :: b). SameKind x y) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 15:29:20 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 15:29:20 -0000 Subject: [GHC] #15200: RFC: export WordPtr from Data.Word and IntPtr from Data.Int rather than only from Foreign.Ptr In-Reply-To: <045.4b1c2629d5a6a22d28611cace837aebd@haskell.org> References: <045.4b1c2629d5a6a22d28611cace837aebd@haskell.org> Message-ID: <060.e86ea0434182c7b3f28e57b0292e47cf@haskell.org> #15200: RFC: export WordPtr from Data.Word and IntPtr from Data.Int rather than only from Foreign.Ptr -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I can't comment about Haskell 2020, but it seems quite reasonable to reexport `IntPtr` and `WordPtr` from `Data.Int` and `Data.Word`, respectively. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 15:31:54 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 15:31:54 -0000 Subject: [GHC] #14310: Assertion triggered by STM invariant. In-Reply-To: <042.9c3fac38bbd2247bedc1f2616e6e2820@haskell.org> References: <042.9c3fac38bbd2247bedc1f2616e6e2820@haskell.org> Message-ID: <057.7a10a49305ac6c4f4a1ece8a5bbe0066@haskell.org> #14310: Assertion triggered by STM invariant. -------------------------------------+------------------------------------- Reporter: mbw | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4065, Wiki Page: | Phab:D4067, Phab:D4073, Phab:D4760 -------------------------------------+------------------------------------- Changes (by bgamari): * differential: Phab:D4065, Phab:D4067, Phab:D4073 => Phab:D4065, Phab:D4067, Phab:D4073, Phab:D4760 Comment: I carry out the removal (almost entirely taken from a patch by fryguybob) in Phab:D4760. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 15:33:07 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 15:33:07 -0000 Subject: [GHC] #14963: ghci -fdefer-type-errors can't run IO action from another module In-Reply-To: <047.c258bd8a8d43881f32b193f6cbfcf8f0@haskell.org> References: <047.c258bd8a8d43881f32b193f6cbfcf8f0@haskell.org> Message-ID: <062.f30f8f8846ea83ee3a3a0493d21741e7@haskell.org> #14963: ghci -fdefer-type-errors can't run IO action from another module -------------------------------------+------------------------------------- Reporter: elaforge | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.4.2 Component: GHCi | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by tdammers): * owner: (none) => tdammers -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 15:38:59 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 15:38:59 -0000 Subject: [GHC] #15206: Strictness annotations bind more tightly than doc strings on non-record data declarations Message-ID: <050.d27d0e7d2edeaad12b554d4fccd90f3f@haskell.org> #15206: Strictness annotations bind more tightly than doc strings on non-record data declarations -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D4727 | Wiki Page: -------------------------------------+------------------------------------- Consider the following declaration: {{{#!hs data Point = Point -- ^ a 2D point !Int -- ^ x coord !Int -- ^ y coord }}} With `-haddock` enabled, the first field parses as {{{ ({ bad.hs:2:16-32 } (HsDocTy ({ bad.hs:2:16-19 } (HsBangTy (HsSrcBang (NoSourceText) (NoSrcUnpack) (SrcStrict)) ({ bad.hs:2:17-19 } (HsTyVar (NotPromoted) ({ bad.hs:2:17-19 } (Unqual {OccName: Int})))))) ({ bad.hs:2:21-32 } (HsDocString {FastString: " x coord"})))) }}} However, this is incorrect since further down the compilation pipeline, strictness and unpackedness annotations are only looked for at the top- level of a field (meaning the above example hits the `strictness annotation cannot appear nested inside a type` error). We want this instead: {{{ ({ bad.hs:2:16-32 } (HsBangTy (NoExt) (HsSrcBang (NoSourceText) (NoSrcUnpack) (SrcStrict)) ({ bad.hs:2:17-32 } (HsDocTy (NoExt) ({ bad.hs:2:17-19 } (HsTyVar (NoExt) (NotPromoted) ({ bad.hs:2:17-19 } (Unqual {OccName: Int})))) ({ bad.hs:2:21-32 } (HsDocString {FastString: " x coord"})))))) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 15:47:14 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 15:47:14 -0000 Subject: [GHC] #14310: Assertion triggered by STM invariant. In-Reply-To: <042.9c3fac38bbd2247bedc1f2616e6e2820@haskell.org> References: <042.9c3fac38bbd2247bedc1f2616e6e2820@haskell.org> Message-ID: <057.23195cef9119f1b460fe099473de756e@haskell.org> #14310: Assertion triggered by STM invariant. -------------------------------------+------------------------------------- Reporter: mbw | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #14324 | Differential Rev(s): Phab:D4065, Wiki Page: | Phab:D4067, Phab:D4073, Phab:D4760 -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * related: => #14324 Comment: Removal is being track in #14234. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 15:47:51 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 15:47:51 -0000 Subject: [GHC] #14324: Consider deprecating STM invariant mechanism In-Reply-To: <046.7d9457872c0d5f0243f1b38705442b7b@haskell.org> References: <046.7d9457872c0d5f0243f1b38705442b7b@haskell.org> Message-ID: <061.4a1789ddc542b1b92c8fbc8df0ddaaee@haskell.org> #14324: Consider deprecating STM invariant mechanism -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14310 | Differential Rev(s): Phab:D4372, Wiki Page: | Phab:D4760 -------------------------------------+------------------------------------- Changes (by bgamari): * status: closed => new * differential: Phab:D4372 => Phab:D4372, Phab:D4760 * resolution: fixed => * related: => #14310 Comment: We will follow-through with removal in 8.6.1. I've done this in Phab:D4760. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 15:49:15 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 15:49:15 -0000 Subject: [GHC] #14990: "Valid refinement suggestions" have the wrong types In-Reply-To: <047.1377e2f34a2eeac1354152d47898fe0b@haskell.org> References: <047.1377e2f34a2eeac1354152d47898fe0b@haskell.org> Message-ID: <062.4fb02df2743e80888c13bfb383279cb0@haskell.org> #14990: "Valid refinement suggestions" have the wrong types -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Tritlo Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4444 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Tritlo): Yes, this has been fixed with e0b44e2/ghc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 15:52:18 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 15:52:18 -0000 Subject: [GHC] #15200: RFC: export WordPtr from Data.Word and IntPtr from Data.Int rather than only from Foreign.Ptr In-Reply-To: <045.4b1c2629d5a6a22d28611cace837aebd@haskell.org> References: <045.4b1c2629d5a6a22d28611cace837aebd@haskell.org> Message-ID: <060.7d528d2586239a10fdffd4259cb2444f@haskell.org> #15200: RFC: export WordPtr from Data.Word and IntPtr from Data.Int rather than only from Foreign.Ptr -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): (my context wrt h2020 is that i'm on that committee, but good to hear positive feedback from the libraries committee) once i get master in better shape locally, i'll throw a patch up on phab -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 15:52:24 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 15:52:24 -0000 Subject: [GHC] #15142: GHC HEAD regression: tcTyVarDetails In-Reply-To: <050.e98a1ae073f44bf5c57814edebb43575@haskell.org> References: <050.e98a1ae073f44bf5c57814edebb43575@haskell.org> Message-ID: <065.5fe1413981ddb0bc884794a0415284e9@haskell.org> #15142: GHC HEAD regression: tcTyVarDetails -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: TypeInType, Resolution: | TypeFamilies, CUSKs Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: (none) => goldfire -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 15:59:06 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 15:59:06 -0000 Subject: [GHC] #15084: Functions in HsUtils don't have the most general type In-Reply-To: <049.1109509c094efe6039ffa43e90f3661d@haskell.org> References: <049.1109509c094efe6039ffa43e90f3661d@haskell.org> Message-ID: <064.7a8caa28856dfd6ba2f5a7551ee790bd@haskell.org> #15084: Functions in HsUtils don't have the most general type -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): We should try to sort this out. Alanz, is Matthew's suggested type okay with you? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 16:05:41 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 16:05:41 -0000 Subject: [GHC] #15084: Functions in HsUtils don't have the most general type In-Reply-To: <049.1109509c094efe6039ffa43e90f3661d@haskell.org> References: <049.1109509c094efe6039ffa43e90f3661d@haskell.org> Message-ID: <064.573435d211219224167b1bb1c61f1a62@haskell.org> #15084: Functions in HsUtils don't have the most general type -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alanz): Yes, I am fine with this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 16:10:36 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 16:10:36 -0000 Subject: [GHC] #14381: Consider making ghc-pkg fill in abi-depends based on depends In-Reply-To: <045.a757b4d974e51bd6ab6f6869ba65de4c@haskell.org> References: <045.a757b4d974e51bd6ab6f6869ba65de4c@haskell.org> Message-ID: <060.87598e51e8340f2fddeb0b1556b317c1@haskell.org> #14381: Consider making ghc-pkg fill in abi-depends based on depends -------------------------------------+------------------------------------- Reporter: ezyang | Owner: tdammers Type: bug | Status: patch Priority: highest | Milestone: 8.4.3 Component: ghc-pkg | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4159 Wiki Page: | Phab:D4729 -------------------------------------+------------------------------------- Comment (by bgamari): Phab:D4159 has been merged to GHC 8.4.3 as a stop-gap with 51abb1c88b53e2989a2a8c2939ac4abc04bef194. We will merge the more sensible Phab:D4729 to `master` shortly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 16:13:24 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 16:13:24 -0000 Subject: [GHC] #7411: Exceptions are optimized away in certain situations In-Reply-To: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> References: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> Message-ID: <065.3ac91386fafc1ff935b570cd32c5ac7c@haskell.org> #7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): As I said on IRC, we should have `nofib` numbers at least. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 16:14:29 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 16:14:29 -0000 Subject: [GHC] #14990: "Valid refinement suggestions" have the wrong types In-Reply-To: <047.1377e2f34a2eeac1354152d47898fe0b@haskell.org> References: <047.1377e2f34a2eeac1354152d47898fe0b@haskell.org> Message-ID: <062.fadf9c37efdac2e38ff8a88b6476181c@haskell.org> #14990: "Valid refinement suggestions" have the wrong types -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Tritlo Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4444 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 16:20:25 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 16:20:25 -0000 Subject: [GHC] #15084: Functions in HsUtils don't have the most general type In-Reply-To: <049.1109509c094efe6039ffa43e90f3661d@haskell.org> References: <049.1109509c094efe6039ffa43e90f3661d@haskell.org> Message-ID: <064.f9675872de81fe8f67c57525e5494b41@haskell.org> #15084: Functions in HsUtils don't have the most general type -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Yikes, there are a lot of these. Do we really want to generalize everything in this module? These constraints are going to get quite noisy. Yuck. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 17:06:41 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 17:06:41 -0000 Subject: [GHC] #8095: TypeFamilies painfully slow In-Reply-To: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> References: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> Message-ID: <065.377f0901551aa118e16655b4fcb9875e@haskell.org> #8095: TypeFamilies painfully slow -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5321, #11598, | Differential Rev(s): Phab:D3752 #12506, #13386 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): According to my understanding, this should be reasonably straightforward: Introduce a placeholder `Coercion` variety which tracks the types, role, and free variables of the coercion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 17:13:58 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 17:13:58 -0000 Subject: [GHC] #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) Message-ID: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) ----------------------------------------+--------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.3 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- for current master, if i build on a mac / OSX high sierra environment with CC set as any flavor of recent GCC rather than apple clang, i get a failure "no open frame" when as (aka apple clang / apple llvm acting as the assembler) is run on the .s file produced by stgRun.c (rts/StgCRun.c to be exact) this error message seems to come from https://github.com/llvm- mirror/llvm/blob/da4a2839d80ac52958be0129b871beedfe90136e/lib/MC/MCStreamer.cpp#L221 https://gist.github.com/cartazio/8cbfb3305e1daa4f7ffc3f6bb90a2891 has the gcc and clang style assembly for /usr/local/bin/gcc-8 -fno-stack-protector -DTABLES_NEXT_TO_CODE -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist- ghcconstants/header -Irts -Irts/dist/build -Irts/dist/build -Irts/dist/build/./autogen -fno-common -U__PIC__ -D__PIC__ -x assembler -c /var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T/ghc22029_0/ghc_1.s -o rts/dist/build/StgCRun.debug_o this is example asm for the the debug way -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 17:29:08 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 17:29:08 -0000 Subject: [GHC] #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) In-Reply-To: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> References: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> Message-ID: <060.6b2d883e70f0b66de2c2bd89e32fc9ea@haskell.org> #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): i'm not sure if the issue is apple llvm/as being conservative in verifying the embedded dwarf or not, nor if more recent clang doesn't have that issue -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 17:32:01 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 17:32:01 -0000 Subject: [GHC] #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) In-Reply-To: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> References: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> Message-ID: <060.aa62531436a569f9b0f6571ac0b9a948@haskell.org> #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: niteria (added) Old description: > for current master, if i build on a mac / OSX high sierra environment > with CC set as any flavor of recent GCC rather than apple clang, i get a > failure "no open frame" when as (aka apple clang / apple llvm acting as > the assembler) is run on the .s file produced by stgRun.c (rts/StgCRun.c > to be exact) > > this error message seems to come from https://github.com/llvm- > mirror/llvm/blob/da4a2839d80ac52958be0129b871beedfe90136e/lib/MC/MCStreamer.cpp#L221 > > https://gist.github.com/cartazio/8cbfb3305e1daa4f7ffc3f6bb90a2891 has > the gcc and clang style assembly for > > /usr/local/bin/gcc-8 -fno-stack-protector -DTABLES_NEXT_TO_CODE > -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header > -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build > -Irts/dist/build -Irts/dist/build/./autogen -fno-common -U__PIC__ > -D__PIC__ -x assembler -c > /var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T/ghc22029_0/ghc_1.s -o > rts/dist/build/StgCRun.debug_o > > this is example asm for the the debug way New description: for current master, if i build on a mac / OSX high sierra environment with CC set as any flavor of recent GCC rather than apple clang, i get a failure `no open frame` when as (aka apple clang / apple llvm acting as the assembler) is run on the `.s` file produced by `stgRun.c` (`rts/StgCRun.c` to be exact) this error message seems to come from https://github.com/llvm- mirror/llvm/blob/da4a2839d80ac52958be0129b871beedfe90136e/lib/MC/MCStreamer.cpp#L221 https://gist.github.com/cartazio/8cbfb3305e1daa4f7ffc3f6bb90a2891 has the gcc and clang style assembly for {{{ /usr/local/bin/gcc-8 -fno-stack-protector -DTABLES_NEXT_TO_CODE -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist- ghcconstants/header -Irts -Irts/dist/build -Irts/dist/build -Irts/dist/build/./autogen -fno-common -U__PIC__ -D__PIC__ -x assembler -c /var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T/ghc22029_0/ghc_1.s -o rts/dist/build/StgCRun.debug_o }}} this is example asm for the the debug way -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 17:33:02 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 17:33:02 -0000 Subject: [GHC] #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) In-Reply-To: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> References: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> Message-ID: <060.706242d4289dfa3a3bbf6ea61ab37f46@haskell.org> #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by carter): * cc: niteria (removed) Old description: > for current master, if i build on a mac / OSX high sierra environment > with CC set as any flavor of recent GCC rather than apple clang, i get a > failure `no open frame` when as (aka apple clang / apple llvm acting as > the assembler) is run on the `.s` file produced by `stgRun.c` > (`rts/StgCRun.c` to be exact) > > this error message seems to come from https://github.com/llvm- > mirror/llvm/blob/da4a2839d80ac52958be0129b871beedfe90136e/lib/MC/MCStreamer.cpp#L221 > > https://gist.github.com/cartazio/8cbfb3305e1daa4f7ffc3f6bb90a2891 has > the gcc and clang style assembly for > {{{ > /usr/local/bin/gcc-8 -fno-stack-protector -DTABLES_NEXT_TO_CODE > -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header > -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build > -Irts/dist/build -Irts/dist/build/./autogen -fno-common -U__PIC__ > -D__PIC__ -x assembler -c > /var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T/ghc22029_0/ghc_1.s -o > rts/dist/build/StgCRun.debug_o > }}} > this is example asm for the the debug way New description: for current master, if i build on a mac / OSX high sierra environment with CC set as any flavor of recent GCC rather than apple clang, i get a failure "no open frame" when as (aka apple clang / apple llvm acting as the assembler) is run on the .s file produced by stgRun.c (rts/StgCRun.c to be exact) this error message seems to come from https://github.com/llvm- mirror/llvm/blob/da4a2839d80ac52958be0129b871beedfe90136e/lib/MC/MCStreamer.cpp#L221 https://gist.github.com/cartazio/8cbfb3305e1daa4f7ffc3f6bb90a2891 has the gcc and clang style assembly for /usr/local/bin/gcc-8 -fno-stack-protector -DTABLES_NEXT_TO_CODE -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist- ghcconstants/header -Irts -Irts/dist/build -Irts/dist/build -Irts/dist/build/./autogen -fno-common -U__PIC__ -D__PIC__ -x assembler -c /var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T/ghc22029_0/ghc_1.s -o rts/dist/build/StgCRun.debug_o this is example asm for the the debug way -- Comment: or if asm with dwarf as emitted by GCC doesn't play nice with (apple?)clang's assembler (which is the system assembler on OSX high sierra) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 17:34:55 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 17:34:55 -0000 Subject: [GHC] #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) In-Reply-To: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> References: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> Message-ID: <060.eceea7b1f3dcb2c99deffb888987d3cf@haskell.org> #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by carter): * cc: niteria (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 17:42:47 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 17:42:47 -0000 Subject: [GHC] #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) In-Reply-To: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> References: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> Message-ID: <060.95efef31efee7431f25713f161502438@haskell.org> #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): filed radar 40690578 on the apple side in case this unique to apple's flavor of clang / llvm / as -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 17:49:33 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 17:49:33 -0000 Subject: [GHC] #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) In-Reply-To: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> References: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> Message-ID: <060.d2bb9507e422118508a0ef66d592216a@haskell.org> #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Do you think you could paste the assembler produced by compiling the following program with `clang -g -O0`? {{{#!c #include int hello(int a, double b) { printf("hello %d %d", 42, 12); return a*b; } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 18:19:27 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 18:19:27 -0000 Subject: [GHC] #15105: `typecheckModule` from GHC API crashes on MacOS for files with TH In-Reply-To: <050.a57b50b77df5fd7c6386ac1485c8460f@haskell.org> References: <050.a57b50b77df5fd7c6386ac1485c8460f@haskell.org> Message-ID: <065.1b8e1b48dae0c76d525b70233837779b@haskell.org> #15105: `typecheckModule` from GHC API crashes on MacOS for files with TH ----------------------------------+---------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHC API | Version: 8.4.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+---------------------------------------- Comment (by simonmic): Also confirmed, I can run doctests again and don't yet see the ill effects from {{{ ~$ locate HSinteger-gmp-1.0.2.0.o /Users/simon/.stack/programs/x86_64-osx/ghc-8.4.2/lib/ghc-8.4.2/integer- gmp-1.0.2.0/HSinteger-gmp-1.0.2.0.o ~$ mv /Users/simon/.stack/programs/x86_64-osx/ghc-8.4.2/lib/ghc-8.4.2 /integer-gmp-1.0.2.0/HSinteger-gmp-1.0.2.0.o{,_DISABLE_GHC_ISSUE_15105} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 18:57:32 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 18:57:32 -0000 Subject: [GHC] #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) In-Reply-To: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> References: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> Message-ID: <060.1dad86b6004c374abc9e6f3d525d67e1@haskell.org> #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): here you go {{{ .section __TEXT,__text,regular,pure_instructions .macosx_version_min 10, 13 .globl _hello ## -- Begin function hello .p2align 4, 0x90 _hello: ## @hello Lfunc_begin0: .file 1 "test.c" .loc 1 3 0 ## test.c:3:0 .cfi_startproc ## BB#0: pushq %rbp Lcfi0: .cfi_def_cfa_offset 16 Lcfi1: .cfi_offset %rbp, -16 movq %rsp, %rbp Lcfi2: .cfi_def_cfa_register %rbp subq $32, %rsp leaq L_.str(%rip), %rax movl $42, %esi movl $12, %edx movl %edi, -4(%rbp) movsd %xmm0, -16(%rbp) Ltmp0: .loc 1 4 5 prologue_end ## test.c:4:5 movq %rax, %rdi movb $0, %al callq _printf .loc 1 5 12 ## test.c:5:12 cvtsi2sdl -4(%rbp), %xmm0 .loc 1 5 13 is_stmt 0 ## test.c:5:13 mulsd -16(%rbp), %xmm0 .loc 1 5 12 ## test.c:5:12 cvttsd2si %xmm0, %edx .loc 1 5 5 ## test.c:5:5 movl %eax, -20(%rbp) ## 4-byte Spill movl %edx, %eax addq $32, %rsp popq %rbp retq Ltmp1: Lfunc_end0: .cfi_endproc ## -- End function .section __TEXT,__cstring,cstring_literals L_.str: ## @.str .asciz "hello %d %d" .section __DWARF,__debug_str,regular,debug Linfo_string: .asciz "Apple LLVM version 9.1.0 (clang-902.0.39.1)" ## string offset=0 .asciz "test.c" ## string offset=44 .asciz "/Users/carter/WorkSpace/projects/active/ghc-head-may2018 -clang-sad" ## string offset=51 .asciz "hello" ## string offset=118 .asciz "int" ## string offset=124 .asciz "a" ## string offset=128 .asciz "b" ## string offset=130 .asciz "double" ## string offset=132 .section __DWARF,__debug_abbrev,regular,debug Lsection_abbrev: .byte 1 ## Abbreviation Code .byte 17 ## DW_TAG_compile_unit .byte 1 ## DW_CHILDREN_yes .byte 37 ## DW_AT_producer .byte 14 ## DW_FORM_strp .byte 19 ## DW_AT_language .byte 5 ## DW_FORM_data2 .byte 3 ## DW_AT_name .byte 14 ## DW_FORM_strp .byte 16 ## DW_AT_stmt_list .byte 23 ## DW_FORM_sec_offset .byte 27 ## DW_AT_comp_dir .byte 14 ## DW_FORM_strp .byte 17 ## DW_AT_low_pc .byte 1 ## DW_FORM_addr .byte 18 ## DW_AT_high_pc .byte 6 ## DW_FORM_data4 .byte 0 ## EOM(1) .byte 0 ## EOM(2) .byte 2 ## Abbreviation Code .byte 46 ## DW_TAG_subprogram .byte 1 ## DW_CHILDREN_yes .byte 17 ## DW_AT_low_pc .byte 1 ## DW_FORM_addr .byte 18 ## DW_AT_high_pc .byte 6 ## DW_FORM_data4 .byte 64 ## DW_AT_frame_base .byte 24 ## DW_FORM_exprloc .byte 3 ## DW_AT_name .byte 14 ## DW_FORM_strp .byte 58 ## DW_AT_decl_file .byte 11 ## DW_FORM_data1 .byte 59 ## DW_AT_decl_line .byte 11 ## DW_FORM_data1 .byte 39 ## DW_AT_prototyped .byte 25 ## DW_FORM_flag_present .byte 73 ## DW_AT_type .byte 19 ## DW_FORM_ref4 .byte 63 ## DW_AT_external .byte 25 ## DW_FORM_flag_present .byte 0 ## EOM(1) .byte 0 ## EOM(2) .byte 3 ## Abbreviation Code .byte 5 ## DW_TAG_formal_parameter .byte 0 ## DW_CHILDREN_no .byte 2 ## DW_AT_location .byte 24 ## DW_FORM_exprloc .byte 3 ## DW_AT_name .byte 14 ## DW_FORM_strp .byte 58 ## DW_AT_decl_file .byte 11 ## DW_FORM_data1 .byte 59 ## DW_AT_decl_line .byte 11 ## DW_FORM_data1 .byte 73 ## DW_AT_type .byte 19 ## DW_FORM_ref4 .byte 0 ## EOM(1) .byte 0 ## EOM(2) .byte 4 ## Abbreviation Code .byte 36 ## DW_TAG_base_type .byte 0 ## DW_CHILDREN_no .byte 3 ## DW_AT_name .byte 14 ## DW_FORM_strp .byte 62 ## DW_AT_encoding .byte 11 ## DW_FORM_data1 .byte 11 ## DW_AT_byte_size .byte 11 ## DW_FORM_data1 .byte 0 ## EOM(1) .byte 0 ## EOM(2) .byte 0 ## EOM(3) .section __DWARF,__debug_info,regular,debug Lsection_info: Lcu_begin0: .long 107 ## Length of Unit .short 4 ## DWARF version number Lset0 = Lsection_abbrev-Lsection_abbrev ## Offset Into Abbrev. Section .long Lset0 .byte 8 ## Address Size (in bytes) .byte 1 ## Abbrev [1] 0xb:0x64 DW_TAG_compile_unit .long 0 ## DW_AT_producer .short 12 ## DW_AT_language .long 44 ## DW_AT_name Lset1 = Lline_table_start0-Lsection_line ## DW_AT_stmt_list .long Lset1 .long 51 ## DW_AT_comp_dir .quad Lfunc_begin0 ## DW_AT_low_pc Lset2 = Lfunc_end0-Lfunc_begin0 ## DW_AT_high_pc .long Lset2 .byte 2 ## Abbrev [2] 0x2a:0x36 DW_TAG_subprogram .quad Lfunc_begin0 ## DW_AT_low_pc Lset3 = Lfunc_end0-Lfunc_begin0 ## DW_AT_high_pc .long Lset3 .byte 1 ## DW_AT_frame_base .byte 86 .long 118 ## DW_AT_name .byte 1 ## DW_AT_decl_file .byte 3 ## DW_AT_decl_line ## DW_AT_prototyped .long 96 ## DW_AT_type ## DW_AT_external .byte 3 ## Abbrev [3] 0x43:0xe DW_TAG_formal_parameter .byte 2 ## DW_AT_location .byte 145 .byte 124 .long 128 ## DW_AT_name .byte 1 ## DW_AT_decl_file .byte 3 ## DW_AT_decl_line .long 96 ## DW_AT_type .byte 3 ## Abbrev [3] 0x51:0xe DW_TAG_formal_parameter .byte 2 ## DW_AT_location .byte 145 .byte 112 .long 130 ## DW_AT_name .byte 1 ## DW_AT_decl_file .byte 3 ## DW_AT_decl_line .long 103 ## DW_AT_type .byte 0 ## End Of Children Mark .byte 4 ## Abbrev [4] 0x60:0x7 DW_TAG_base_type .long 124 ## DW_AT_name .byte 5 ## DW_AT_encoding .byte 4 ## DW_AT_byte_size .byte 4 ## Abbrev [4] 0x67:0x7 DW_TAG_base_type .long 132 ## DW_AT_name .byte 4 ## DW_AT_encoding .byte 8 ## DW_AT_byte_size .byte 0 ## End Of Children Mark .section __DWARF,__debug_ranges,regular,debug Ldebug_range: .section __DWARF,__debug_macinfo,regular,debug Ldebug_macinfo: Lcu_macro_begin0: .byte 0 ## End Of Macro List Mark .section __DWARF,__apple_names,regular,debug Lnames_begin: .long 1212240712 ## Header Magic .short 1 ## Header Version .short 0 ## Header Hash Function .long 1 ## Header Bucket Count .long 1 ## Header Hash Count .long 12 ## Header Data Length .long 0 ## HeaderData Die Offset Base .long 1 ## HeaderData Atom Count .short 1 ## DW_ATOM_die_offset .short 6 ## DW_FORM_data4 .long 0 ## Bucket 0 .long 261238937 ## Hash in Bucket 0 .long LNames0-Lnames_begin ## Offset in Bucket 0 LNames0: .long 118 ## hello .long 1 ## Num DIEs .long 42 .long 0 .section __DWARF,__apple_objc,regular,debug Lobjc_begin: .long 1212240712 ## Header Magic .short 1 ## Header Version .short 0 ## Header Hash Function .long 1 ## Header Bucket Count .long 0 ## Header Hash Count .long 12 ## Header Data Length .long 0 ## HeaderData Die Offset Base .long 1 ## HeaderData Atom Count .short 1 ## DW_ATOM_die_offset .short 6 ## DW_FORM_data4 .long -1 ## Bucket 0 .section __DWARF,__apple_namespac,regular,debug Lnamespac_begin: .long 1212240712 ## Header Magic .short 1 ## Header Version .short 0 ## Header Hash Function .long 1 ## Header Bucket Count .long 0 ## Header Hash Count .long 12 ## Header Data Length .long 0 ## HeaderData Die Offset Base .long 1 ## HeaderData Atom Count .short 1 ## DW_ATOM_die_offset .short 6 ## DW_FORM_data4 .long -1 ## Bucket 0 .section __DWARF,__apple_types,regular,debug Ltypes_begin: .long 1212240712 ## Header Magic .short 1 ## Header Version .short 0 ## Header Hash Function .long 2 ## Header Bucket Count .long 2 ## Header Hash Count .long 20 ## Header Data Length .long 0 ## HeaderData Die Offset Base .long 3 ## HeaderData Atom Count .short 1 ## DW_ATOM_die_offset .short 6 ## DW_FORM_data4 .short 3 ## DW_ATOM_die_tag .short 5 ## DW_FORM_data2 .short 4 ## DW_ATOM_type_flags .short 11 ## DW_FORM_data1 .long 0 ## Bucket 0 .long -1 ## Bucket 1 .long 193495088 ## Hash in Bucket 0 .long -113419488 ## Hash in Bucket 0 .long Ltypes0-Ltypes_begin ## Offset in Bucket 0 .long Ltypes1-Ltypes_begin ## Offset in Bucket 0 Ltypes0: .long 124 ## int .long 1 ## Num DIEs .long 96 .short 36 .byte 0 .long 0 Ltypes1: .long 132 ## double .long 1 ## Num DIEs .long 103 .short 36 .byte 0 .long 0 .subsections_via_symbols .section __DWARF,__debug_line,regular,debug Lsection_line: Lline_table_start0: }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 20:49:10 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 20:49:10 -0000 Subject: [GHC] #14381: Consider making ghc-pkg fill in abi-depends based on depends In-Reply-To: <045.a757b4d974e51bd6ab6f6869ba65de4c@haskell.org> References: <045.a757b4d974e51bd6ab6f6869ba65de4c@haskell.org> Message-ID: <060.c69dbdc05d3def0b2710577ab122848e@haskell.org> #14381: Consider making ghc-pkg fill in abi-depends based on depends -------------------------------------+------------------------------------- Reporter: ezyang | Owner: tdammers Type: bug | Status: patch Priority: highest | Milestone: 8.4.3 Component: ghc-pkg | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4159 Wiki Page: | Phab:D4729 -------------------------------------+------------------------------------- Comment (by phadej): The warning is indeed noisy, and gives an impression cabal-install (or GHC-8.4.3) is broken. I'd hope for 8.4.4 with a proper fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 21:02:17 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 21:02:17 -0000 Subject: [GHC] #15208: GHC 8.4 fails to build on Debian armel (softfloat) Message-ID: <044.485dae4c163d04b201fd244d05e7bdd0@haskell.org> #15208: GHC 8.4 fails to build on Debian armel (softfloat) --------------------------------+--------------------------------- Reporter: clint | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Linux Architecture: arm | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+--------------------------------- This seems intentional but on the other hand the error message says "Please report this as a GHC bug" {{{ "inplace/bin/ghc-stage1" -static -H32m -O -lffi -optl-pthread -optl-B/usr/bin/ld.gold -Wall -Iincludes -Iincludes/dist -Iincludes /dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -optc-DNOSMP -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical- monad-instances -c rts/StgStartup.cmm -o rts/dist/build/StgStartup.o "inplace/bin/ghc-stage1" -static -H32m -O -lffi -optl-pthread -optl-B/usr/bin/ld.gold -Wall -Iincludes -Iincludes/dist -Iincludes /dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -optc-DNOSMP -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical- monad-instances -c rts/PrimOps.cmm -o rts/dist/build/PrimOps.o "inplace/bin/ghc-stage1" -static -H32m -O -lffi -optl-pthread -optl-B/usr/bin/ld.gold -Wall -Iincludes -Iincludes/dist -Iincludes /dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -optc-DNOSMP -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical- monad-instances -c rts/Updates.cmm -o rts/dist/build/Updates.o ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.4.3 for arm-unknown-linux): Failed to lookup the datalayout for armv7l-unknown-linux-gnueabi; available targets: ["i386-unknown-windows","i686-unknown-windows","x86_64 -unknown-windows","arm-unknown-linux-gnueabihf","armv6-unknown-linux- gnueabihf","armv6l-unknown-linux-gnueabihf","armv7-unknown-linux-gnueabihf ","armv7a-unknown-linux-gnueabi","armv7l-unknown-linux-gnueabihf","aarch64 -unknown-linux-gnu","aarch64-unknown-linux","i386-unknown-linux-gnu","i386 -unknown-linux","x86_64-unknown-linux-gnu","x86_64-unknown-linux","armv7 -unknown-linux-androideabi","aarch64-unknown-linux-android","arm-unknown- nto-qnx-eabi","i386-apple-darwin","x86_64-apple-darwin","armv7-apple- ios","aarch64-apple-ios","i386-apple-ios","x86_64-apple-ios"] CallStack (from HasCallStack): error, called at compiler/llvmGen/LlvmCodeGen.hs:96:24 in ghc:LlvmCodeGen Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug rts/ghc.mk:295: recipe for target 'rts/dist/build/StgStartup.o' failed make[3]: *** [rts/dist/build/StgStartup.o] Error 1 make[3]: *** Waiting for unfinished jobs.... ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.4.3 for arm-unknown-linux): Failed to lookup the datalayout for armv7l-unknown-linux-gnueabi; available targets: ["i386-unknown-windows","i686-unknown-windows","x86_64 -unknown-windows","arm-unknown-linux-gnueabihf","armv6-unknown-linux- gnueabihf","armv6l-unknown-linux-gnueabihf","armv7-unknown-linux-gnueabihf ","armv7a-unknown-linux-gnueabi","armv7l-unknown-linux-gnueabihf","aarch64 -unknown-linux-gnu","aarch64-unknown-linux","i386-unknown-linux-gnu","i386 -unknown-linux","x86_64-unknown-linux-gnu","x86_64-unknown-linux","armv7 -unknown-linux-androideabi","aarch64-unknown-linux-android","arm-unknown- nto-qnx-eabi","i386-apple-darwin","x86_64-apple-darwin","armv7-apple- ios","aarch64-apple-ios","i386-apple-ios","x86_64-apple-ios"] CallStack (from HasCallStack): error, called at compiler/llvmGen/LlvmCodeGen.hs:96:24 in ghc:LlvmCodeGen Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug rts/ghc.mk:295: recipe for target 'rts/dist/build/Updates.o' failed make[3]: *** [rts/dist/build/Updates.o] Error 1 ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.4.3 for arm-unknown-linux): Failed to lookup the datalayout for armv7l-unknown-linux-gnueabi; available targets: ["i386-unknown-windows","i686-unknown-windows","x86_64 -unknown-windows","arm-unknown-linux-gnueabihf","armv6-unknown-linux- gnueabihf","armv6l-unknown-linux-gnueabihf","armv7-unknown-linux-gnueabihf ","armv7a-unknown-linux-gnueabi","armv7l-unknown-linux-gnueabihf","aarch64 -unknown-linux-gnu","aarch64-unknown-linux","i386-unknown-linux-gnu","i386 -unknown-linux","x86_64-unknown-linux-gnu","x86_64-unknown-linux","armv7 -unknown-linux-androideabi","aarch64-unknown-linux-android","arm-unknown- nto-qnx-eabi","i386-apple-darwin","x86_64-apple-darwin","armv7-apple- ios","aarch64-apple-ios","i386-apple-ios","x86_64-apple-ios"] CallStack (from HasCallStack): error, called at compiler/llvmGen/LlvmCodeGen.hs:96:24 in ghc:LlvmCodeGen Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug rts/ghc.mk:295: recipe for target 'rts/dist/build/PrimOps.o' failed }}} https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=armel&ver=8.4.3-1&stamp=1527769922&raw=0 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 21:33:01 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 21:33:01 -0000 Subject: [GHC] #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) In-Reply-To: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> References: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> Message-ID: <060.9e4ccd1fe8ca477e8727660de8f239d2@haskell.org> #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): running the build with clang-6 from llvm tells us something more useful though still a slightly tricky error message cause theres no line numbers {{{ clang-6.0 -fno-stack-protector -DTABLES_NEXT_TO_CODE -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist- ghcconstants/header -Irts -Irts/dist/build -Irts/dist/build -Irts/dist/build/./autogen -fno-common -U__PIC__ -D__PIC__ -x assembler -c /var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T/ghc34265_0/ghc_1.s -o rts/dist/build/StgCRun.thr_o clang-6.0: warning: argument unused during compilation: '-fno-stack- protector' [-Wunused-command-line-argument] clang-6.0: warning: argument unused during compilation: '-D TABLES_NEXT_TO_CODE' [-Wunused-command-line-argument] clang-6.0: warning: argument unused during compilation: '-fno-common' [-Wunused-command-line-argument] clang-6.0: warning: argument unused during compilation: '-U __PIC__' [-Wunused-command-line-argument] clang-6.0: warning: argument unused during compilation: '-D __PIC__' [-Wunused-command-line-argument] :0: error: this directive must appear between .cfi_startproc and .cfi_endproc directives :0: error: this directive must appear between .cfi_startproc and .cfi_endproc directives :0: error: this directive must appear between .cfi_startproc and .cfi_endproc directives :0: error: this directive must appear between .cfi_startproc and .cfi_endproc directives :0: error: this directive must appear between .cfi_startproc and .cfi_endproc directives :0: error: this directive must appear between .cfi_startproc and .cfi_endproc directives :0: error: this directive must appear between .cfi_startproc and .cfi_endproc directives :0: error: this directive must appear between .cfi_startproc and .cfi_endproc directives :0: error: this directive must appear between .cfi_startproc and .cfi_endproc directives }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 21:35:08 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 21:35:08 -0000 Subject: [GHC] #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) In-Reply-To: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> References: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> Message-ID: <060.e93d3a260db5a94999e799e9d93edba7@haskell.org> #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): this still doesn't answer why the assembly clang generates for the same file is accepted, but the one generated by gcc isnt' -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 21:36:59 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 21:36:59 -0000 Subject: [GHC] #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) In-Reply-To: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> References: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> Message-ID: <060.f35e1718951235fcc3213d28b25c3645@haskell.org> #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): ahah! clang-6.0 doesn't accept its own assembly! {{{ $ clang-6.0 -fno-stack-protector -DTABLES_NEXT_TO_CODE -fno-stack-protector -Wall -Wall -Wextra -Wstrict-prototypes -Wmissing-prototypes -Wmissing- declarations -Winline -Waggregate-return -Wpointer-arith -Wmissing- noreturn -Wnested-externs -Wredundant-decls -Wundef -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist- ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS '-DFS_NAMESPACE=rts' -fno-strict-aliasing -fno-common -DDTRACE -Irts/dist/build/./autogen '-Werror=unused-but-set-variable' '-Wno- error=inline' -O2 -fomit-frame-pointer -g '-DRtsWay="rts_thr"' -w -DTHREADED_RTS -x c rts/StgCRun.c -o /var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T/ghc34756_0/ghc_1.s -fno- common -U__PIC__ -D__PIC__ -Wimplicit -S -O2 -include /Users/carter/WorkSpace/projects/active/ghc-head-may2018-clang- sad/includes/ghcversion.h -Iincludes -Iincludes/dist -Iincludes/dist- derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -Irts/dist/build -Irts/dist/build/./autogen -I/Users/carter/WorkSpace/projects/active/ghc-head-may2018-clang- sad/libraries/base/include -I/Users/carter/WorkSpace/projects/active/ghc- head-may2018-clang-sad/libraries/base/dist-install/build/include -I/Users/carter/WorkSpace/projects/active/ghc-head-may2018-clang- sad/libraries/integer-gmp/include -I/Users/carter/WorkSpace/projects/active/ghc-head-may2018-clang- sad/libraries/integer-gmp/dist-install/build/include -I/Users/carter/WorkSpace/projects/active/ghc-head-may2018-clang- sad/rts/dist/build -I/Users/carter/WorkSpace/projects/active/ghc-head- may2018-clang-sad/includes -I/Users/carter/WorkSpace/projects/active/ghc- head-may2018-clang-sad/includes/dist-derivedconstants/header 17:36:22 ~/W/p/a/ghc-head-may2018-clang-sad (master|…) $ clang-6.0 -fno-stack-protector -DTABLES_NEXT_TO_CODE -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist- ghcconstants/header -Irts -Irts/dist/build -Irts/dist/build -Irts/dist/build/./autogen -fno-common -U__PIC__ -D__PIC__ -x assembler -c /var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T/ghc34265_0/ghc_1.s -o rts/dist/build/StgCRun.thr_o clang-6.0: warning: argument unused during compilation: '-fno-stack- protector' [-Wunused-command-line-argument] clang-6.0: warning: argument unused during compilation: '-D TABLES_NEXT_TO_CODE' [-Wunused-command-line-argument] clang-6.0: warning: argument unused during compilation: '-fno-common' [-Wunused-command-line-argument] clang-6.0: warning: argument unused during compilation: '-U __PIC__' [-Wunused-command-line-argument] clang-6.0: warning: argument unused during compilation: '-D __PIC__' [-Wunused-command-line-argument] :0: error: this directive must appear between .cfi_startproc and .cfi_endproc directives :0: error: this directive must appear between .cfi_startproc and .cfi_endproc directives :0: error: this directive must appear between .cfi_startproc and .cfi_endproc directives :0: error: this directive must appear between .cfi_startproc and .cfi_endproc directives :0: error: this directive must appear between .cfi_startproc and .cfi_endproc directives :0: error: this directive must appear between .cfi_startproc and .cfi_endproc directives :0: error: this directive must appear between .cfi_startproc and .cfi_endproc directives :0: error: this directive must appear between .cfi_startproc and .cfi_endproc directives :0: error: this directive must appear between .cfi_startproc and .cfi_endproc directives }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 21:41:45 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 21:41:45 -0000 Subject: [GHC] #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) In-Reply-To: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> References: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> Message-ID: <060.deeccb78fac50cf54042c9f73cd8fa05@haskell.org> #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): also apple clang (some v5 llvm variant) rejects the assembly emited by clang v6! {{{ /usr/bin/clang -fno-stack-protector -DTABLES_NEXT_TO_CODE -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist- ghcconstants/header -Irts -Irts/dist/build -Irts/dist/build -Irts/dist/build/./autogen -fno-common -U__PIC__ -D__PIC__ -x assembler -c /var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T/ghc34265_0/ghc_1.s -o rts/dist/build/StgCRun.thr_o clang: warning: argument unused during compilation: '-fno-stack-protector' [-Wunused-command-line-argument] clang: warning: argument unused during compilation: '-D TABLES_NEXT_TO_CODE' [-Wunused-command-line-argument] clang: warning: argument unused during compilation: '-fno-common' [-Wunused-command-line-argument] clang: warning: argument unused during compilation: '-U __PIC__' [-Wunused-command-line-argument] clang: warning: argument unused during compilation: '-D __PIC__' [-Wunused-command-line-argument] clang -cc1as: fatal error: error in backend: No open frame }}} this definitely seems like a bug in llvm -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 21:49:03 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 21:49:03 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.ff962f7c8bef6bd6b2ace0d074e3e6fc@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): In a call today Richard and Simon decided: * Kill 1decideKindGeneralisationPlan`; instead always generalise. (Explain why we don't need to worry about local generalisation as we do with terms.) * And hence kill `tc_hs_sig_type`, leaving `tc_hs_sig_type_and_gen` * `tc_hs_sig_type_and_gen` should not call `solveEqualities` (which fails if there are unsolved equalities) * Instead call `solveLocalEqualities`, gather unsolved equalities, and do not quantify over their free vars. NB: `tcImplicitTKBndrs` already calls `solveLocalEqualities`, and must do so. Needs a Note to explain why: it's so that we can top-sort the bound variables * Promote all the free vars of the unsolved constraints. '''Principle''': all free vars should either be generalised or promoted. * Get rid of `zonkPromote` and friends altogether -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 22:01:35 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 22:01:35 -0000 Subject: [GHC] #14939: Lint error in forall type (was: StaticPointers + -dcore-lint: cause Core Lint error??) In-Reply-To: <051.8bc9e96ca4b89b1613c7c0914d47c2a8@haskell.org> References: <051.8bc9e96ca4b89b1613c7c0914d47c2a8@haskell.org> Message-ID: <066.57b83ef0e874409f73d7258368c6a4e3@haskell.org> #14939: Lint error in forall type -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | StaticPointers Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): The Lint error is this: {{{ In the type `forall (cls :: * -> Constraint) (b :: Alg cls *). b' Variable escape in forall: forall (cls :: * -> Constraint) (b :: Alg cls *). b }}} The complaint is because the kind of the body of the forall is `Alg cls *`, but the forall binds `cls` so it looks as if `cls` escapes. But actually it is fine because {{{ type Alg cls ob = ob }}} so `Alg cls *` is really just `*`, and the `cls` argument is not mentioned in the expansion. I conclude that the program is fine and it's Lint that is at fault. c.f. `TcUnify.occCheckExpand` and `CoreUtils.coreAltsType` which deal with the same problem. A single systematic solution eludes me. I worry that `Type.typeKind` suffers from the same problem, in the `ForAllTy` case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu May 31 23:44:35 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 May 2018 23:44:35 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.8e83e812796014a42122ecb74b24748f@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): While I agree with comment:17, that doesn't have anything to do with this ticket... -- Ticket URL: GHC The Glasgow Haskell Compiler